Firmware bug: defaultLevelRemote does not work

Switches General Discussion
, ,
1

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:

  1. Turn on switch remotely.
  2. Set brightness to 25.
  3. Turn off remotely.
  4. 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.

2

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

Thx

3

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.

1 Like
4

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?

5

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.

6

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'.

1 Like
7

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

8

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 > > >

2 Likes
9

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?

10

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.

11

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!

12

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.

2 Likes
13

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

1 Like
14

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”

15

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.

1 Like
16

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?

17

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.

1 Like