Zwave2mqtt: Dimmer switch state doesn't update when turned off[bug]
Version
Build/Run method
- [x] Docker
Zwave2Mqtt version: 1.2.3
Openzwave Version: 1.4.1
Describe the bug
I am using a GE Z-Wave Plus Smart Motion Dimmer,
I have the motion detection working fine,
The problem is with the dimmer switch.
Whenever I publish 99 to 2/38/1/0/set (brightness), the light turns on and the state 2/38/1/0 change to 99 as expected,
But whenever I turn it off, I publish 0 to 2/38/1/0/set, the light turns off, but the state remains at 99.
Only once I have published the command a second time the state changes to 0.
To Reproduce
Steps to reproduce the behavior:
- Publish 0 to 2/38/1/0/set
- Notice the state of the switch doesn't change to 0 the first time.
- Publish the same command a second time, then the state of the switch change to 0.
Expected behavior
I was expecting the state of the switch to change to 0.
As it did change to 99 when I turn it on.
Seb788
All 10 comments
I have tried removing the node and readding it without success.
I have tried changing polling intensity and also verifying changes too.
The state eventually change to 0 after the 60 second polling.
here is my log when I publish 0 to 3/38/1/0/set
Thanks for your help
``
2019-08-23T18:30:27.917Z z2m:Mqtt Message received on zwave/Kitchen/kitchen_dimmer/brightness/set
2019-08-23 12:30:27.918 Info, Node003, Value::Set - COMMAND_CLASS_SWITCH_MULTILEVEL - Level - 0 - 1 -
2019-08-23 12:30:27.918 Info, Node003, SwitchMultilevel::Set - Setting to level 0
2019-08-23 12:30:27.918 Info, Node003, Duration: Default
2019-08-23 12:30:27.918 Detail, Node003, Queuing (Send) SwitchMultilevelCmd_Set (Node=3): 0x01, 0x0b, 0x00, 0x13, 0x03, 0x04, 0x26, 0x01, 0x00, 0xff, 0x25, 0x29, 0x34
2019-08-23 12:30:27.918 Detail, Node003, Queuing (Send) SwitchMultilevelCmd_Get (Node=3): 0x01, 0x09, 0x00, 0x13, 0x03, 0x02, 0x26, 0x02, 0x25, 0x2a, 0xcf
2019-08-23 12:30:27.918 Detail,
2019-08-23 12:30:27.918 Info, Node003, Sending (Send) message (Callback ID=0x29, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=3): 0x01, 0x0b, 0x00, 0x13, 0x03, 0x04, 0x26, 0x01, 0x00, 0xff, 0x25, 0x29, 0x34
2019-08-23 12:30:27.925 Detail, Node003, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2019-08-23 12:30:27.926 Detail, Node003, ZW_SEND_DATA delivered to Z-Wave stack
2019-08-23 12:30:27.946 Detail, Node003, Received: 0x01, 0x07, 0x00, 0x13, 0x29, 0x00, 0x00, 0x02, 0xc0
2019-08-23 12:30:27.946 Detail, Node003, ZW_SEND_DATA Request with callback ID 0x29 received (expected 0x29)
2019-08-23 12:30:27.946 Info, Node003, Request RTT 28 Average Request RTT 28
2019-08-23 12:30:27.946 Detail, Expected callbackId was received
2019-08-23 12:30:27.946 Detail, Expected reply was received
2019-08-23 12:30:27.946 Detail, Message transaction complete
2019-08-23 12:30:27.947 Detail,
2019-08-23 12:30:27.947 Detail, Node003, Removing current message
2019-08-23 12:30:27.947 Detail,
2019-08-23 12:30:27.947 Info, Node003, Sending (Send) message (Callback ID=0x2a, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=3): 0x01, 0x09, 0x00, 0x13, 0x03, 0x02, 0x26, 0x02, 0x25, 0x2a, 0xcf
2019-08-23 12:30:27.954 Detail, Node003, Received: 0x01, 0x04, 0x01, 0x13, 0x01, 0xe8
2019-08-23 12:30:27.955 Detail, Node003, ZW_SEND_DATA delivered to Z-Wave stack
2019-08-23 12:30:27.975 Detail, Node003, Received: 0x01, 0x07, 0x00, 0x13, 0x2a, 0x00, 0x00, 0x02, 0xc3
2019-08-23 12:30:27.975 Detail, Node003, ZW_SEND_DATA Request with callback ID 0x2a received (expected 0x2a)
2019-08-23 12:30:27.975 Info, Node003, Request RTT 28 Average Request RTT 28
2019-08-23 12:30:27.975 Detail, Expected callbackId was received
2019-08-23 12:30:27.988 Detail, Node003, Received: 0x01, 0x09, 0x00, 0x04, 0x00, 0x03, 0x03, 0x26, 0x03, 0x63, 0xb4
2019-08-23 12:30:27.989 Detail,
2019-08-23 12:30:27.989 Info, Node003, Response RTT 41 Average Response RTT 41
2019-08-23 12:30:27.989 Info, Node003, Received SwitchMultiLevel report: level=99
2019-08-23 12:30:27.989 Detail, Node003, Refreshed Value: old value=99, new value=99, type=byte
2019-08-23 12:30:27.989 Detail, Node003, Changes to this value are verified
2019-08-23 12:30:27.989 Detail, Node003, Expected reply and command class was received
2019-08-23 12:30:27.989 Detail, Node003, Message transaction complete
2019-08-23 12:30:27.989 Detail,
2019-08-23 12:30:27.989 Detail, Node003, Removing current message
2019-08-23 12:30:27.989 Detail, Node003, Notification: ValueRefreshed
2019-08-23T18:30:27.989Z z2m:Zwave zwave node 3: changed: 38-1-0:Level:99 -> 99
Seb788
on 23 Aug 2019
@Fishwaldo
robertsLando
on 26 Aug 2019
It’s reporting instant values and not target value. In OZW 1.6 please use the Target ValueID or enable verifychanged option.
(Some dimmers etc don’t updated the Value as it’s a slow ramp up/down)
Fishwaldo
on 26 Aug 2019
@Seb788 You can enable verifyChanges using gateway values table or mqtt apis
robertsLando
on 27 Aug 2019
Thanks I will give it a try
Seb788
on 27 Aug 2019
It would appear that the latest docker image for zwave2mqtt does not include OZW 1.6:
Initialising OpenZWave 1.4.3493 binary addon for Node.JS. Is there a different build of zwave2mqtt I'm missing to allow us to use target value?
I have attempted to enable verify changes in the device table as seen below:
This however is not reliable (about half of the 9 lights report back the correct final value). In the HASS implementation this is worked around by having an automatic delayed refresh available:
https://www.home-assistant.io/docs/z-wave/installation/#refresh_value
Would it make sense to add this as an option for the device gateway table in zwave2mqtt to alleviate the same issues @robertsLando ?
brilthor
on 29 Dec 2019
I also was caught by the versions, however:
https://github.com/robertsLando/Zwave2Mqtt-docker#tags
Available Tags:
latest: Always points to the latest version published using OZW 1.4
latest-dev: Always points to the latest version published using OZW 1.6
j3kestrel
on 10 Jan 2020
I don't see a latest-dev tag in docker hub. Either the documentation is wrong or the tag is missing for some reason.
chilicheech
on 10 Jan 2020
I hadn't gotten that far, but you're right. It looks like latest is 2.0.6 and the only 2.1.0 is an amd64-2.1.0-dev, posted just 5 hrs ago. There is a 2.0.6-dev plus some additional arm variants which might be what a latest-dev would be at this time?
j3kestrel
on 10 Jan 2020
Sorry guys I had release version 2.1.0 yesterday and the build process has fail on arm archs, I’m tring to fix the problem and release it asap
Daniel
On 10 Jan 2020, at 02:15, j3kestrel notifications@github.com wrote:

I hadn't gotten that far, but you're right. It looks like latest is 2.0.6 and the only 2.1.0 is an amd64-2.1.0-dev, posted just 5 hrs ago. There is a 2.0.6-dev plus some additional arm variants which might be what a latest-dev would be at this time?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
robertsLando
on 10 Jan 2020
Related issues
hostrup
·
4Comments
raspberrypython
·
5Comments
LordMike
·
3Comments
magpern
·
7Comments
dooz127
·
3Comments
Most helpful comment
It would appear that the latest docker image for zwave2mqtt does not include OZW 1.6:
Initialising OpenZWave 1.4.3493 binary addon for Node.JS.Is there a different build of zwave2mqtt I'm missing to allow us to use target value?I have attempted to enable verify changes in the device table as seen below:
This however is not reliable (about half of the 9 lights report back the correct final value). In the HASS implementation this is worked around by having an automatic delayed refresh available:
https://www.home-assistant.io/docs/z-wave/installation/#refresh_value
Would it make sense to add this as an option for the device gateway table in zwave2mqtt to alleviate the same issues @robertsLando ?