Ahha - therein lies the folly. The keyphrase I assert through my 35 yrs in software development, is “never assume anything in software!”. Software has (or should) a predictable logic, that is to say that the golden test is to ensure that every possible state within the machine programme must be logically defined and evaluated for all possible conditions within the domain being programmatically emulated or simulated. To assume something would be to fail such a test and render the state interminable - which is never a good state to be in !!
Not so much logical that the problem lies in ZWJS itself, but moreover there is - ostensibly - an issue somewhere in the complete stack that ZWJS uses, for your use-case. That is to say the actual problem may not be in ZWJS but “something it uses”. Aside, that is precisely why I posted the OP. I sought to canvass experiences. Some will be good - no issues - some will be less good , such as yours. There is never a copper bottom guarantee with software.
That is what I would do because currently I do not have capacity in my daytime to investigate. If circumstances were different , I would, but now is not the right time for me. Again another reason for the OP. Everything is working perfectly at the moment so I am very hesitant to “fix that which is not broken” by “upgrading” to ZWJS. Now may not be the best time and there is nothing forcing me to do so anyway - YET.
I do run daily backups so in practice I could just “try it” with ZWJS and then if it doesn’t work then return to the backup. But even restoring backups can have a negative effect and cause rework. For example restoring a live database such as that which HA uses will mean I lose history on entities. This is just one example, there are many others I could cite in my use-case. Yes I could be selective in restore but that’s more effort on top of effort on top of an action which I didn’t really need to do. As I say, now is the wrong time for all this - for me - so I plan to stick with OZW.
I have one major pain in the ass with one node. Its a philio psp05. I can set all configs as desired, communication seems fine. However, the motion detector never goes away. After inclusion , it works one time and then never.
The ‘report off’ is enabled, so it should report ‘motion cooled down’ or somehting, but it does not work (while it did in deprecated zwave integration).
below, you see message coming in… and after 20 seconds orso, the reset should happen, but that message seems wrongly parsed. I cant remember literaly the config i had in openzwave 1.4, but it did just report properly no motion any more after the right amount of 24 seconds (3 times 8 seconds as config describes)
2021-02-16 11:54:08.580 INFO ZWAVE: Node 31: value updated: 128-0-level 100 => 100
2021-02-16 11:54:08.582 INFO ZWAVE: Node 31: value updated: 128-0-isLow false => false
2021-02-16 11:54:08.648 INFO ZWAVE: Node 31: value updated: 113-0-Home Security-Motion sensor status 8 => 8
2021-02-16 11:54:25.352 INFO ZWAVE: Node 31: value updated: 113-0-Home Security-unknown 254 => 254
Also tried binary setup, no avail.
feels kinda of a bug to me on this specific device, as other brand motion sensor (hank) is working fine
This thread relates to my OP query. This thread is not for new questions and issues, but rather experiences of moving to ZWJS. May I ask that it is not cluttered with questions unrelated - please. You should probably move your post to a new post in the configuration section and tag is with ZWave.
well, yes and no. I know how zwave configs work, and this is specifically an experience report in the context of ZWJS matter. I can remove the question if you want, or more report on nodes that do work?
btw depending on the JS server add in use, I see different behaviors in general. Anyone else tried the ‘js’ vs ‘mqtt JS’ differrences?
If you would be so kind, that would be appreciated. Otherwise we can easily get to a scenario of multiple questions posted from different members, attracting multiple resolutions or suggestions, and cycling around these with replies and counter replies. This is going to hinder me as I try to pick out the “experience” reports that I asked for in the OP. I’m sure you understand - thank you.
I tried out switching from OZW to ZWJS and then ZJS2MQTT over the weekend. Things were mostly straight forward initially, but I was never able to get any of my battery powered door sensors, motion sensors, or smoke alarm to show up despite multiple attempts to wake up the devices and waiting ~24hrs. My battery powered Yale lock worked fine however. Everything without a battery showed up without issue. Response times were maybe a bit better with Z-Wave JS, but OZW performs fine for me so it was hard to say for sure. I took some videos and I’ll maybe do a frame-by-frame comparison later.
After wrestling with Docker for a bit, I was able to gracefully switch between the core Z-Wave JS and Z-Wave JS to MQTT add-ons without refreshing all devices by copying the cache files using HassOS root SSH access as documented in this post. In short, you can copy three Z-Wave JS cache files between the two versions of Z-Wave JS and switch between them without too much hassle (but don’t docker cp or docker exec or you might have problems).
For now I’d recommend using the Z-Wave JS to MQTT add-on if you’re just trying out Z-Wave JS. The core Z-Wave JS add-on doesn’t have much in the way of visualization, logging or configuration options, and it’s really helpful to be able to change the Z-Wave JS log level, or look at the node list in the Z-Wave JS control panel to be able to understand what is happening under the hood for debugging.
Ultimately, I switched back to OZW. Everything just works for me in OZW. I’ll keep the Z-Wave JS add-ons installed but not started so I can easily try them out as updates are released.
Update: Not 100% sure it was related to trying out Z-Wave JS but my Yale lock stopped working after moving back to OZW. I pulled out the batteries on it and refreshed the node in the OZW admin and restarted the OZW add-on a few times and it came back
That’s a great bunch of info @johnboiles , much appreciated, and like you I find OZW “just works”.ZWJS is a bit of a 50/50 for me I think at this time.
I seem to have battery sensors that stop working. Seems when JS server reloads stuff (after settings change or whatever), the battery ones that do not regularly come awake, stop updating and no longer have working entities in HA.
Kind of kick back on this migration. i’m sure devs can make it more stable, but for now it would keep beta sticker for me.
Mine would have gone fine if I did not have a Zwave plus devices. I don’t think it fully supports garage door openers- it’s enough to work but left me with plenty of dummy entities and those gummed up my homekit so much I had to wipe it and start over. Same issue with zwave plus door locks.
I’ve found that ZWave-JS is, at best, early alpha. I have ten devices. Of those, it’s only found 2…after six hours. I honestly don’t know how anyone is using this integration. I have one door lock, two motion sensors, two contact sensors, a power receptacle (found this one), a water leak sensor, and two light switches. (The 10th device is the stick.)
I don’t really depend on ZWave, as I’ve converted most of my home to Zigbee due to reliability issues.
I think your plan is spot on. After I’m bored with ZWave-JS, I will revert to OZW. As I noted in a later comment, ZWave-JS is really early alpha in quality and functionality.
Fwiw after I made my renaming script this weekend I migrated back to ZWaveJS and haven’t gone back to ozw yet. I now have everything important working in ZWaveJS including my finicky ZCOMBO smoke alarm. I’m a few days in and everything has been reliable and fast so far!
Update: of course just as I write this I have an issue. I just had a blip where it took ~15s for a ZWave light to turn off. Afterwards everything was perfectly responsive again
Most are, yes. The outlet is not battery, nor are the light switches (all are powered). I didn’t have any substantive issues with OZW…occasional device dropouts for one fringe device. When looking at the map when they were OZW, the network looked relatively robust; one device had no alternate path.
Just installed ZWave-JS over HA 2021.5.5 containerized.
After a lot of renaming I finally have HA working again… With ONE NASTY exception!
All my Light Switches (switches converted to Lights using the switch platform) appears as “Unavailable” (greyed-out) although all related ZWave switches are perfectly operational.
It seems like that “Switch Platform” tried to generate the Lights when the Switches were not yet ready. However, I haven’t found a way to force re-scanning them.
Of course I can modify all my lovelace controls to use the underlying switches, but it would break many automations and the Google Assistant integration.
You should have a bunch of new entities for those light.switch ones, as long as you renamed everything. The unavailable ones are bound to the old OZW integration entities.
