Firmware bug: defaultLevelRemote does not work

Glenn · November 21, 2022, 4:22am

Using latest z2m as an external_converter (so very latest from GitHub) and 2.08. When I configure defaultLevelRemote to 254 I understand that it means when I turn on the switch remotely that the switch will go to brightness 254. What happens is that the switch turns on at the previous brightness level.

All tests were done using z2m (not Home Assistant).

Test sequence in z2m:

Turn on switch remotely.
Set brightness to 25.
Turn off remotely.
Turn on remotely. I expect switch to go to 254. It goes to 25 brightness.

defaultLevelLocal works as intended and goes to full brightness when pressing the top paddle.

Glenn · November 28, 2022, 2:28am

@EricM_Inovelli Checking that this was seen and if you need help reproducing.

Thx

mamber · November 28, 2022, 3:33am

EDIT:

At first, I thought I was seeing the same thing on Hubitat, but I reset/cleared all settings and now I can’t reproduce the problem. Seems to be working properly for me after resetting everything.

EricM_Inovelli · November 28, 2022, 10:39pm

I tested this in SmartThings and Hubitat on 2.08 and did not see the same behavior. I am seeing the problem with z2m though. Is it possible that z2m is sending a level cluster command instead of an on/off?

Glenn · November 28, 2022, 10:54pm

I’m not sure how to check which command is sent. Perhaps the z2m debug logs would have something. I’ll poke at debug logging and see what I learn.

Glenn · November 28, 2022, 11:03pm

Here are the debug logs, not sure if it answers your question.

Zigbee2MQTT:debug 2022-11-28 17:59:36: Received MQTT message on 'zigbee2mqtt/InoTest/set' with data '{"state":"ON"}'
Zigbee2MQTT:debug 2022-11-28 17:59:36: Publishing 'set' 'state' to 'InoTest'
Zigbee2MQTT:debug 2022-11-28 17:59:36: Received Zigbee message from 'InoTest', type 'attributeReport', cluster 'genOnOff', data '{"onOff":1}' from endpoint 1 with groupID 0
Zigbee2MQTT:info  2022-11-28 17:59:36: MQTT publish: topic 'zigbee2mqtt/InoTest', payload '{"action":null,"activeEnergyReports":null,"activePowerReports":null,"autoTimerOff":null,"brightness":254,"buttonDelay":"300ms","defaultLevelLocal":254,"defaultLevelRemote":254,"doubleTapClearNotifications":null,"doubleTapUpForFullBrightness":null,"energy":0.05,"firmwareUpdateInProgressIndicator":null,"invertSwitch":null,"linkquality":109,"loadLevelIndicatorTimeout":null,"localProtection":null,"maximumLevel":null,"minimumLevel":null,"onOffLedMode":null,"outputMode":0,"periodicPowerAndEnergyReports":null,"power":0,"powerType":null,"relayClick":1,"remoteProtection":null,"smartBulbMode":null,"state":"ON","stateAfterPowerRestored":255,"switchType":null,"update":{"state":"idle"},"update_available":false}'
Zigbee2MQTT:debug 2022-11-28 17:59:36: Received Zigbee message from 'InoTest', type 'readResponse', cluster 'manuSpecificInovelliVZM31SN', data '{"rampRateOffToOnRemote":127}' from endpoint 1 with groupID 0
Zigbee2MQTT:info  2022-11-28 17:59:36: MQTT publish: topic 'zigbee2mqtt/InoTest', payload '{"action":null,"activeEnergyReports":null,"activePowerReports":null,"autoTimerOff":null,"brightness":254,"buttonDelay":"300ms","defaultLevelLocal":254,"defaultLevelRemote":254,"doubleTapClearNotifications":null,"doubleTapUpForFullBrightness":null,"energy":0.05,"firmwareUpdateInProgressIndicator":null,"invertSwitch":null,"linkquality":109,"loadLevelIndicatorTimeout":null,"localProtection":null,"maximumLevel":null,"minimumLevel":null,"onOffLedMode":null,"outputMode":0,"periodicPowerAndEnergyReports":null,"power":0,"powerType":null,"relayClick":1,"remoteProtection":null,"smartBulbMode":null,"state":"ON","stateAfterPowerRestored":255,"switchType":null,"update":{"state":"idle"},"update_available":false}'
Zigbee2MQTT:debug 2022-11-28 17:59:37: Received Zigbee message from 'InoTest', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":106}' from endpoint 1 with groupID 0
Zigbee2MQTT:info  2022-11-28 17:59:37: MQTT publish: topic 'zigbee2mqtt/InoTest', payload '{"action":null,"activeEnergyReports":null,"activePowerReports":null,"autoTimerOff":null,"brightness":254,"buttonDelay":"300ms","defaultLevelLocal":254,"defaultLevelRemote":254,"doubleTapClearNotifications":null,"doubleTapUpForFullBrightness":null,"energy":0.05,"firmwareUpdateInProgressIndicator":null,"invertSwitch":null,"linkquality":109,"loadLevelIndicatorTimeout":null,"localProtection":null,"maximumLevel":null,"minimumLevel":null,"onOffLedMode":null,"outputMode":0,"periodicPowerAndEnergyReports":null,"power":10.6,"powerType":null,"relayClick":1,"remoteProtection":null,"smartBulbMode":null,"state":"ON","stateAfterPowerRestored":255,"switchType":null,"update":{"state":"idle"},"update_available":false}'
Zigbee2MQTT:debug 2022-11-28 17:59:37: Received Zigbee message from 'InoTest', type 'attributeReport', cluster 'haElectricalMeasurement', data '{"activePower":106}' from endpoint 1 with groupID 0
Zigbee2MQTT:info  2022-11-28 17:59:37: MQTT publish: topic 'zigbee2mqtt/InoTest', payload '{"action":null,"activeEnergyReports":null,"activePowerReports":null,"autoTimerOff":null,"brightness":254,"buttonDelay":"300ms","defaultLevelLocal":254,"defaultLevelRemote":254,"doubleTapClearNotifications":null,"doubleTapUpForFullBrightness":null,"energy":0.05,"firmwareUpdateInProgressIndicator":null,"invertSwitch":null,"linkquality":109,"loadLevelIndicatorTimeout":null,"localProtection":null,"maximumLevel":null,"minimumLevel":null,"onOffLedMode":null,"outputMode":0,"periodicPowerAndEnergyReports":null,"power":10.6,"powerType":null,"relayClick":1,"remoteProtection":null,"smartBulbMode":null,"state":"ON","stateAfterPowerRestored":255,"switchType":null,"update":{"state":"idle"},"update_available":false}'

It looks like an on/off is used, put the publish just shows Publishing 'set'.

Glenn · November 28, 2022, 11:06pm

Another “I wonder” is what does ST and Hubitat send. Is it On/Off?

EricM_Inovelli · November 29, 2022, 6:37pm

Hubitat is using the on/off cluster (zigbee.on). I’m guessing that SmartThings does the same, but our driver is using the built in on/off handling so I cannot see the code.

Edit: Looked at the ST logs. It is using the on/off cluster and is sending the command 0x01 to turn the switch on:

2022-11-29T18:37:54.195743036+00:00 INFO Inovelli 2-in-1 Blue Series <ZigbeeDevice: 19fd1dc3-22a3-4c0f-a83f-06242e2660b0 [0x6D43] (Inovelli 2-in-1 Blue Series Two)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x6D43, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, lqi: 0xCA, rssi: -72, body_length: 0x0005, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x0C, ZCLCommandId: 0x0B >, < DefaultResponse || cmd: 0x01, ZclStatus: SUCCESS > > >

Glenn · November 29, 2022, 8:02pm

I need help to debug further. If I were to guess, and this is just a gut feel, I do not suspect that a level cluster command is being used. I say this because z2m issues on/off commands to other devices just fine. But, I don’t know how to find out what is being sent. Here is my annotations on the log when I click the on/off toggle in z2m:

I click and this is the message that is sent from the web front end to z2m:

Zigbee2MQTT:debug 2022-11-29 14:53:03: Received MQTT message on 'zigbee2mqtt/InoTest/set' with data '{"state":"ON"}'

Next I see that z2m is publishing a set state. I assume, but I don’t know, this is writing to the switch over Zigbee. It’s a pretty weak debug message, especially given the message that follows it.

Zigbee2MQTT:debug 2022-11-29 14:53:03: Publishing 'set' 'state' to 'InoTest'

The next message, seems clear. Seems like the cluster I would expect.

Zigbee2MQTT:debug 2022-11-29 14:53:03: Received Zigbee message from 'InoTest', type 'attributeReport', cluster 'genOnOff', data '{"onOff":1}' from endpoint 1 with groupID 0

And finally, the publishing of the change to the MQTT bus. Again, as expected. Confirmation that the level is 33 and not 254 as configured.

Zigbee2MQTT:info  2022-11-29 14:53:03: MQTT publish: topic 'zigbee2mqtt/InoTest', payload '{"action":null,"activeEnergyReports":null,"activePowerReports":null,"autoTimerOff":null,"brightness":33,"buttonDelay":"300ms","defaultLevelLocal":254,"defaultLevelRemote":254,"doubleTapClearNotifications":null,"doubleTapUpForFullBrightness":null,"energy":0.09,"firmwareUpdateInProgressIndicator":null,"invertSwitch":null,"linkquality":131,"loadLevelIndicatorTimeout":null,"localProtection":null,"maximumLevel":null,"minimumLevel":null,"onOffLedMode":null,"outputMode":0,"periodicPowerAndEnergyReports":null,"power":0,"powerType":null,"relayClick":1,"remoteProtection":null,"smartBulbMode":null,"state":"ON","stateAfterPowerRestored":255,"switchType":null,"update":{"state":"idle"},"update_available":false}'

Is there a z2m expert on these forums that could help out further?

EricM_Inovelli · November 29, 2022, 9:01pm

Yeah, it seems like the correct command is being sent. My only other thought then is that defaultLevelRemote is not being sent correctly. Seems strange that defaultLevelLocal would be ok then.

Glenn · December 9, 2022, 3:34am

This is still a problem. Are we sure that this is not a firmware issue? If so then I guess this needs to pursued with the z2m folks.

Is there anyone on the forums here that can help and debug further? I am willing to do some legwork but I need some direction on what to look for. Thx!

dahanc · December 9, 2022, 4:08am

FWIW, the default level - remote (parameter 14) works for me in ZHA, although the level slider in the UI goes to the previous level when I turn the light on instead of the level that the light is actually at.

I set parameter 14 to 10, opened the light control so it shows both the toggle switch and the brightness slider. The switch is on and I move the slider all the way to the right (100). When I toggle the switch off, the light turns off and the brightness slider goes all the way to the left. When I toggle it back on, the light is on dimly, but the slider goes back to 100. I can then drag the slider to some other level, and the light brightness will move to that level.

According to a Zigbee sniffer capture, ZHA is just sending a simple On/Off cluster “On” command to the switch.

The capture also shows that the switch is sending a Level Report back saying the current level is 10; seems like ZHA should pick that up and adjust the slider to the correct position.

mamber · December 9, 2022, 12:50pm

It works properly with the Hubitat drivers (and apparently ZHA and ST also). So that would indicate to me its not a firmware issue, but something particular to z2m

romamix · February 21, 2023, 4:20pm

I can see the similar issue with zigbee2mqtt. As a workaround, I have a flow in Node-RED where in the message payload I change “brightness” from “null” to an actual number when the “state” changes to “ON”

mathieu · April 15, 2023, 3:50pm

Turns out that z2m has some custom logic to handle the turn off with transition so it stores the last known brightness and transitions back to that value when turning back on. We can easily bypass this extra logic that ends up transforming a regular ON command into a moveToLevelWithOnOff by patching the converter. I am not totally confident in the solution yet but so far it’s behaving the way I expect it to.

Edit \zigbee2mqtt\node_modules\zigbee-herdsman-converters\devices\inovelli.js at around line 992:

                if (state === 'on' &&
          globalStore.getValue(entity, 'turnedOffWithTransition') === true
                ) {
                    /**
           * In case the bulb it turned OFF with a transition and turned ON WITHOUT
           * a transition, the brightness is not recovered as it turns on with brightness 1.
           * https://github.com/Koenkk/../issues/1073
           */

Change state === 'on' to state === 'ignore' so it completely skips that section and always falls back to the inovelliOnOffConvertSet logic.

This fix cannot be committed to the repo as is yet and thus must be performed (and updated manually again on updates).

Hope this helps.

Glenn · April 15, 2023, 4:14pm

Nice find @mathieu!

The code definitely conflicts with the option.

Do you know what has to happen to get this change (or one like it) into the code base?

mathieu · April 15, 2023, 5:08pm

Hard to say. I get the feeling that a good chunk of that code is copy paste, not applicable and can be ripped out, but I don’t know all the scenarios that others use the same devices.

You can change this yourself directly in your z2m install, restart z2m and the changes are immediate.

zhudhjen · November 17, 2023, 8:33am

Sorry to wake up this old thread. I’m getting the same issue that DefaultLevelRemore is not working. Is the aforementioned issue already fixed within Z2M or do I still need to manually patch it?

Edit: found the code still in there. And the fix above still works.

EricM_Inovelli · December 21, 2023, 11:38pm

Can confirm that this is still the behavior of z2m. To store the level if the switch is turned off via z2m and then use the “commandMoveToLevelWithOnOff” with the level specified instead of using “commandOn”. This makes it so that defaultLevelRemote does not work. I’m looking into making this change in the converter, but I am wondering if it will cause problems elsewhere. Especially considering the issue #1073 that is mentioned in the code comments.

EricM_Inovelli · December 26, 2023, 11:04pm

Looks like this bit of code may also be causing problems when turning a group of devices on / off. Zigbee2MQTT Groups Giving “rampRateOffToOnRemote” error? - Switches / General Discussion - Inovelli Community

Seems strange this code is being executed when a group is commanded, but looks like it is the same section in the converter that is causing problems.