See this about addressing the lack of coordination between the lock status notifications and the lock state in HA. I have 3 Kwikset locks that exhibit the behavior in that thread, but I don’t see the utter failure that you describe. I posted one of my automations that “fixes” the lock state based on the notification event here.
Oh, thanks. I’m seeing much of this. Nice to know I’m not crazy!
Well this new integration finally gave me the motivation to move my stick to a pi located a little more central in the house. Ended up implementing usbip for this. Thank you zwavejs peoples.
OK, I’ll answer my own questions from above…
I ended up having to pull the latest docker dev image and update my container.
It’s now working…I think…so far…
I’m having a pretty serious issue now. I didn’t think much of it earlier because I thought it was because I was just constantly tinkering to get things going… now that I’ve left it alone for a few hours it just… STOPS. Sensors, everything just go unresponsive in HA. I don’t mean showing off-line, I mean UNRESPONSIVE sticking to their last known state.
In the Z-wave JS Control Panel everything on that side still works. It is as if HA just stops talking to it.
Anyone see this? I run the server on a Pi and HA on a different machine. Both are connected with Ethernet… no spotty Wifi. OZW worked perfectly for months on end in this configuration.
For the battery devices I tried removing a few from the Z-wave Network and add them and that seemed to do the trick in keeping them active on the network. I’ve been through a few reboots of my Unraid zwavejs2mqtt docker container and a few reboots of HA itself and it looks like they are all coming back. I’m not sure if this will help you or someone else but it might be worth testing.
I thought about doing the exact same thing, and was wondering if this would actually work? I assume the devices themselves wouldn’t care about having two controllers connected to them (no simultaneously, anyway). Can anyone confirm this is possible? I’d be willing to buy another Pi and stick to go this route if so. Sure beats being down for a week (or two) to rebuild the network and test all your automations again. 
I’m with you!
I’m finding a lot of my Zwave Nodes showing up as devices in ZWave JS but they are marked as not ready. Some are working, others are not. It’s not just battery powered devices either.
Those devices that aren’t working aren’t also working in the ZWave Legacy either now, when they used to be fine. No idea what’s going on.
e.g. here’s a portion of devices shown. Everything with a name of “Node XX” are “Not Ready”:
eg.
I’ve tried waking up the battery powered ones (eg. zooz multisensor) but nothing worked.
…help?
I think this adds to some of the confusion many of us have. This topic is about the new zwave JS integration being built, NOT the existing community developed zwavejs2mqtt (which I believe what you are talking about here). Although they are both based on zwave-js, they are not the same, nor directly interchangeable, just like the original zwave 1.4 is different from OZW 1.6, even though they both rely on OpenZWave.
I had this with a HUSBZB-1 stick on the old zwave integration, it would never correct, never populate the manufacturer and model after one day deciding it didn’t know anything about them anymore. So I bought a new stick and all good now.
Restart your home assistant and zwavejs. That solved this exact issue for me
Thank you for the confirmation. I was planning on trying that but its so boring and I wasn’t sure it was worth it, now I know it’s at least worth a try! 
@tmchow, @cree8 Took me three hours to copy/paste my 16 nodes with 119 OZW entitiy IDs into Excel and then edit 53 new ZJS entities that are active!
@quizzical I reloaded ZJS, restarted HA and ecolink binary sensor entity became available but that was after the preceding documentation, editing & removal of owz integration…
1 Like
I restarted HA and devices are workign again with the legacy ZWave integration. Not sure what happened there. But many devices are still showing up in ZJS as unavailable/not ready/etc:
I have two questions regarding the new integrations:
-
I assume that if one uses HA fully supervised, the HA ZJS Server add-on is a separate docker container that does not get restartet (and re-interviews the whole Z-Wave mesh) when HA Core gets restarted? So if one primarly wants to make solve that the standard approach would work?
-
If you start with an integrated solution (say: HA Blue with Z-Stick, ZJS server add-on, ZJS integration as described in the documentation) and decide later that you want to separate the Stick and ZJS server to a different host, is it that easy to just point the ZJS integration to a different host (say: IP and Port…) and everything stays the same? Or will it be recognized as something new? Will entities change? Reasoning: I would start with an integrated solution but would want to understand what changing that later (i.e. move HA Core to a server host and use a RasPi with Stick and ZJS server as Z-Wave hub) would mean - would I have to do the work with devices and entities twice?
Thanks for shedding some light on this!
any reason why you would start on 1 instance now, and separate later? I mean, if making the transition to the new JS implementation, why not do it in the foreseen way at once?
Can only tell it was snap easy to do that, and have it running like that exactly.
not biting the bait here, but characterizing the mqtt layer as a ‘between layer’ in my instance is not correct.
First of all, the Mqtt isn’t ‘between’ the Z-wave and HA at all, it is ‘next’ to it on the single instance. Second to that, mqtt is only used to communicate the Z-wave states to other instances. Whichever they are, wherever they are.
If one would only use the ZwaveJS integration and add-on on 1 single production system, the mqtt addition (explicitly not calling it a ‘layer’) would not be necessary at all. If one needs it to do more than that, and publish states to other devices, one needs some sort of publishing layer.
Mqtt is clean as a whistle and defacto industry standard, or should I say purposely created for that. Using more than 1 hardware device for these purposes is simply a way to up the control in Risk management, especially if one want to be their HA system more than a Hobby, and wants it to be as secure was possible. A pure necessity imho, especially given the control over our homes we hand to it…
Being married to a professional Risk manager/enterprise architect forces me to hand over my architectural decisions every once in a while, to get the green light for future investments. Talking about the WAF
Not even talking about the proverbial Garagedoor opening while on holiday, because the Z-wave instance acted up…
2nd question…what’s the purpose of this configuration item?
