What you are experiencing is the same I experienced over on Hubitat when they went from 1.4 to 1.6. All my Kwikset 888 zwave locks stopped being reliable. I moved to Yale yrd-110 locks and gave up on the kwikset as my home’s security outweighed waiting for the devs to get something fixed (was about 8mos when I threw in the towel). Just an FYI and hope your experience will be better here on HA.
Edit: I also thought you could change the hardware and make those secure Zigbee locks. Just another option.
Has anyone upgraded to ZWaveJS2MQTT 1.4.0?
Running core with docker and the ZWJS2MQTT container (using WS and not MQTT obviously…). Upgraded and lost a few entities in the ZWJS control panel (ones that are a pain to get info restored) and also could not get anything to talk to Home Assistant anymore, even after 30 minutes and some Home Assistant restarts. I downgraded to 1.2.3 (I think I was on 1.2.xx before) and rolled back my config folder and it seems to be coming back and talking now.
EDIT: Looks like an open issue now
EDIT 2: Basically 1.4.0 only works with the in the process of being released Home Assistant beta and forward.
I started migrating to zwavejs yesterday but found the delay to be obscenely long (~ 10 seconds) and wasn’t sure if it was maybe something with my existing zwave network, so I started up a test env with a second (clean) zwave stick and an extra zwave dimmer I wasn’t using. Originally couldn’t get the entities to appear but then read the messages right above mine and switched to v1.3.0 of zwavejs2mqtt and that solved the initial issue. It also seems that with just the simple 2 node network, the response is pretty much instantaneous, so I was thinking of rebuilding my network from scratch to see if it fixes the issues.
One thing I found at least for this dimmer is that the home assistant ui toggle button updates the state incorrectly for about 1-2 seconds. Is this a known issue? In the video below you can see that I toggle the light on, but the ui switches back off for a second or two and then corrects itself. The physical switch doesn’t exhibit any weird behavior, it turns on and ramps up the brightness over the desired ~1 second transition time.
Search the community and you will find this has always been a problem with Z-Wave.
The UI toggles because the state of the switch is not updated until 5 seconds later. Most switches do not report a level value when Set from a z-wave command. Zwave-js manually refreshes the value after 5 seconds. If your transition took longer than 5 seconds, the state would be wrong. In most cases 5 seconds is plenty.
This is an improvement over zwave/ozw, which refreshed the level value immediately after the Set command. In some cases this would result in the wrong brightness, in other cases the switch might be completely off because it hadn’t even started the transition. At least this 5 second delay is functional for most uses, it only results in a minor annoyance in the UI. The zwave integration had a hack in place that implemented the same refresh logic via configuration setting, but the UI toggle was still present.
If you turn on the switch with a specific brightness level, zwave-js will return that value back to HA right after sending the command, assuming the switch will end up in that target state. In that case HA will register the state change and the UI will stick. After 5 seconds later zwave-js will refresh the level in the same way as described above, verifying the change.
It is not possible for zwave-js to provide an optimistic value for a toggle command, or at least it chooses not to make something up. Prior to a toggle on, the level value is off. When you toggle it on, it doesn’t know what the target value is. Thus it only sends the refresh command which leaves time for the frontend to revert the toggle.
HA could mitigate by optimistically assuming some value on toggle (what would it be? 50%, 100%?), updating the state, then let zwave-js refresh it 5 seconds later with the actual value). Whatever brightness value it chooses (what does the frontend do now?) will be wrong in many cases, but at least the on/off state will be correct.
Thanks for the thorough explanation! I’m surprised I’ve never come across this in the 2-3 years I’ve been using HA (w/ the zwave 1.4 implementation).
I just added that dimmer to my production zwave 1.4 implementation and the UI behaves correctly, so I’m not sure exactly what is going on behind the scenes, but it seems there are some implementation differences between zwavejs and the old 1.4 implementation. I also tried altering the transition time of the switch itself to be shorter, but it seems that had no effect either.
Though this was posted for a zwavejs2mqtt installation, I suffered the same with the ZwaveJS core integration and add-on, which was updated to the latest version 0.1.8 today
I might be imagining things, but I could have swore that HA would update the devices / entities with their new information once the re-discovery was done.
I’m using a standalone ZWaveJSServer, not MQTT (only use mqtt for gui).
In my case I have a few nodes / devices that didn’t make it through the first round of discovery/interviews so they’re listed as “Unknown” in HA and ZWaveJS, I go back to ZWaveJSMQTT and re-interview, everything is fine and dandy there, but at that point nothing changes in HA.
Short of deleting the integration and start over I’m not sure how I can force it to update the devices ?
Edit, should have mentioned versioning…
HA 2021.3.0b0
ZWaveJS2MQTT 1.4.0
Zwavejs Version 6.5.0
Zwavejs-server 1.0.0
As stated previously in the thread, there are versions of ZwaveJS2MQTT that do not work with the released version of Home Assistant. If you updated your container, this is probably your issue. Downgrade ZwaveJS2MQTT to the version that was working or upgrade home assistant to 2021.3.beta. or update to the beta and use the Zwave JS addon.
Just upgraded to core-2021.3.0b0 and Z-Wave JS 0.1.8. I basically lost all my zwave devices. I have no control over them in the UI. They are greyed out. When I look in the integration devices and view it now has two entities for it. The old one that does not work and now a new one that does work.
Is this normal?
Happened to me as well today on a standalone docker install of ZWaveJS2MQTT. Fortunately, I keep a full backup on nodes.json and settings.json to recover from and I also have the MQTT retain flag set.
Not sure if your answers were directed towards me, but I’m only using ZWave2MQTT for the GUI.
As far as integration into HA I’m using the “standard ?” ZWaveJS-Server and the latest 1.0.0 version of it.
Are you saying this (external ZWaveJS) is currently a no-no with 2021.3.b and that the only thing that would work with that version is the fully integrated version of ZWaveJS ?
Yes. ZwaveJS2MQTT Addon is currently not compatible with the beta. You have to use the Zwave JS Addon instead. Not sure when ZwaveJS2MQTT Addon will be compatible.
I’m not using the add-on, I have a separate Raspberry PI running a stand-alone installation of ZWaveJSMQTT where I only use it for the GUI features. (MQTT is disabled).
I use the ZWave JS Server on it in order to communicate with HA.
On HA (separate box/installation) I use the ZwaveJS integration, no other addons. (related to ZWave)
