Item/Node is not updated when a Report Attributes Command is received

Hi OH Community,

I’m running OH 3.2.0 and I have a custom ZigBee device that turns on/off/dims an LED with a Rotary Encoder. The device uses the On/Off Cluster and LevelControl Cluster. When I click on the dimmer item or the onoff switch item, OH sends the MoveToLevelWithOnOff and my ZigBee device replies with a Default Response with Status OK (0x00) as well as a Report Attribute Command. Everything works as expected.

But when I operate the LED with the Rotary Encoder, the hardware works as expected and the device sends a Report Attributes Command to OH to update it’s status (on, off, dimmer value), however
in the logs, OH says that the Node is not updated. As a result, the item does not change to the On/Off state or the Dimmer state. The values stay as the last time I used the OH UI.

Why is OH not updating the Items when it’s receiving Report Attribute Commands?

Thanks.

Log below:

2022-06-06 11:52:44.856 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspIncomingSenderEui64Handler [networkId=0, senderEui64=0013A20041A406E7]
2022-06-06 11:52:44.879 [DEBUG] [zigbee.dongle.ember.ZigBeeDongleEzsp] - RX EZSP: EzspIncomingMessageHandler [networkId=0, type=EMBER_INCOMING_UNICAST, apsFrame=EmberApsFrame [profileId=0104, clusterId=0008, sourceEndpoint=4, destinationEndpoint=1, options=[EMBER_APS_OPTION_ENABLE_ROUTE_DISCOVERY, EMBER_APS_OPTION_DESTINATION_EUI64, EMBER_APS_OPTION_SOURCE_EUI64], groupId=0, sequence=21], lastHopLqi=255, lastHopRssi=-45, sender=95DA, bindingIndex=255, addressIndex=255, messageContents=18 D2 0A 00 00 20 F1]
2022-06-06 11:52:44.883 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX APS: ZigBeeApsFrame [sourceAddress=95DA/4, destinationAddress=0000/1, profile=0104, cluster=0008, addressMode=DEVICE, radius=0, apsSecurity=false, ackRequest=false, apsCounter=21, rssi=-45, lqi=FF, payload=18 D2 0A 00 00 20 F1]
2022-06-06 11:52:44.886 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 0013A20041A406E7: Node update. NWK Address=NULL
2022-06-06 11:52:44.890 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - 0013A20041A406E7: Node 95DA is not updated from ZigBeeNode [state=ONLINE, IEEE=0013A20041A406E7, NWK=----, endpoints=[]]
2022-06-06 11:52:44.893 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX ZCL: ZclHeader [frameType=ENTIRE_PROFILE_COMMAND, manufacturerSpecific=false, direction=SERVER_TO_CLIENT, disableDefaultResponse=true, manufacturerCode=0, sequenceNumber=D2, commandId=10]
2022-06-06 11:52:44.897 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Level Control: 95DA/4 -> 0000/1, cluster=0008, TID=D2, reports=[AttributeReport [attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, attributeValue=241]]]
2022-06-06 11:52:44.899 [DEBUG] [transaction.ZigBeeTransactionManager] - notifyTransactionCommand: ReportAttributesCommand [Level Control: 95DA/4 -> 0000/1, cluster=0008, TID=D2, reports=[AttributeReport [attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, attributeValue=241]]] 
2022-06-06 11:52:44.903 [DEBUG] [converter.ZigBeeConverterSwitchLevel] - 0013A20041A406E7: ZigBee attribute reports ZclAttribute [cluster=Level Control, id=0, name=Current Level, dataType=UNSIGNED_8_BIT_INTEGER, lastValue=241, lastReportTime=Mon Jun 06 11:52:44 EDT 2022, implemented=true]

You can ignore this message - it is not related to the binding.

What clusters does this device support, and what channels do you have? Can you provide the XML file for this device (in the userdata/zigbee folder with the file name of the devices long address).

Clusters Supported: Basic, OnOff and LevelControl.
EP1 = Basic Cluster
EP2 = OnOff Cluster
EP3 = OnOff and LevelControl
EP4 = OnOff and LevelControl

XML file: 0013A20041A406E7.xml (58.5 KB)

I also noticed a strange behavior. Normally, on a EP with LevelControl with OnOff, any command received by the EP (on, off, move, step, etc) is followed by a Default Response, a report for OnOff State and a report for LevelControl CurrentLevel.
Below is the log output when I send a Move or an On command.

Move To Level Command:

2022-06-06 19:12:12.701 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: MoveToLevelWithOnOffCommand [Level Control: 0000/0 -> 95DA/3, cluster=0008, TID=A8, level=102, transitionTime=10]
2022-06-06 19:12:12.868 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: DefaultResponse [Level Control: 95DA/3 -> 0000/1, cluster=0008, TID=A8, commandIdentifier=4, statusCode=SUCCESS]
2022-06-06 19:12:12.928 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [On/Off: 95DA/3 -> 0000/1, cluster=0006, TID=06, reports=[AttributeReport [attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=true]]]
2022-06-06 19:12:12.679 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' received command 40
2022-06-06 19:12:12.883 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 0 to 40
2022-06-06 19:12:12.885 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from OFF to ON
2022-06-06 19:12:12.942 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 40 to 0
2022-06-06 19:12:12.945 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from ON to OFF
2022-06-06 19:12:12.982 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Level Control: 95DA/3 -> 0000/1, cluster=0008, TID=07, reports=[AttributeReport [attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, attributeValue=102]]]
2022-06-06 19:12:13.000 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 0 to 40
2022-06-06 19:12:13.003 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from OFF to ON

On Command:

2022-06-06 19:15:02.793 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: OnCommand [On/Off: 0000/0 -> 95DA/3, cluster=0006, TID=AD]
2022-06-06 19:15:02.987 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: DefaultResponse [On/Off: 95DA/3 -> 0000/1, cluster=0006, TID=AD, commandIdentifier=1, statusCode=SUCCESS]
2022-06-06 19:15:02.774 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' received command ON
2022-06-06 19:15:03.046 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [On/Off: 95DA/3 -> 0000/1, cluster=0006, TID=10, reports=[AttributeReport [attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=true]]]
2022-06-06 19:15:03.108 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Level Control: 95DA/3 -> 0000/1, cluster=0008, TID=11, reports=[AttributeReport [attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, attributeValue=8]]]
2022-06-06 19:15:03.000 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 0 to 100
2022-06-06 19:15:03.007 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from OFF to ON
2022-06-06 19:15:03.062 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 100 to 0
2022-06-06 19:15:03.066 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from ON to OFF
2022-06-06 19:15:03.126 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 0 to 3
2022-06-06 19:15:03.128 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from OFF to ON

As you can see OH turns on the item, turns it back off and then turns it back on…

As far as I can see, everything seems to be working ok from the zigbee perspective for this report. There is a check in the code that the level will only be updated in OH if the device is also considered ON - this is done since a device can send reports of the level, even when it’s off. My guess is this is the issue here as it’s nearly the only check between the above log entry and the channel update.

But if the device is OFF and it gets a report for CurrentLevel that is > 0 doesn’t that imply that the device turned ON?

No - because because there is a decoupling between On/Off and Level and it’s possible for a device to update its level even when it’s off (and remain off). This allows the level to be set before turning it on.

This is why for example there is a command MoveToLevel and MoveToLevelWithOnOff - one impacts the On/Off state, and the other only changes the level.

1 Like

For information - here’s what the standards say -:

There are two sets of commands provided in the Level Control cluster. These are identical, except that the first set (Move to Level, Move and Step) SHALL NOT affect the OnOff attribute, whereas the second set (‘with On/Off’ variants) SHALL.

The first set is used to maintain independence between the CurrentLevel and OnOff attributes, so changing CurrentLevel has no effect on the OnOff attribute. As examples, this represents the behavior of a volume control with a mute button, or a ‘turn to set level and press to turn on/off’ light dimmer.

The second set is used to link the CurrentLevel and OnOff attributes. When the level is reduced to its minimum the OnOff attribute is automatically turned to Off, and when the level is increased above its minimum the OnOff attribute is automatically turned to On. As an example, this represents the behavior of a light dimmer with no independent on/off switch.

Completely agree. In this case, the command that OH is sending is the MoveToLevelWithOnOff so it should behave as described in last paragraph above, and it is not.

Ok, so I guess this is a problem in the device :frowning:. If I understand your comment in the first paragraph this is a device you have built? If so, I guess you are able to influence the way this works?

OK, so I figured out what was happening. The device was not sending the OnOff State reports whenever the CurrentLevel attribute changed between 0 and Non-0 values. So now everything is working as expected.

I did further testing and these are my findings.

Device configured with following: (all startup values/States are 0 or Off)
EP1: Basic
EP2: OnOff Cluster
EP3: Level Control Cluster
EP4: OnOff and Level Control Cluster

Test#1 - Initiate actions from OH UI:
EP2: On, Off - Works.
EP3: Move To Level - Fails
EP4: Move To Level - Works.
Result: All EPs work fine from OH UI, except for EP3 because OH requires that an OnOff cluster exist in the same EP for the Level Control to work. This is the same behavior I reported back in OH2.5. I still believe goes against what the Zigbee Spec because nowhere does it say that LevelControl cluster requires an OnOff cluster on the same EP or that it is mandatory. If that continues to be the case, then OH will never send or use LevelControl Commands 0x00 to 0x03.

Behavior Note: OH reacts to EP4 responses in a strange way:
OH → Sends MoveToLevelWithOnOffCommand to value X > 0 or Sends OnCommand
OH → Gets Default Response OK
OH → Gets Report OnOff State = ON
OH → Sets Level Control to X
OH → Sets OnOff State to ON
OH → Sets Level Control back to 0
OH → Sets OnOff State back to OFF
OH → Gets Report LevelControl Value = X
OH → Sets Level Control back to X
OH → Sets OnOff State back to ON

Log:

2022-06-10 08:23:43.269 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: OnCommand [On/Off: 0000/0 -> C934/4, cluster=0006, TID=AC]
2022-06-10 08:23:43.496 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: DefaultResponse [On/Off: C934/4 -> 0000/1, cluster=0006, TID=AC, commandIdentifier=1, statusCode=SUCCESS]
2022-06-10 08:23:43.547 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [On/Off: C934/4 -> 0000/1, cluster=0006, TID=23, reports=[AttributeReport [attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=true]]]
2022-06-10 08:23:43.254 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' received command ON
2022-06-10 08:23:43.507 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 0 to 100
2022-06-10 08:23:43.509 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from OFF to ON
2022-06-10 08:23:43.561 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 100 to 0
2022-06-10 08:23:43.564 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from ON to OFF
2022-06-10 08:23:45.565 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Level Control: C934/4 -> 0000/1, cluster=0008, TID=24, reports=[AttributeReport [attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, attributeValue=111]]]
2022-06-10 08:23:45.577 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 0 to 44
2022-06-10 08:23:45.579 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from OFF to ON
...
2022-06-10 08:28:00.380 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - TX CMD: MoveToLevelWithOnOffCommand [Level Control: 0000/0 -> C934/4, cluster=0008, TID=B3, level=127, transitionTime=10]
2022-06-10 08:28:00.664 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: DefaultResponse [Level Control: C934/4 -> 0000/1, cluster=0008, TID=B3, commandIdentifier=4, statusCode=SUCCESS]
2022-06-10 08:28:00.795 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [On/Off: C934/4 -> 0000/1, cluster=0006, TID=2B, reports=[AttributeReport [attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=true]]]
2022-06-10 08:28:00.361 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' received command 50
2022-06-10 08:28:00.676 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 0 to 50
2022-06-10 08:28:00.679 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from OFF to ON
2022-06-10 08:28:00.806 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 50 to 0
2022-06-10 08:28:00.808 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from ON to OFF
2022-06-10 08:28:02.797 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Level Control: C934/4 -> 0000/1, cluster=0008, TID=2C, reports=[AttributeReport [attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, attributeValue=127]]]
2022-06-10 08:28:02.811 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 0 to 50
2022-06-10 08:28:02.813 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from OFF to ON

Why does OH turns the device ON, then OFF and then ON again? Same thing with levels, sets the device to Level X, then OFF, then back to Level X?

Test#2: Initiate actions from Device
EP1: N/A
EP2: N/A
EP3: N/A
EP4: Change level using rotary encoder - OK
Note: The OH behavior mentioned above does not occur in this scenario.
Log:

2022-06-10 08:31:20.365 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [On/Off: C934/4 -> 0000/1, cluster=0006, TID=37, reports=[AttributeReport [attributeDataType=BOOLEAN, attributeIdentifier=0, attributeValue=true]]]
2022-06-10 08:31:22.448 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Level Control: C934/4 -> 0000/1, cluster=0008, TID=38, reports=[AttributeReport [attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, attributeValue=34]]]
2022-06-10 08:31:22.462 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 0 to 13
2022-06-10 08:31:22.464 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTSwitch' changed from OFF to ON
2022-06-10 08:31:32.526 [DEBUG] [tsystems.zigbee.ZigBeeNetworkManager] - RX CMD: ReportAttributesCommand [Level Control: C934/4 -> 0000/1, cluster=0008, TID=39, reports=[AttributeReport [attributeDataType=UNSIGNED_8_BIT_INTEGER, attributeIdentifier=0, attributeValue=60]]]
2022-06-10 08:31:32.538 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ACMEZigbeeDevice_DIMMABLELIGHTLevelControl' changed from 13 to 24

Agreed - we discussed this in the past and opened an issue -:

I’ve not personally looked at this and I guess no-one else has either, so it has remained open. You are also of course welcome to provide a PR since it seems you have the only devices affected by this issue :slight_smile:

I’m not 100% sure - there doesn’t seem to be much in the log, but I can guess that it might have something to do with the core updating values as well as the binding. If the binding changes the state, then it logs as follows -:

    protected void updateChannelState(State state) {
        logger.debug("{}: Channel {} updated to {}", endpoint.getIeeeAddress(), channelUID, state);

        thing.setChannelState(channelUID, state);
    }

I don’t see this in your log. It also seems some other log entries I would expect to see are missing so I’m wondering if you have provided the full logs or if this is filtered in some way?

Sorry, I had filtered the logs by ‘Item|CMD’. But I ran the same tests to capture logs. See attached.

events.log (5.7 KB)
openhab.log (130.4 KB)

Also, regarding the PR, if you think that’s the best way, then perhaps but all I’m asking is to follow the Zigbee spec, nothing custom. BTW, there’s no issue with Hubitat nor HomeAssistant with an EP with LevelControl without On/Off cluster.

My project which I will release as opensource, is simply an Digi XBee3 communicating via serial with an MCU via API (So far tested with Atmega328 and TeensyLC).

I’m using OH as a baseline of which Clusters to support and so far, it supports most of the common clusters (Basic, Identify, PowerControl, On/Off, LevelControl, as well as temperature, humidity, pressure and illuminance meausrements, etc). The way I’m testing the LevelControl is simply using a Servo or an LED. Obviously the LED acts as a dimmer, but the servo acts as a generic Lever/Leveler (could be a gate, a bridge, a valve actuator, etc) so has no need for an On/Off button. For example, in my case, I control all my venitian blinds (tilt only) with the Servo. Next is to control my pool actuators to control the flow of my pool waterfall.

Right now, as a workaround I’m including On/Off clusters in the EPs so that it works with OH, but it’s a waste of precious flash/memory on the MCUs because there’s no use for applications that only require LevelControl commands. And the same thing could apply to OH, because if LevelControl requires On/Off cluster, then all the OH code to handle LevelControl commands 0x00 to 0x04 will never get used because OH will only send 0x05 and higher commands ((LevelControl with OnOff).

Sure, and I agreed with you in the previous discussion, it it wont change by magic - there MUST be a PR to make the changes in the binding.

So while I 100% agree this is an improvement and would bring it inline with the spec, someone still needs to actually do the change and I’ve had limited time. The fact is that this is not a common use case since it only seems to impact your custom device, so it’s just not made it to the top of my todo list unfortunately.

At some stage that may change and I will try and find time to create a PR for this, but all I’m suggesting above is that as this is an open source project, you could also consider providing a PR yourself.

100% in agreement. Where do I go to create the PR and what is the process?

Have you had a chance to take a look at the last logs that I uploaded to see why On/Off/On behavior is happening?

It’s probably worth having a read of the OH developer documents since first you’d need to make the modifications to the binding before creating the PR. There are also loads of resources on the web on how to use Git and GitHub, but it’s relatively simple - just fork the binding, commit the modifications to your fork (you can create a new branch, which is best, or just commit to the main branch) and then push it to GitHub. Go to your GitHub fork and it should ask you if you want to create a PR for the changes you’ve just pushed.

Sorry - no I’ve not had the chance as I was travelling most of this week. I will try and look over the next few days.

I guess this here is the part of the log you have an issue with -:

What happens is the following…

  • You send the command
  • When the command completes, we assume that this is an ack, so the value is updated (to 80)
  • It then receives the ON response, and I guess something here says the previous value was 0, so it sets it to 0 again.
  • It then receives the report of 80, so updates the value to 80.

The issue is on the second point - when the command completes we assume it has been received - and actioned by the device. The converter keeps a local variables to remember the state/value of the device so it can ignore the level reports if the device is off and set to the appropriate level when it comes on, and this needs to somehow be updated. The difficulty is that there’s a separate (common) handler for setting the state when the ack comes in and I need to find a way to call back in to the converter.

If the ON response is the ReportAttribute for OnOff set to ON (true), why would it set the dimmer to 0? I could understand if the report value was OFF(false). and If the OnOff state is now ON, it should change the dimmer value to the last dimmer value (OnLevel), which in this case is 80. So, that part doesn’t make sense.

And according to the spec, when MoveToLevelWithOnOff Command has an effect on OnOff cluster (changes its state), a report for OnOff must also be sent. So sending the OnOff report is the correct behavior since we are going from Off to On.

Also notice this behavior does not happen when the Off command or Move to Level 0 commands are sent even though that same sequence of events happen.

As above, there are some local variables that hold the last known state, so that (for example) when the ON report is received, the channel state can be set to the last known level (which is what would happen in the device when the ON report is sent). In this case, the last known level was 0, so it gets set to 0.

Yes, as above, I have said that this is a bug in the binding and the way it manages these local variables. I didn’t say, or mean to imply there was anything wrong with the reports from the device.

Again - it all comes down to these local variables. I think you will just have to take my word for it :slight_smile:

I’m working on a fix for this but it requires a bit of a rewrite of the management of command completion in the binding.

I’ve created a fix for this issue -:

1 Like