Ubisys C4 UNSUPPORTED_ATTRIBUTE on writing configure_device_setup #2552

sjorge · 2021-05-05T22:06:35Z

Zigbee2MQTT:debug 2021-05-05 22:01:00: Received MQTT message on 'zigbee2mqtt/livingroom/light/switch2/set' with data '{"configure_device_setup":{"input_action_templates":[{"type":"dimmer_single"},{"type":"dimmer_single"}]}}'
Zigbee2MQTT:debug 2021-05-05 22:01:00: Publishing 'set' 'configure_device_setup' to 'livingroom/light/switch2'
Zigbee2MQTT:warn  2021-05-05 22:01:00: ubisys: Using input(s) 0 and endpoint 1 for 'dimmer_single'.
Zigbee2MQTT:warn  2021-05-05 22:01:00: ubisys: Using input(s) 1 and endpoint 2 for 'dimmer_single'.
Zigbee2MQTT:debug 2021-05-05 22:01:00: ubisys: input_actions to be sent to 'livingroom/light/switch2': [[0,7,1,6,0,2],[0,134,1,8,0,5,0,50],[0,198,1,8,0,5,1,50],[0,11,1,8,0,3],[1,7,2,6,0,2],[1,134,2,8,0,5,0,50],[1,198,2,8,0,5,1,50],[1,11,2,8,0,3]]
Zigbee2MQTT:error 2021-05-05 22:01:00: Publish 'set' 'configure_device_setup' to 'livingroom/light/switch2' failed: 'Error: Write 0x001fee0000005baa/232 manuSpecificUbisysDeviceSetup({"inputActions":{"elementType":"octetStr","elements":[[0,7,1,6,0,2],[0,134,1,8,0,5,0,50],[0,198,1,8,0,5,1,50],[0,11,1,8,0,3],[1,7,2,6,0,2],[1,134,2,8,0,5,0,50],[1,198,2,8,0,5,1,50],[1,11,2,8,0,3]]}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4338,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')'
Zigbee2MQTT:debug 2021-05-05 22:01:00: Error: Write 0x001fee0000005baa/232 manuSpecificUbisysDeviceSetup({"inputActions":{"elementType":"octetStr","elements":[[0,7,1,6,0,2],[0,134,1,8,0,5,0,50],[0,198,1,8,0,5,1,50],[0,11,1,8,0,3],[1,7,2,6,0,2],[1,134,2,8,0,5,0,50],[1,198,2,8,0,5,1,50],[1,11,2,8,0,3]]}}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4338,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
    at Endpoint.checkStatus (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:196:23)
    at Endpoint.<anonymous> (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:225:26)
    at Generator.next (<anonymous>)
    at fulfilled (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:24:58)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)

@felixstorm I got a C4 to play with, but it's not taking the configuration of the inputs, it gives UNSUPPORTED_ATTRIBUTE. After that, the device is 'bricked' until it is power cycled.

I have not yet upgraded the device, I will do so and try again.

Edit: there was no update available, so maybe they changed how this works on the newer firmwares?

The text was updated successfully, but these errors were encountered:

sjorge · 2021-05-05T22:11:27Z

I just tried it on some of my S1 and S2, it now also gives UNSUPPORTED_ATTRIBUTE. I have also updated those.
So looks like the new firmware different, and my C4 already shipped with it.

felixstorm · 2021-05-07T10:36:01Z

Unfortunately I currently do not have an environment at hand to test this myself, but would you be able to provide logs containing the ZigBee bytes (including header) being sent?

From the back of my head I think I remember that the ubisys devices used to be quite picky on whether the manufacturer specific bit in the ZigBee header needed to be set or needed not to be set and that this behavior even was not always aligned with the official ZigBee ZCL specification. Therefore it could also be that something within z2m has been changed in the meantime to do things right but that this now leads to problems with the ubisys devices (who might expect this to not be done "right")...

sjorge · 2021-05-07T18:49:19Z

So send the same command while having wireshark running to check the payload?

sjorge · 2021-05-07T19:10:15Z

Seems the old saying is right, 3rd try I got both.

The write

Frame 28: 146 bytes on wire (1168 bits), 146 bytes captured (1168 bits) on interface /var/folders/fh/5w4ww0ms2wj2zg6w12pph4ph0000gn/T/wireshark_extcap_-dev-cu.usbmodemCCE532FC3D041B2QZ20, id 0
IEEE 802.15.4 TAP
IEEE 802.15.4 Data, Dst: 0x46a9, Src: 0x0000
    Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = PAN ID Compression: True
        .... .... 0... .... = Reserved: False
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
    Sequence Number: 69
    Destination PAN: 0x1a5e
    Destination: 0x46a9
    Source: 0x0000
    [Extended Source: TexasIns_00:22:81:20:b5 (00:12:4b:00:22:81:20:b5)]
    [Origin: 16]
    [Ack In: 29]
ZigBee Network Layer Data, Dst: 0x46a9, Src: 0x0000
    Frame Control Field: 0x0248, Frame Type: Data, Discover Route: Enable, Security Data
        .... .... .... ..00 = Frame Type: Data (0x0)
        .... .... ..00 10.. = Protocol Version: 2
        .... .... 01.. .... = Discover Route: Enable (0x1)
        .... ...0 .... .... = Multicast: False
        .... ..1. .... .... = Security: True
        .... .0.. .... .... = Source Route: False
        .... 0... .... .... = Destination: False
        ...0 .... .... .... = Extended Source: False
        ..0. .... .... .... = End Device Initiator: False
    Destination: 0x46a9
    Source: 0x0000
    Radius: 30
    Sequence Number: 149
    [Extended Source: TexasIns_00:22:81:20:b5 (00:12:4b:00:22:81:20:b5)]
    [Origin: 16]
    ZigBee Security Header
ZigBee Application Support Layer Data, Dst Endpt: 232, Src Endpt: 1
    Frame Control Field: Data (0x00)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False
        .0.. .... = Acknowledgement Request: False
        0... .... = Extended Header: False
    Destination Endpoint: 232
    Cluster: Manufacturer Specific (0xfc00)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 52
ZigBee Cluster Library Frame, Mfr: Ubisys technologies GmbH (0x10f2), Command: Write Attributes, Seq: 25
    Frame Control Field: Profile-wide (0x14)
    Manufacturer Code: Ubisys technologies GmbH (0x10f2)
    Sequence Number: 25
    Command: Write Attributes (0x02)
    Attribute Field
        Attribute: 0x0001
        Data Type: Array (0x48)
        Elements Type: Octet String (0x41)
        Elements Number: 8
        Element #1, Octets: 00:07:01:06:00:02
        Element #2, Octets: 00:86:01:08:00:05:00:32
        Element #3, Octets: 00:c6:01:08:00:05:01:32
        Element #4, Octets: 00:0b:01:08:00:03
        Element #5, Octets: 01:07:02:06:00:02
        Element #6, Octets: 01:86:02:08:00:05:00:32
        Element #7, Octets: 01:c6:02:08:00:05:01:32
        Element #8, Octets: 01:0b:02:08:00:03

The response:

Frame 32: 79 bytes on wire (632 bits), 79 bytes captured (632 bits) on interface /var/folders/fh/5w4ww0ms2wj2zg6w12pph4ph0000gn/T/wireshark_extcap_-dev-cu.usbmodemCCE532FC3D041B2QZ20, id 0
IEEE 802.15.4 TAP
IEEE 802.15.4 Data, Dst: 0x0000, Src: 0x46a9
    Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = PAN ID Compression: True
        .... .... 0... .... = Reserved: False
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
    Sequence Number: 242
    Destination PAN: 0x1a5e
    Destination: 0x0000
    Source: 0x46a9
    [Extended Source: ubisyste_00:00:00:5b:aa (00:1f:ee:00:00:00:5b:aa)]
    [Origin: 24]
    [Ack In: 33]
ZigBee Network Layer Data, Dst: 0x0000, Src: 0x46a9
    Frame Control Field: 0x0248, Frame Type: Data, Discover Route: Enable, Security Data
        .... .... .... ..00 = Frame Type: Data (0x0)
        .... .... ..00 10.. = Protocol Version: 2
        .... .... 01.. .... = Discover Route: Enable (0x1)
        .... ...0 .... .... = Multicast: False
        .... ..1. .... .... = Security: True
        .... .0.. .... .... = Source Route: False
        .... 0... .... .... = Destination: False
        ...0 .... .... .... = Extended Source: False
        ..0. .... .... .... = End Device Initiator: False
    Destination: 0x0000
    Source: 0x46a9
    Radius: 30
    Sequence Number: 15
    [Extended Source: ubisyste_00:00:00:5b:aa (00:1f:ee:00:00:00:5b:aa)]
    [Origin: 24]
    ZigBee Security Header
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 232
    Frame Control Field: Data (0x40)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False
        .1.. .... = Acknowledgement Request: True
        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: Manufacturer Specific (0xfc00)
    Profile: Home Automation (0x0104)
    Source Endpoint: 232
    Counter: 31
ZigBee Cluster Library Frame, Mfr: Ubisys technologies GmbH (0x10f2), Command: Write Attributes Response, Seq: 25
    Frame Control Field: Profile-wide (0x1c)
    Manufacturer Code: Ubisys technologies GmbH (0x10f2)
    Sequence Number: 25
    Command: Write Attributes Response (0x04)
    Status Record
        Status: Unsupported Attribute (0x86)
        Attribute: 0x0001

felixstorm · 2021-05-09T11:16:23Z

@sjorge Thanks! The dump shows that the bit "Manufacturer specific" is set in the ZCL frame control field (0x14) and that the manufacturer code also gets sent in the ZCL header (which needs to be done if the bit is set). And looking at some of my older notes and also at this issue here it seems that ubisys will really only accept the write attributes command when the flag has not been set (which probably used to be the case or at least used to be possible in the past).

Also, I already tried to contact ubisys twice on this incompatibility, but I never received any response from them - so I guess there is very little chance that they will ever change this.

@Koenkk Do you see any chance to send a write attributes command to a non-standard cluster without the ZCL manufacturer bit being set in the header from the converters? This is the line where it currently happens:

zigbee-herdsman-converters/converters/toZigbee.js

Lines 3248 to 3249 in f67c255

    
           await devMgmtEp.write('manuSpecificUbisysDeviceSetup', 
        
               {'inputActions': {elementType: 'octetStr', elements: resultingInputActions}});

Sorry for asking without searching through the code more thorougly myself, but due to the current pandemic situation here in Germany with two little kids, home-schooling and a full-time job my time is unfortunately very, very limited at the moment.

sjorge · 2021-05-09T11:26:36Z

Also, I already tried to contact ubisys twice on this incompatibility, but I never received any response from them - so I guess there is very little chance that they will ever change this.

Yeah from my experience they are usually quick to verify something is wrong or broken, but don't actually fix it. (.e.g. genOnOff.startupOnOff is broken when the input is configured a momentum switch but works OK when using it as a normal switch) ... although it is also a hit and miss on getting a response at all when writing to them in English.

Sorry for asking without searching through the code more thoroughly myself, but due to the current pandemic situation here in Germany with two little kids, home-schooling and a full-time job my time is unfortunately very, very limited at the moment.

Understandable! Good luck.

https://github.com/Koenkk/zigbee-herdsman/blob/be70088a148f9cb7fea9dcc2d81fd4851d0dc8f3/src/controller/model/endpoint.ts#L272 seems to indicate we can send an options param and perhaps set manufacturerCode but I don't see how we can unset it. I think the lookup for manuSpecificUbisysDeviceSetup would also fail then.

felixstorm · 2021-05-09T12:34:02Z

You could try to pass an options object with a manufacturerCode property set to 0 (zero) or null - that might work (the options properties are added to the defaults with the … operator, so the mere presence of the property should override the defaults). The cluster lookup seems to be performed without any reference to the manufacturer (but in contrast return the default manufacturer code to be used), so that could still work.

sjorge · 2021-05-09T18:29:28Z

That didn't seem to help

Zigbee2MQTT:debug 2021-05-09 18:28:18: Publishing 'set' 'configure_device_setup' to 'livingroom/light/switch2'
Zigbee2MQTT:warn  2021-05-09 18:28:18: ubisys: Using input(s) 0 and endpoint 1 for 'dimmer_single'.
Zigbee2MQTT:warn  2021-05-09 18:28:18: ubisys: Using input(s) 1 and endpoint 2 for 'dimmer_single'.
Zigbee2MQTT:debug 2021-05-09 18:28:18: ubisys: input_actions to be sent to 'livingroom/light/switch2': [[0,7,1,6,0,2],[0,134,1,8,0,5,0,50],[0,198,1,8,0,5,1,50],[0,11,1,8,0,3],[1,7,2,6,0,2],[1,134,2,8,0,5,0,50],[1,198,2,8,0,5,1,50],[1,11,2,8,0,3]]
Zigbee2MQTT:debug 2021-05-09 18:28:18: Received Zigbee message from 'livingroom/light/switch2', type 'readResponse', cluster 'manuSpecificUbisysDeviceSetup', data '{}' from endpoint 232 with groupID 0
Zigbee2MQTT:debug 2021-05-09 18:28:18: No converter available for 'C4' with cluster 'manuSpecificUbisysDeviceSetup' and type 'readResponse' and data '{}'
(node:22418) UnhandledPromiseRejectionWarning: Error: Read 0x001fee0000005baa/232 manuSpecificUbisysDeviceSetup(["inputConfigurations"], {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":4338,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Status 'UNSUPPORTED_ATTRIBUTE')
    at Endpoint.checkStatus (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:196:23)
    at Endpoint.<anonymous> (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:251:26)
    at Generator.next (<anonymous>)
    at fulfilled (/opt/zigbee2mqtt/node_modules/zigbee-herdsman/dist/controller/model/endpoint.js:24:58)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
(Use `node --trace-warnings ...` to show where the warning was created)
(node:22418) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:22418) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

The line now reads

                await devMgmtEp.write('manuSpecificUbisysDeviceSetup',
                    {'inputActions': {elementType: 'octetStr', elements: resultingInputActions}}, {manufacturerCode: null});

When I did the same for the reads, i now tries to use manuSpecificPhilips so it does seem to require the manufacturerCode to be set, or at least not 0.

sjorge · 2021-05-09T18:35:25Z

That being said... it did seem to have applied the change to the C4...

Zigbee2MQTT:debug 2021-05-09 18:30:51: Received MQTT message on 'zigbee2mqtt/livingroom/light/switch2/set' with data '{"configure_device_setup":{"input_action_templates":[{"type":"dimmer_single"},{"type":"dimmer_single"}]}}'
Zigbee2MQTT:debug 2021-05-09 18:30:51: Publishing 'set' 'configure_device_setup' to 'livingroom/light/switch2'
Zigbee2MQTT:warn  2021-05-09 18:30:51: ubisys: Using input(s) 0 and endpoint 1 for 'dimmer_single'.
Zigbee2MQTT:warn  2021-05-09 18:30:51: ubisys: Using input(s) 1 and endpoint 2 for 'dimmer_single'.
Zigbee2MQTT:debug 2021-05-09 18:30:51: ubisys: input_actions to be sent to 'livingroom/light/switch2': [[0,7,1,6,0,2],[0,134,1,8,0,5,0,50],[0,198,1,8,0,5,1,50],[0,11,1,8,0,3],[1,7,2,6,0,2],[1,134,2,8,0,5,0,50],[1,198,2,8,0,5,1,50],[1,11,2,8,0,3]]
Zigbee2MQTT:debug 2021-05-09 18:30:51: Received Zigbee message from 'livingroom/light/switch2', type 'readResponse', cluster 'manuSpecificPhilips', data '{"0":[0,0,0,0]}' from endpoint 232 with groupID 0
Zigbee2MQTT:debug 2021-05-09 18:30:51: No converter available for 'C4' with cluster 'manuSpecificPhilips' and type 'readResponse' and data '{"0":[0,0,0,0]}'
Zigbee2MQTT:warn  2021-05-09 18:30:51: ubisys: Device setup read for 'livingroom/light/switch2': {"0":[0,0,0,0]}
Zigbee2MQTT:debug 2021-05-09 18:30:51: Received Zigbee message from 'livingroom/light/switch2', type 'readResponse', cluster 'manuSpecificPhilips', data '{"1":[{"data":[0,7,1,6,0,2],"type":"Buffer"},{"data":[0,134,1,8,0,5,0,50],"type":"Buffer"},{"data":[0,198,1,8,0,5,1,50],"type":"Buffer"},{"data":[0,11,1,8,0,3],"type":"Buffer"},{"data":[1,7,2,6,0,2],"type":"Buffer"},{"data":[1,134,2,8,0,5,0,50],"type":"Buffer"},{"data":[1,198,2,8,0,5,1,50],"type":"Buffer"},{"data":[1,11,2,8,0,3],"type":"Buffer"}]}' from endpoint 232 with groupID 0
Zigbee2MQTT:debug 2021-05-09 18:30:51: No converter available for 'C4' with cluster 'manuSpecificPhilips' and type 'readResponse' and data '{"1":[{"data":[0,7,1,6,0,2],"type":"Buffer"},{"data":[0,134,1,8,0,5,0,50],"type":"Buffer"},{"data":[0,198,1,8,0,5,1,50],"type":"Buffer"},{"data":[0,11,1,8,0,3],"type":"Buffer"},{"data":[1,7,2,6,0,2],"type":"Buffer"},{"data":[1,134,2,8,0,5,0,50],"type":"Buffer"},{"data":[1,198,2,8,0,5,1,50],"type":"Buffer"},{"data":[1,11,2,8,0,3],"type":"Buffer"}]}'
Zigbee2MQTT:warn  2021-05-09 18:30:51: ubisys: Device setup read for 'livingroom/light/switch2': {"1":[{"type":"Buffer","data":[0,7,1,6,0,2]},{"type":"Buffer","data":[0,134,1,8,0,5,0,50]},{"type":"Buffer","data":[0,198,1,8,0,5,1,50]},{"type":"Buffer","data":[0,11,1,8,0,3]},{"type":"Buffer","data":[1,7,2,6,0,2]},{"type":"Buffer","data":[1,134,2,8,0,5,0,50]},{"type":"Buffer","data":[1,198,2,8,0,5,1,50]},{"type":"Buffer","data":[1,11,2,8,0,3]}]}

And it was able to read the data, @Koenkk do we somehow need a extra flag we still use the manufacturerCode to find the right info in cluster.ts but send it without the value set like Felix sugested?

felixstorm · 2021-05-10T08:15:31Z

The UnhandledPromiseRejectionWarning from your first log above probably just came up because it automatically does a read directly after the write and the read statement had not yet been changed for the first log?
So the sending part seems to be completely fine then with {manufacturerCode: null} both for writes and for reads?

As for interpreting the response with the correct cluster, this had never really worked (also discussed in Koenkk/zigbee-herdsman#52). The problem is - AFAIR - that zigbee-herdsman can only use information directly contained in the response packet to lookup the correct cluster structure and name and assign it to the cluster id in the packet (i.e. it has no idea that 0xfc01 sometimes means "ubisys" and sometimes "philips"). And as the ubisys devices respond without a manufacturer id (which is correct if the request also did not contain one) zigbee-herdsman probably just takes the first cluster where the number matches (at least it used to be like this when I implemented it last year).
But to be honest I don't think this is a big problem since the result is still being parsed correctly anyway despite the wrong cluster name and then gets printed to the log without 'manuSpecificPhilips' ever being shown outside of the debug logs.

So my suggestion would be the following:

Add another line below

zigbee-herdsman-converters/converters/toZigbee.js

Line 19 in 7be424d

ubisys: {manufacturerCode: herdsman.Zcl.ManufacturerCode.UBISYS},

containing: ubisysNoManufacturerCode: {manufacturerCode: null}, with a comment that ubisys expects no manufacturer id for their custom clusters

Use manufacturerOptions.ubisysNoManufacturerCode in all reads and writes that deal with those custom clusters. The places that I found are these (but please double check them, I might have forgotten some):

zigbee-herdsman-converters/converters/toZigbee.js

Lines 3060 to 3061 in 7be424d

    
           await devMgmtEp.write('manuSpecificUbisysDeviceSetup', 
        
               {'inputConfigurations': {elementType: 'data8', elements: value.input_configurations}});

zigbee-herdsman-converters/converters/toZigbee.js

Lines 3066 to 3067 in 7be424d

    
           await devMgmtEp.write('manuSpecificUbisysDeviceSetup', 
        
               {'inputActions': {elementType: 'octetStr', elements: value.input_actions}});

zigbee-herdsman-converters/converters/toZigbee.js

Lines 3248 to 3249 in 7be424d

    
           await devMgmtEp.write('manuSpecificUbisysDeviceSetup', 
        
               {'inputActions': {elementType: 'octetStr', elements: resultingInputActions}});

zigbee-herdsman-converters/converters/toZigbee.js

Lines 3262 to 3263 in 7be424d

    
           log(await devMgmtEp.read('manuSpecificUbisysDeviceSetup', ['inputConfigurations'])); 
        
           log(await devMgmtEp.read('manuSpecificUbisysDeviceSetup', ['inputActions']));

zigbee-herdsman-converters/converters/toZigbee.js

Line 3043 in 7be424d

await entity.write('manuSpecificUbisysDimmerSetup', {'mode': phaseControlValues[phaseControl]});

zigbee-herdsman-converters/converters/toZigbee.js

Lines 3048 to 3050 in 7be424d

    
           await entity.read('manuSpecificUbisysDimmerSetup', ['capabilities']); 
        
           await entity.read('manuSpecificUbisysDimmerSetup', ['status']); 
        
           await entity.read('manuSpecificUbisysDimmerSetup', ['mode']);

I just tried reading zigbee2mqtt/.../get/mode_phase_control from a D1 in my production environment and received an UNSUPPORTED_ATTRIBUTE error, but if you also happen to have a D1/D1R then you might want to verify the last two changes affecting manuSpecificUbisysDimmerSetup.

Does that sound ok? And would you be able to create a pull request with these changes?

felixstorm · 2021-05-10T08:22:25Z

Another note: The code that deals with the ubisys J1 (i.e. calibration) does not need the modification as it accesses custom attributes inside a standard cluster and ubisys requires for the manufacturer id to be sent in the packet for these operations.

sjorge · 2021-05-13T09:49:13Z

Taking a look at this now, I only have S1, S2 and C4 as of now.

rindlerblabla · 2021-05-13T09:56:43Z

Would it be possible to expose those settings to the frontend, or would that be a lot of extra work?

sjorge · 2021-05-13T10:13:39Z

Would it be possible to expose those settings to the frontend, or would that be a lot of extra work?

AFAIK there is no way to describe an array of objects, where the objects have a set of flexible attributes.

sjorge · 2021-05-13T10:25:16Z

Seems to work, I reconfigured all my S1, S2 and C4 by adding 'no_onoff', that is how i noticed it was broken in the first place, trying to change that :)

* Add ubisysNull manufacturer option * Switch to manufacturerOptions.ubisysNull for some converters

This comment has been minimized.

Sign in to view

sjorge mentioned this issue May 13, 2021

Fix #2552 Ubisys configuration throws UNSUPPORTED_ATTRIBUTE #2570

Merged

Koenkk closed this as completed in #2570 May 13, 2021

Koenkk pushed a commit that referenced this issue May 13, 2021

Fix #2552 Ubisys configuration throws UNSUPPORTED_ATTRIBUTE (#2570)

022196f

* Add ubisysNull manufacturer option * Switch to manufacturerOptions.ubisysNull for some converters

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ubisys C4 UNSUPPORTED_ATTRIBUTE on writing configure_device_setup #2552

Ubisys C4 UNSUPPORTED_ATTRIBUTE on writing configure_device_setup #2552

sjorge commented May 5, 2021 •

edited

Loading

sjorge commented May 5, 2021

felixstorm commented May 7, 2021

sjorge commented May 7, 2021

This comment has been minimized.

sjorge commented May 7, 2021

felixstorm commented May 9, 2021

sjorge commented May 9, 2021 •

edited

Loading

felixstorm commented May 9, 2021

sjorge commented May 9, 2021 •

edited

Loading

sjorge commented May 9, 2021

felixstorm commented May 10, 2021

felixstorm commented May 10, 2021

sjorge commented May 13, 2021

rindlerblabla commented May 13, 2021

sjorge commented May 13, 2021

sjorge commented May 13, 2021

Ubisys C4 UNSUPPORTED_ATTRIBUTE on writing configure_device_setup #2552

Ubisys C4 UNSUPPORTED_ATTRIBUTE on writing configure_device_setup #2552

Comments

sjorge commented May 5, 2021 • edited Loading

sjorge commented May 5, 2021

felixstorm commented May 7, 2021

sjorge commented May 7, 2021

This comment has been minimized.

sjorge commented May 7, 2021

felixstorm commented May 9, 2021

sjorge commented May 9, 2021 • edited Loading

felixstorm commented May 9, 2021

sjorge commented May 9, 2021 • edited Loading

sjorge commented May 9, 2021

felixstorm commented May 10, 2021

felixstorm commented May 10, 2021

sjorge commented May 13, 2021

rindlerblabla commented May 13, 2021

sjorge commented May 13, 2021

sjorge commented May 13, 2021

sjorge commented May 5, 2021 •

edited

Loading

sjorge commented May 9, 2021 •

edited

Loading

sjorge commented May 9, 2021 •

edited

Loading