Let's start talking about the new Z-wave JS integration

Did you install the zwavejs add-on when you installed the zwavejs integration on instance B?

Are you sure you still have the add-on running on instance B? Maybe if you installed it that way the since you removed the integration on B it also assumed you no longer needed the add-on so it removed the add-on as well.

As far as I understand it you don’t have to have any HA running on the machine that runs the zwavejs server. So there may be something funky going on with the way you installed it (via the instance B integration).

that’s it! How strange. Stopping the integration on Instance B also stopped the add-on on B. I restarted the Add-on (and the integration on B remained stopped) which made the integration on A come back to life with all devices and entities.

Not sure if this is as per design, we might/must tag @petro here, because if it isn’t Id have to create an issue

Thanks for the hint!

1 Like

I have both v1 and v2, after upgrading nothing was coming through to Homeassistant.
What I did was wake up both the devices by pulling out the battery and re-inserting it after pressing the button. Once you hear a beep you can see the lights as the device re-interviews with the hub. Once you see awake on zwavejs2mqtt refresh/restart home assistant.
I had to do this with all of my zwave battery device like minimote and smoke alarms.

I do wonder now, if the integration should start showing entities for state ‘restartfromCache’ too. I have one (hank motion sensor) on that state now and entity is working in HA. Meaning Triggering motion or pusing the button in that room did not make JS server see it complete, but the motion binary is updating in HA.
When i will update HA now, it will disappear and not comeback easily as that sensor just doenst get away from that state seemingly. so to me, restartfromcache would be valid to show as entity in HA as opposed to 'wait for complete ’ state as it is now afaik.

Addditionally, i have one on complete state, but no info


But also works fine in HA…
I’ll update new HA version today and see which will come back and which wont

I would like to know this as well. I’m using the same module. Haven’t found a solution yet.

I see the same sort of errors:

21-03-05 09:47:03 ERROR (MainThread) [supervisor.api.ingress] Ingress error: 400, message='Invalid response status', url=URL('http://172.30.33.1:8099/socket.io/?EIO=4&transport=websocket&sid=A5CtUK7Br62wvD7yAAAI')
21-03-05 09:48:49 ERROR (MainThread) [supervisor.api.ingress] Ingress error: 400, message='Invalid response status', url=URL('http://172.30.33.1:8099/socket.io/?EIO=4&transport=websocket&sid=T8uTiKAH196tkmweAAAK')
21-03-05 09:51:41 ERROR (MainThread) [supervisor.api.ingress] Ingress error: 400, message='Invalid response status', url=URL('http://172.30.33.1:8099/socket.io/?EIO=4&transport=websocket&sid=7-iCG36o2e_x5nTwAAAM')
21-03-05 09:55:26 ERROR (MainThread) [supervisor.api.ingress] Ingress error: 400, message='Invalid response status', url=URL('http://172.30.33.1:8099/socket.io/?EIO=4&transport=websocket&sid=ZuVzb59Ek8qXTbmAAAAO')
21-03-05 09:56:48 ERROR (MainThread) [supervisor.api.ingress] Ingress error: 400, message='Invalid response status', url=URL('http://172.30.33.1:8099/socket.io/?EIO=4&transport=websocket&sid=TE1k8wygbmczK_QFAAAQ')

Doný know if its related to zwavejs or not, running zwave2mqtt. How can I determine what container it’s from? Can’t find the ip adresses anywhere. Running hass.io OVA on vwmare.

I did have some luck with 3 of 4 of my smoke alarms last night doing this. Had to do the same thing initially after migrating to ZWJS. The last one Ill re-tackle today. Really appreciate all the hard work from team. I just hope were at a point where I can rely on critical things like smoke alarms to always work and not have a check list of items to review after each upgrade.

Firstalert devices normally checks with zwave controller every 60-70 minutes. Wonder if you leave them alone they might reconnect again but then you are not protected for 60 mins

Nope, they were left alone for over a day after the sensors went away. Did a restart or two of each Home Assistant and Zwave in between.

i changed the cable config … so this was the solution too me.

I’m still unable to add the ZEN30, despite excluding and factory resetting the device first. I’m running ZwaveJs2Mqtt App Version 2.1.0, Zwavejs Version 6.6.0, and Zwavejs-server Version 1.1.0. But it keeps appearing as status: unknown, interview state: none.

Has anyone else gotten a ZEN30 to pair and work with ZwaveJs?

I tried ZWaveJS2MQTT (using ZWave-JS 6.6.0), but I noticed that the device configuration files are not up to “quality” as with OZW. Mostly this gives timeouts during startup (and thus slowdown the initial process), but my Qubino Smart Plug 16A does not like, when trying to poll unknown configuration values (then it stops responding and needs a power cycle).
I reported this to ZWaveJS and until that’s fixed, I need to stay on OZW 1.4.

Fwiw, the qubinos work super responsively here, using core integration and add-on

That includes the Smart Plug 16A? I tried 3 different ones, all have the same “issue”. The 6.6.0 version polls configuration id=41 and then the plug is dead in the water (until power cycle).

yes:

with a ridiculous amount of entities :wink:

I just switched from zwave2mqtt to zwavejs2mqtt using websockets through the new integration. Wow! State updates are instantaneous! There was always a 2-3s delay between when the switch was flipped and when HA would register the state change before. Not anymore. Thank you to all the contributors!

1 Like

Thanks for screenshot, and I got:
Firmware: 2.0

So 3.0 is fine, but something wrong with 2.0 with retrieving invalid configuration parameters.

Did some more testing and checked https://github.com/zwave-js/node-zwave-js/ of zwave-js, and it seems (at least for me), to wait for v7.x.x of the zwave-js. In the v7.x they seem to remove the retrieval of the parameters from the start-up queue (which really slows things down and makes it less responsive 2-3 minutes after start).

My Zen30 works well. It does have a couple weird issues, but it still works. When I look at the network map, the Zen30 is frequently grayed out and showing not connected to any of my other 24 devices. When it does show connected on the network map, it has to make 2 hops to get to my controller. That doesn’t make sense to me as the device is relatively close to my controller and is hoping through devices that are further away from the controller.

But even with those issues, the Zen30 still works very well. It is very responsive to voice commands (through Alexa) and when I flip the switch in Home Assistant. It also works flawlessly with my automations.

new challenge: after adding a new Sensative Strip Guard it shows up correctly, and all entities are created, including the battery sensor.


The latter wont show in the entities list in the battery column, as the others all do:

another instance (which holds the add-on and the stick) does show the battery, even while it hasn’t been renamed on that instance yet:

I have already restarted the add-on, and the integration a couple of times, and, given it some time (day).

What could be wrong in the systems registry for it not to show the battery?

this is the renamed sensor on the remote system:

            {
                "entity_id": "sensor.garage_corridor_door_battery_level",
                "config_entry_id": "62redfacteda861183",
                "device_id": "dd71ddredactedb4439",
                "area_id": null,
                "unique_id": "39redacted.52-128-0-level",
                "platform": "zwave_js",
                "name": "Garage corridor door: Battery level",
                "icon": null,
                "disabled_by": null,
                "capabilities": {},
                "supported_features": 0,
                "device_class": "battery",
                "unit_of_measurement": "%",
                "original_name": "Strips-MaZw: Battery level",
                "original_icon": null
            }

and this the add-on system:

            {
                "entity_id": "sensor.strips_mazw_battery_level",
                "config_entry_id": "8529redactedd128f1f",
                "device_id": "fe64redacted9859bbe",
                "area_id": null,
                "unique_id": "39redacted.52-128-0-level",
                "platform": "zwave_js",
                "name": null,
                "icon": null,
                "disabled_by": null,
                "capabilities": null,
                "supported_features": 0,
                "device_class": "battery",
                "unit_of_measurement": "%",
                "original_name": "Strips-MaZw: Battery level",
                "original_icon": null
            }