I’m confused, it’s impossible to have 2 containers using the same USB device, do you switch between the 2?
EDIT: nevermind, slow morning.
What version of ZwaveJS2MQTT are you using?
EDIT2: If you’re using ZwaveJS2MQTT v1.4.0 it’ll work. The Addon has not been updated, the ZwaveJS2MQTT Addon v4.4 is still using ZwaveJS2MQTT v1.2.3.
Are you using the ZwaveJS add-on or ZwaveJS2MQTT add-on with your zwave controller? I personally went with ZwaveJS2MQTT but curious what the moderator did. 
I’m not using ZwaveJS2MQTT. Only using the addon Z-Wave JS.
Yes, I’m using ZwaveJS2MQTT Addon on my production system.
OK, thanks ! Worried all the changes I was doing would be for nothing 
I did loose entities just as others have mentioned in this thread but I had to re-do it anyway so for me it’s not a big issue right now.
@gregg098 - I believe sound switch command class was implemented for zwave-js, so for siren/chime combo do we still need to pass manual parameters to trigger chime or should it show up as an entity switch similar to siren?
I have zse019 which was working well minus chime and as the parameters have not been implemented I was not able to trigger the chimes. But was wondering if sound switch class has been implemented then why do we need to pass manual parameters?
I really dont know about other sirens. I got the Dome siren when OZW was still a thing and I always had to set config parameters to change the tone, then turn on/off a switch entity to turn it on/off. I haven’t messed with the new release candidate yet as far as setting parameters goes.
Yeah thats how zooz siren/aeotec siren are. Siren have turn on/off switch and for chime you pass parameters.
Wondering how sound switch class standardizes this if you still have to pass parameters manually.
Edit: Is the beta for zwavejs with parameter already out?
I am a little confused. I have ZWaveJS working through MQTT. The only device that I have that doesn’t work is a GoControl GD00Z-4. It is my understanding that it did not work for 2 reasons, 1) ZWaveJS did not support Barriers and 2) HA did not support Covers. It sounds like the ZWave part is done and I am should get the rest with the next HA upgrade, 2021.3, Is this correct? If I update to the beta will it work?
Well, after several days with zwaveJS and waiting for several devices to become recognized by it (battery operated ones), and after a few days more with the zwaveJS2MQTT, I’ll be pulling the plug to it and getting back to the good old 1.4 OZW integration (fortunately I backed it up before moving to the zwaveJS).
I loved the responsiveness of the devices under the new driver, but I find it troublesome not having devices recognized after several days, or even for those devices that were previously detected (switches, shutters, etc - all powered devices) sometimes they are displayed as unavailable or they are listed as unknown devices or unknown manufacturer.
It is a great enhancement for HASSIO, but I’m afraid it is still not stable enough to replace OZW 1.4.
I have had zero issues with over 70 devices. I do use the ZwaveJS2MQTT verses ZwaveJS but the HA has worked for everything I use except my two GoControl devices. Are you sure you did the implementation correctly?
I kind of agree. I was forced into zwavejs because my HA wouldn’t start. I don’t know why, but that’s how it was. I have 103 z-wave devices that ALL worked nice in 1.4. Most are fine in zwavejs, and the speed in much better than with1.4. But some devices cause trouble or won’t go in. They are:
sensative strips. 3 out of 14 simply will not be recognized.
Qubino smart meters (singe and 3 phase). Must set them up with polling, but then they’re ok, it seems.
Idlock 150: two came in nicely with all sensors and stuff. Two are IMPOSSIBLE to get in. I’ve tried everything, but no luck. That’s my biggest problem right now.
And the Heatit thermostats, of course. Bot that’s being fixed in 2021.3?
In fact, the way it works now is that zwavejs goes out to ask each and every device: who are you and what can you do?
What I’d like, is a button that says “node 27 is identical to node 227, so please treat it the same way”
Is this possible? To simply tell zwavejs what type each device instead of letting it find out itself?
Thats probably possible if you can edit the config files properly. I was able to do somethign similar with a Schlage lock that refused to update when I used OZW. Shut everything down and copied the important bits from OZWCache file to the entity that didnt work. Messed up some formatting first try. Got it on the second. Format seems different in ZWaveJS though, so like I said, maybe possible, but never tried.
I swear I’ve seen somewhere, maybe this thread, but cant find it now, that there is a way to import the old cache file into ZWaveJS if you use Docker and not HassOS due to the file access required. Maybe someone else can ellaborate or clarify?
Just keep in mind that while your Z-Wave-device/stick/card/dongle/whatchamacallit contains a lot of information about your devices, it does not contain all of it and as a result the “platform” (i.e. 1.4, OpwnZW, ZWaveJS) need to run a discovery / “Interview”. This is normally done during the initial inclusion process, but when you switch platforms it has to be done again. The device won’t trigger this as it is happily included with your dongle/interface, instead it is triggered by the platform (ZWaveJS in this case).
On powered devices this happens automatically over time, but battery operated devices need to be woken up, In some cases it’s as easy as them reporting something due to a status change, but in some (for me, many) cases they need to be put into pairing mode again to allow the interview process to be completed.
Time will not solve this issue I’m afraid, nor will any level of “maturity” of the platform, it’s the way your devices operate and can’t be fixed by HA / ZWaveJS.
Also note that due to the massive influx of information during initial startup some devices simply won’t get interviewed. i.e. you can’t fire up ZWaveJS and then run around waking up every single battery operated device you have and expect them to all get interviewed properly. A lot of them will time-out before they get a chance to.
I find it best to monitor the interview status (which is why ZWaveJSMQTT is so convenient with it’s logs and GUI) and once the initial round of interviews are done / appears to have gone dormant, you then target each remaining device individually by triggering a re-interview and then waking that specific device up, one by one until they’re all completed.
Again, this is not really an issue with HA / ZWaveJS, you’d be having the same issues no matter which platform you switch to.
I too had issues with battery operated devices. One by one I had to re-establish the interview and wake up the devices. I waited until it was completed before moving to the next one. This worked in every instance. In fact, zwavejs2mqtt identified the following devices which were unknown under OZW.
Ministon toggle switch
Wink window/door sensors
Verilock translator
I’m only missing my GoControl garage door cover.
Some devices don’t report there information, you may have to physically wake them up. You’ll be stuck on 1.4 forever if you aren’t willing to put in the leg work (walking to the device and pressing the wakeup sequence). I personally have 2 devices that don’t have a periodic wakeup. I’d be willing to bet that your battery devices also don’t have that feature.
Can confirm that GoControl NGD00Z-4 works just fine in the latest HA Beta and with ZWaveJS 6.5 / Server 1.0
I’m using zwavejs2mqtt. I hope they have it working via that platform.
Could anybody Say me if the Cover will work in the latest beta?
Iam using a fibaro Roller shutter
Doesn’t appear to be working for me. I removed/readded it. HA sees it but does not appear to be able to control it. Appears as a Garage Door Controller (NGD00Z-4) by Nortek Security & Control LLC