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
yes, it’s included in the most recent versions.
if you want both mqtt and the UI you have to install the zwavejs2mqtt add-on/container. THe other add-on doesn’t offer either of those.
1 Like
That was my understanding as well. What got me last time was the bug with cache not working. If I stuck around longer I might have seen that fixed, and been able to enjoy 1.6 the past year. I just wanted to double check that cache is working properly with the new js is all.
I probably should also ask how device support looks, vs the original integration? I know it’s early, so I assume there are lots of unsupported devices, but then again I know little about the underpinnings of ozw… maybe there list is more extensive? My main concern would be my Honeywell T6 thermostat, which is not as common as the rest (like Ecobee door/window and jasco switches… probably some of the first to be added).
Just the one , I don’t need the latest inbuilt too and I’m staying up to date with leading edge ?
Will websocket be used by HA ?
Thank you - I’ll do that
Yes, if you use the zwavejs integration you have to use websockets. It doesn’t work with MQTT at all.
if you don’t want to use websockets and instead use mqtt you don’t need the zwavejs integration at all. you just need an MQTT broker and set up MQTT discovery on the HA config side.
1 Like
I think we probably need some way to cache battery devices in the zwavejs container in the future. Half of my nodes didn’t come up for hours…
I believe they should already do that. If not then it’s a bug?
I’ll double check, maybe it’s just that the ones I was having trouble with hadn’t even come in the first time. If there’s indeed an issue i’ll file a bug report.
Ok think I figured out the issue it appears that if ZwaveJS2MQTT restarts (docker image update or whatever) that HA also needs a restart as well. So I told HA that it now depends on zwavejs2mqtt as well so hoping that when zwavejs2mqtt restarts it will restart HA as well.