[question] Device only update status after tapping (off) twice (manual)

[lee-costa]

I have this switch and noticed that it's OFF status will only update in Home Assistant after tapping it twice. So for example, turn on switch manually, HA shows correct status. Turn off switch manually, HA shows switch as ON. Tap off again and HA updates correctly.

I read about pooling but not sure if this is what I want. If so, what is a good pooling interval to configure? I plan on doing this to a total of 3 devices. I am aware of the consequences but should I worry even if only pooling 3 devices?

[robertsLando]

I think it's a device issue as device is not reporting its status, please attach zwavejs logs

[lee-costa]

I think it's a device issue as device is not reporting its status, please attach zwavejs logs

Attached
zwavejs2mqtt-store.zip

[lee-costa]

And by the way, this also happens when turning on this (and other two switches)

Screen.Recording.2022-02-08.at.10.24.38.AM.mov

switch:

[robertsLando]

@AlCalzone

[AlCalzone]

Which Node ID am I looking for? When (time and timezone) did you interact with it? The log is 77k lines long :)

[lee-costa]

@AlCalzone I have generated a new log file and you will find it attached. I purposely interacted with the device between 5:58pm and 6:10pm today (eastern time) and the Node ID is Device ID 99-12337-18756 (0x0063-0x4944-0x3031). The same behavior is still noticed.

Thank you.
zwavejs2mqtt-store.zip

---

edit

I believe the correct ID is 31.

[AlCalzone]

In the time frame you mention I see a couple of these interactions:

2022-02-09T23:02:03.600Z DRIVER « [Node 031] [REQ] [ApplicationUpdateRequest]
                                    payload: 0x1f0a04110126277370867277
2022-02-09T23:02:03.601Z CNTRLR « [Node 031] Received updated node info
2022-02-09T23:02:03.601Z CNTRLR   [Node 031] Node does not send unsolicited updates; refreshing actuator and sen
                                  sor values...
2022-02-09T23:02:03.602Z CNTRLR » [Node 031] requesting current switch state...
2022-02-09T23:02:03.604Z DRIVER » [Node 031] [REQ] [SendData]
                                  │ transmit options: 0x25
                                  │ callback id:      166
                                  └─[MultilevelSwitchCCGet]
...
2022-02-09T23:02:03.648Z CNTRLR   [Node 031] [~] [Multilevel Switch] currentValue: 2 => 97          [Endpoint 0]
2022-02-09T23:02:03.654Z DRIVER « [Node 031] [REQ] [ApplicationCommand]
                                  └─[MultilevelSwitchCCReport]
                                      current value: 97

Or in plain english:
device: "hey there is something new!"
zwave-js: "okay whats your status?"
device: "I'm currently at level 97"

---

Most of these are just a tiny bit off the limits of fully off (2 or 3 instead of 0) or fully on (97 instead of 99). I think this is a timing issue. The device isn't done dimming when its status is refreshed, so the status ends up as "almost off" instead of off.

We have a compat flag to delay these refreshes, I'm going to try with 250ms which shouldn't feel too long but long enough to avoid the half-dimmed states.

[AlCalzone]

@zwave-js-bot add compat flag to 0x0063:0x4944:0x3031:3.37

manualValueRefreshDelayMs: 250

[zwave-js-bot]

🔨 I created a PR at #4221 - check it out!

[AlCalzone]

@junior466 If you have zwavejs2mqtt installed, you can test this file by following this guide and let me know if that works.

If not, also let me know - then I'll just merge and you can test on the next update.

[lee-costa]

@AlCalzone Thanks for the prompt (possible) fix. I will try it as soon as I can today. And just to be sure, where will my ‘app-root’ be if installed using Snap on Ubuntu?

[AlCalzone]

@jmgiaever?

[jmgiaever]

/var/snap/zwavejs2mqtt/<revision>/ where each revision contains data (backup) from each. You should most likely use the highest revision, or the symlink current.

[lee-costa]

So inside there should be a ‘store’ folder where I create a ‘config’ folder and upload? Apologies but away from desk.

[jmgiaever]

Hi, no, that folder is your «store folder». Everything essential is created by z2m itself, but if you need to store config files, use the config folder specified in the «config priority path» within the zwave section in the setting. In my case it's set to (by default): /var/snap/zwavejs2mqtt/340/config.

However this path is not automatically created. Create it with sudo mkdir <path you have>.

Note that 340 is the revision number. Snap will increase/decrease this value whenever you're upgrading or downgrading.

For what I'm aware you're not able to upload files through the Z2M UI. If you have to upload from your local computer, use scp or something like that to upload it to your server in an SSH like way

scp /my/local/file username@my-host:<path you have>

EDIT: Note «username» needs root access to write to this directory (<path you have>). You might just scp it to this users home dir (e.g scp /my/local/file username@my-host:~, ~ is important) and then log in with SSH and move it with sudo mv ~/file <path you have>.

[AlCalzone]

You can edit files in the UI, which is enough in this case
#4188 (comment)

[lee-costa]

@AlCalzone I have followed the instructions but no luck. Attached are the logs. I tried it a couple times between 7:10PM and 7:30PM eastern time.

One thing I didn't do is re-interview that device as per the guide since I was afraid of loosing my configuration. If it must be done, let me know and I will try it.

zwavejs2mqtt-store.zip

[AlCalzone]

Doesn't look like the config was applied. Did you restart zwavejs2mqtt? If so, please keep logging enabled there and download the logfile from the store after restarting so I can see what happens during startup.

[lee-costa]

I made sure to restart it at the command line after clicking save. I have logging enabled since yesterday. I just finished restarting and attached the logs. I interacted with the switch today between 4:20PM and 4:25PM eastern time.
zwavejs2mqtt-store.zip

[lee-costa]

@AlCalzone Anything else you recommend I try? Any more logs needed?

[AlCalzone]

2022-02-11T21:23:19.367Z CNTRLR   [Node 031] Node does not send unsolicited updates; refreshing actuator and sen
                                  sor values in 250 ms...
2022-02-11T21:23:19.617Z CNTRLR » [Node 031] requesting current switch state...

Looks like the change was applied, but maybe 250 ms is still not enough. How long does that device need for dimming?

You could try changing

"manualValueRefreshDelayMs": 250

at the end of the file to

"manualValueRefreshDelayMs": 1000

or maybe even

"manualValueRefreshDelayMs": 2000

and see if this gets better after restarting zwavejs2mqtt.

[lee-costa]

So I tried all those three values and neither has worked (made sure to click "save" and restart zwavejs2mqtt.zwavejs2mqtt service). One thing I just noticed though is that when I tap the switch to turn off, it dims itself to 80 and stops there (what home assistant sees). The actual light in the ceiling already shows as off. I recorded a video of the behavior using Home Assistant:

edit - The reason it eventually goes to the "off" state is because I tap it a second time after turning it off. So in the video, I tap it to ON, then tap it to OFF then at this point the light is off but Home Assistant shows it ON still so a third tap gets it to OFF.

Screen.Recording.2022-02-15.at.8.44.08.AM.mov

[AlCalzone]

Can you try something ridiculously long, like 10000? I wonder if the delay has any influence on how close the reported value is to the actual brightness.

Also how is the dimming configured?

[lee-costa]

Yes, the value of 10000 works! And here's what I see:

[AlCalzone]

Ok I'm not 100% sure how to interpret these settings. Maybe @blhoward2 has a better idea?
If this means each dim level changes the brightness by 1 and takes 30ms for each step, then dimming down from 99 to 0 would take almost 3 seconds. This would mean that a value of 3000 or higher should work.

[blhoward2]

This means it should take one 30ms step. I just confirmed that's what mine are set to and they barely ramp down at all. It's practically instant.

I'm not sure the compat flag is the issue. I've seen this exact behavior but only at certain combinations of original dim level and step/timing. And not in a way that makes sense either. It seems that going down too many levels too fast is a larger issue then catching it mid-ramp.

Some of the GE switches are a bit buggy when it comes to steps and the brightness level they're originally at. One of mine won't go the whole way off if it is below 20% and set to take more than one step, even at the switch. Another of the same model works fine. I'd play around with the settings before the config file.

[AlCalzone]

Interesting... we should definitely mention this in the device config comments when we can pin the issue down further.

[lee-costa]

So what @blhoward2 said is I should change the step to 30ms? What setting exactly? There are multiple Dim Rate Steps.

[blhoward2]

It’s already at 30 ms. The unit is 10ms. There are two that matter. Manual is the local switch. Zwave is zwave. I’d try two or three steps at 30 ms. Then if that doesn’t work try 1-3 steps at 10 ms. Too slow and the get will catch it on the ramp but just play around with it.

If you can’t find a combination that you’re happy with, try setting up an automation that is triggered by the brightness changing and have it refresh the device using the refresh service after a second or two. Just do a trigger on the brightness attribute. While it’s staying on I’m assuming the level changes to something else in HA.

I’ve also had this behavior go away after a factory reset. So you might try that too.

[lee-costa]

I think I want to try a factory reset before going further just in case. Should I just reset the switch manually or do I need to do anything from within the control panel?

[blhoward2]

Do it at the switch. Then replace failed node and include it again.

[lee-costa]

So I configured Dim Rate Steps (Z-Wave Command) to 2 and Dim Rate Steps (Manual) to 2 and later tried a value of 3 on each and no luck. Instead the brightness goes to 18 when turned on and 240 when turned off.

edit - Also tried a factory reset and no luck.

[AlCalzone]

@junior466 did you get this resolved somehow? I'm not convinced that the linked PR is the correct fix for this, so I'll probably not merge it.

[lee-costa]

The suggestion here has been working fine.

[AlCalzone]

Ok thanks. I'm hesitant to use this as the "official" fix though, since you seem to be the only one so far with the problem.

[lee-costa]

@AlCalzone I recently updated HA to the latest version and zwavejs2mqtt to version 6.9.1 and noticed that now the issue is back on ONLY on the devices that the fix hasn't been applied to. In other words, the switches I applied the fix above work as expected.

[lee-costa]

It appears that the issue is only with a WD500Z-1 switch. Manual control doesn't update Home Assistant at all. I tried resetting the switch and re-pairing it.

[AlCalzone]

Could be that you need to set up a lifeline association from the switch to the controller. For some older switches, zwave-js doesn't know which association would be needed.

[lee-costa]

So recently I migrated from the SNAP package version to a docker compose file. Brought back all of my devices but noticed the issue was back. I followed the steps again and configured the JSON file "manualValueRefreshDelayMs": value to 30000 but nothing this time.

Attached are my logs and here is my device configuration screen.
zwavejs_current.log

[lee-costa]

...and figured out the solution again by going through the comments. The sweet spot for me is setting manualValueRefreshDelayMs: to 3000. Here's the json file with this already set.

Hopefully this helps someone (and myself) down the road.
ZW3003.json.zip