What/where are you using this info? I really want my garage doors to work again.
hy guys i setup the zwave js addon and not everything is working very well,
now i want to use zwavejstomqtt too is there any solution to migrate from zwavejs to zwavejstomqtt without deleting the zwavejs addon?
zwave locks have no attributes, such as lock_status. Is there a plan to remedy this soonish?
2 Likes
The NGD00Z-4 works fine in the latest versions of zwavejs.
Barrier Operator support is in for zwavejs, what you’re waiting on is the next HA beta to support them via covers 
1 Like
I don’t use add-ons but I think there is a way to just stop the add-on from the add-on configuration panel.
Got it! I was aware we are waiting on the HA update but thought maybe there was a manual option to add the covers. Much appreciate the info!
Any idea when covers for GoControl will be coming to HA?
AFAIK you should see them in the beta, then next release.
1 Like
Just chiming in to give an update. Have been running ZWaveJS for a few weeks now and its been great once I got past the hurdles in the first week or so. I have >50 devices of mixed brands and types (open/close sensors, motion sensors, flood sensors, plugs, bulbs, locks, sirens, etc…almost no two devices are the same brand from buying sales over time), and right now, the only thing that doesn’t work for me is setting ZWave parameters, which I use for things like setting the notification tone on my Dome Siren and Inovelli Switch notifications. I know this is coming. My door locks work great, automations that fire off from devices from my detached garage work almost instantly (vs up to a 15 second delay with OZW and the old Z wave - and there has been no physical changes to the network) and events have been coming through reliably from Minimotes, Quadmotes, door locks, and again, Inovelli Switches.
I dont have any cover devices so I cant speak there, but Schlage locks were fixed early in the month and always report the correct status (and quickly) every time now.
The migration experience wasn’t great, but this is early on so I hope that will get better down the road for others. Other than that, I’m pretty happy and the WAF has gone up after the initial investment in time on getting it set up.
Anyways, for those with issues, give it time or stick with what works for awhile. Its going to get better and we can move past this whole ZWave ordeal soon enough.
Just wanted to add my input because it seems there are lots of negative discussions in here. It sucks at first (right now), but for me, it ended up being a way more reliable and speedy system so far.
2 Likes
Are you getting updates on alarm_type and alarm_level on your Schlage locks, if you have B469’s? Everything else for my Schlage locks works except those two notifications, which are how I read the code slot to know who unlocked the door to fire off other automations. I see the B469’s still on the migration list, so hopefully there are still some improvements coming.
I have that same lock and it works great. Use the events to determine the user who unlocked the door and fire your automations. I don’t believe that those sensors are being updated (I haven’t checked in awhile), but they are unnecessary for that purpose.
@gregg098 Please elaborate on events to which I can subscribe for code position determination on locks within zwave js. I see no attribute and no specific event that I could use. What am I missing?
See the events section
I’ve subd to that event in appdaemon, I get no event from locks with it on Kwikset 910
Are you sure that command class is supported?
I’m afraid I’m ignorant here. I am not sure, and I don’t know how to find out.
You’ll have to look into the zwavejs logs and see what is happening on the network when these actions occur. Also, it’s possible that configuration values may need to change in the physical device if you migrated. For example, you may need to change the reporting type if that’s a configuration option in your devices configuration.
Thanks for the direction.
Fibaro devices:
I managed to make things work here with ZWJS. I noticed some Fibaro devices are a bit hard to get working:
- FGS223 Fibaro double switch (1 out of 4 would not report the second switch)
- FGSD002 Fibaro smoke sensor is really hard to get working. I had to try re-intervies node and heal node many times. After a day some of them were ok. Two of them report “Unknown Manufacturer” and “Unknown Product” and some values where missing.
This was also the issue with my AEON Labs ZW089 Recessed Door Sensors Gen5. (they all work now)
Furthermore using the ZW Debug panel I discovered that Fibaro devices sometimes complain that they do no support group assignment (while other exact same devices do).
Also interesting: in the ZWJS2MQTT interface, the fibaro smoke sensor is often reported alive. As soon as you issue the ‘Re-Interview Node’ command, it report the node to be asleep. Pressing the button on the device immediate wakes it up again. When I wake up the sensor just before the ‘Re-Interview Node’ command, it also immediate turns to aSleep state. This is probably why it is so hard to get these devices configured.
Ya, as far as I can tell from the logs, I’m getting nothing logged from that node, which would explain why I’m not getting the events.