I tried using the node_id with my setup and it still failed to work so thats when I swapped it over to the device_id
I was able to get the new Z-wave JS integration and everything that is not battery powered came right up and works as expected. Although I have a few battery powered motion sensors, door\window sensors that seem to become unavailable anytime the zwavejsmqtt server is restarted or any changes are made to the sever and I have to save the changes. I have to go in on each device and push the button to get it show, although that doesn’t seem to work on each device.
Is anyone else having this issue? Or is this expected behavior, for now?
I’m having the same issues. It’s also not picking up all the entities from the devices in Home Assistant.
1 Like
You’re not alone on this
1 Like
For some reason the Z-Wave JS integration isnt’ even shown… done a hard refresh too but haven’t restarted HA. I’ll try that next.
Good tip, thanks.
To anyone having issues picking up battery powered devices…
The controller will only query devices when they are awake and report in.
In many cases, that could be several hours or even days depending on the schedule configured in the device.
And just to be clear, just because the device reports movement/temp/humidity/etc doesn’t mean that the device is “awake enough” to send reporting data.
To find out how long the wake interval is set to you can re-install the old zwave integration (or re-enable it if you just stopped the zwave network) and look in the values for each node. It will tell you how many seconds the wake cycle is.
And you can change it there too so it takes less time to report in. I set all of mine to 3600 in preparation to switch to OZW (but never did).
But again, if you change the setting there be aware that the setting won’t actually be completed until the next normal wake up cycle of the device. So even then you may still have to wait a while for that setting to change. The benefit of doing it that way is that you can still use your zwave network while you are waiting for the changes to take effect.
Yeah, I know you can’t immediately start using the shiny new stuff 
right away but it’s way less frustrating to do it methodically instead of jumping in the deep end and rushing things.
You should be able to manually wake up devices and the report should happen immediately. But some devices are pretty persnickety and can be difficult to wake up.
either keep trying (or try a different way) or just wait for them to wake up.
Does anyone know if this or the new zwave-js-server-python support using my Razberry daughter card that’s in a raspi 3b+ (ttyAMA0) via a network connection like ser2net (or equivalent) or will I still have to install the integration on the pi with the real physical port like I’m doing now with ozw 1.6?
zwave-js-server-python is just a Python component that talks to the server, so would not be relevant.
The API docs for zwave-js say it supports a tcp serial port, you can try it. https://zwave-js.github.io/node-zwave-js/#/api/driver?id=constructor
tcp://<hostname>:<portnumber>
Of course, if you just run zwave-js on the RPi you don’t need a tcp serial port.
I understand what you’re saying but all these new different components has me confused again!
(Like I was 6 months ago trying to figure out the Z-Wave components that were available back then!)
I’d like to try just installing this:
Put the tcp serial port in the device field and let us know how it goes. 
I held off going from 1.4 to ozw because with ozw, battery powered devices won’t work some time after a reboot, unlike with 1.4 where they work instantly after a reboot (don’t have to wait for another wake period to elapse with 1.4).
Can anyone confirm the expected behavior of the new zwave-js setup WRT rebooting and sleeping devices… good to go like 1.4, or no go like ozw?
I’m ready to jump onboard if it is the former.
I’m trying to clearly figure out the answer to the UI question about Z-wave JS; I’m on hassio and in the addon store there is the official Z-wave JS addon which is what is recommended to use (if you’re on hassio) along with the Z-wave JS integration but there is also another Z-wave JS to MQTT addon that also works with the Z-wave JS integration but has additional functions for MQTT and has a UI on the addon.
so my question is, if you want to be able to get at the z-wave UI you need to set up your addon that interfaces with the USB and the z-wave JS integration to be the Z-wave JS to MQTT addon (even if you don’t need the other functions) and not use the official Z-wave JS addon?
When I first looked at this today I had it in my mind that you could run the official addon but in addition you could install the Z-wave JS to MQTT addon and point it to the the same usb and Z-wave JS addon (port 3000 that’s disabled by default) if all you wanted was to use the UI, but I think this is incorrect, so between the 2 paths if you want the full z-wave UI you have to start out with the Z-wave to MQTT addon? The fact that the plain addon is recommended is the reason I migrated over to that initially but I really appreciate having the UI for some advanced Z-wave functions.
This confused me even writing it so hopefully someone understands what i’m asking
Delete your zwcfg*.xml cache file and see if it still works. OZW 1.4 interviewed your nodes, created a cache file and uses that after a restart. The new integrations need to interview the nodes to do the same thing.
Just to clarify, I’m not running ozw 1.4, but zw 1.4 (the recently deprecated integration)… I may be confused but I thought the whole point of ozw last year was go use 1.6? I did try ozw when it was first introduced around last year, and the cache/reboot thing was never resolved (at least it never worked for me, hence sticking with 1.4… even after nodes had woken and been interviewed… same had to happen after every reboot so apparently no cache was working).
Either way, am I correct in reading what you said? …if I upgrade to zwave-js, it will (like 1.4) create a cache file that it will use after a reboot?
I have to assume the answer would be yes… seems trivial and I was kinda surprised that ozw didn’t work that way when I played a year back.
OZW = the openzwave driver
OZW has always used a cache file. The OpenZWave addon had a bug very early on that didn’t persist the cache, but that’s not the fault of OZW.
And yes, zwave-js uses a cache file. I must imagine every controller software does. You only discover most capabilities of a device when you interview it (which will happen next wake up). Technically you can still report some events w/o knowing some details, but I don’t know exactly how zwave-js acts in that case, and HA needs the metadata in many cases.
1 Like
Ah, ok thank you for the clarification on the early issue with caching, and on what “OZW” means WRT the integration and add-on.
Welp… I’ve got some spare time to play so wish me luck… I’m goin’ in!
In general, any time you switch to a new software (or even lose the cache file), there will be missing information for a short time, until the devices can be interviewed. This usually only affects battery devices because the mains-powered ones are always listening and can be re-interviewed on demand.
Note this applies to zwave software like OZW or zwave-js which use the information they discover from the device interviews. Something like Smart Things let’s you choose specific “device handlers” which are coded for specific devices. You might have a different experience in that case.
I hope I can help…
The zwave-js integration is always going to be needed if you use the websocket method of communication (which seems to be the recommended/“official” way.
If you want the UI you have to install the zwavejs2mqtt add-on/docker container.
If you don’t want the UI then you just need to install the zwave-js add-on.
The MQTT portion of the zwavejs2mqtt add-on is only needed if you don’t want to use the websocket communication. And then, you don’'t even need the zwave-js integration.
And since the add-ons need exclusive access to your zwave controller, you can’t use both add-ons at the same time. It’s one or the other.
But, to simplify…
Do only ONE of the following:
-
if you want the UI then install the zwavejs2mqtt add-on.
-
If you don’t want the add-on then install the zwave-js add-on
then:
either way, install the zwave-js integration.
2 Likes
zwavejs cf zwavejs2mqtt.
Both install and use the same js server or are they different ? Is one js server feature different to the other or more upto date in maintenance or are they the same and in synch dev wise ?
I know there’s websocket included in the non mqtt version but is this in the MQTT version too. I want MQTT but I also want the most current/maintained version and better web UI. What do I install ?
Thank you, that succinctly answers my question exactly. I’ll go that route until the more advanced UI functions get built into the official addon or the UI for the integration get’s beefed up with the additional options
1 Like