I tried ZWaveJS multiple times since it was introduced. I was using "one variable at a time" aproach for testing. I.e. during the test only one change was done to the system which was switching to the ZWaveJS. Test time was around 4-5 days to make sure ZWaveJS intervied all ZWave devices.
Every time I switched to the ZWaveJS system became unstable driving pretty high WAF down. Suddenly many (if not all) RM rules experienced random very noticable delays. Sometime delays are up to a minute or so. It feels like rume failed but no it did work with a huge delay. Ultraloq zwave lock happens to be most sensitive device.
After changing back to Legacy ZWave system instanly became very stable,
Bottom line: ZWaveJS is not quite ready for prime time.
That seems a tad harsh - I had it running on a C8 for about 2 months (not even a C8+, so I know I'm pushing my luck) - with about 30 devices (mainly lights, shades, and buttons - no locks) and it seems to be doing well, other than being a bit of a memory pig. It IS getting LOTS of active development on the beta side, from library updates to lots of work on handling reports for different command classes - So I believe it's an area of active focus. For me, it solved some problems around backups and using LR devices.
Is it as mature as ZIP, no -
Is it the future for Zwave on HE, yes - Given the SiL has given up on ZIP.
So if it's a problem for you some of your devices, then stick with ZIP for the time being, but to say "it's not practical" is simply an overstatement. - It may not be practical FOR YOU. - But it's solved some long open problems for others (myself included), and given the efforts that are ongoing, it's clearly the current long term direction for ZWave on HE
Bottom line, it's like a fine wine - It's just taking a bit of time to mature for all the different palates (different device types).
Yup - there are a lot of folks running JS and having good results, but there are others (like me) who have had and continue to have inconsistent results.
JS is definitely still a YMMV situation, but it is the future, and HE is very focused on getting it into tip-top shape. Situations like this is where HE shines, in that you can choose what works best for you. Use ZipGateway or JS, stick w/last month's (or last year's) platform version, etc. Choice is good.
I've been using it since release and haven't had any problems related to ZW JS. My Zwave mesh has had consistent problems for a long time, and ZWJS didn't fix them or make them any worse. I suspect I have a misbehaving device somewhere and just haven't really had the time to look deep into it as almost all my devices actually work fine, just a few problematic ones.
Thanks for the feedback — totally fair point. Like most new protocols, Z-Wave JS had its share of growing pains early on, but it’s really starting to mature. The latest update (currently in beta) already shows big improvements, and assuming testing goes smoothly, it should roll out publicly soon.
Honestly, Z-Wave JS is already more stable and capable than the older implementation ever was. A lot of folks are running large networks reliably now.
Of course, some edge cases and quirky devices can still make it feel “not quite ready” depending on the setup — but the gap is definitely closing fast.
Thank you for the info. I will try it again as soon as it will become available.
But as of today whenever I tryed ZWaveJS my setup immedietly became unstable (huge random delays near for every RM rule, all my automations are RM childs). This is definitely atributed to the ZWaveJS because for clean testing this is only one single change in the setup.
There are 57 mesh devices plus 4 LR devices. 6 devices are S2 (3LR and 3Mesh) and somehow only 1 is S0. This S0 one is a Fibaro Motion Sensor ZW5. I do not remember why it was included with S0 but it must be a reson (it could be related to the "including" problem). Anyway I have a hard time to believe this single S0 device screws up the entire ZWave Mesh when ZWaveJS is enabled. Otherwise ZWave mesh near 100% stable. However if you think this single S0 device is a problem I can try to re-include it without S0 enabled.
Not really wanting it at this time but Just curious. I thought JS was only available on the PRO, but some of the comments here seem to indicate it is also available on a plain C8.
my exact sentiments - I said something like this in one of the ZWaveJS threads.
I'm still using Z/IP ~ but don't think I would get any complaints around here if I was on JS, for me there was just some millisecond better performance w/ sensors on legacy. That and the direct associations. I'm sure JS will be in my future.
I am happy to hear the ZwaveJS works just fine formany users. I hope one day my setup also will be happy with ZwaveJS. I tried to switch to ZWaveJS 3-4 times. Each time unfortunately near all RM rules exhibited huge (up to 1 min) delays. Of course this is/was not acceptable. And this is/was not only a problem with my speciffic setup. There was many complains related to the same problem with ZWaveJS. The most sesitive device happens to be an Ultraloq ZWave Lock.
It would be interesting to get a full picture of your zwave environment after the Zwave JS migration has had time to settle down. Delays like that sound like possibly radio routing, the radio getting overwelmed, cpu contention, memory contention. Is it just RM being slow. What happens with just submitting commands from the hub?
OK. Next time when I will try ZwaveJS again I can/will provide whatever details are required but I will have to know what exactly to provide. Right now is not a good time to try again ZwaveJS.
This is very confusing statement. Everything works near ideally with Legacy Zwave but becomes really bad right after switching to the ZWaveJS. Things are not improving over time. I was waiting 3-4 days hopping for the "self healing" (or whatever it is). Unfortunately this did not work. And what exactly this ZWaveJS is? Is it touting Zwave Chip firmware or just a ZWave Chip driver? Why suddenly radio getting overwelmed, cpu contention and memory contention? To my EE eyes this makes near no sense.
RM rules (all my automations are RM rules) definitely impacted. It is hard to say if controlling a devices from the Device Page somewhat compromized. I tried this for the lock (most impacted device) and it responded to the lock/unlock commands reasonably fast. But sure, few commands did no go through on the first try. But the lock behavior is about is about the same as with Legacy Zwave.
Speaking only for myself, I can say for me it's been stable as a rock. 40+ devices on a C8pro. No lagging, no reboots (except for platform updates). I've even switch back and forth a couple of times back to zip gateway. It's been very steady. Props to @bcopeland for his hard work...
That is fine. I think the key is to narrow in on what isn't working so probably start with the Zwave Details page to show the overall devices and how it is working, Then may narrow down to a single device and automation to review what it is doing and the logs. Maybe a few devices if the automation has multiple zwave devices involved.
Sorry, it was not ment to be. My point was there are a few possible things that could be related. The one problem is that it does take a little bit of time for it to settle in meaning for everything in your environment to be re interviewed and setup with the Zwave JS software. Think of Zipgateway and ZwaveJS as the driving software for the Zwave Radio. It is the middleware between the Hubitat environment and the radio that talks to your devices. Zipgateway is the old software which is EOL and no longer getting updates, or bug fixes. Zwave JS is in active development and getting fixes. From a support perspective that means the only real go forward option is Zwave JS. There are bugs that will just never be fixed with Zipgateway at this point. The problem is all of our environments are a little different. Many of us are running without issues so the question is what in your environment isn't working with ZwaveJS. To figure that out we need to dig into what you have and where the delays are occuring. It could also be a device functioning as a router is misbehaving. Either way it will take some time to diagnose what the issue really is.
The reason i include RM is becuase this could be just as much about the trigger as it is anything else. So it would be important to look at the entire flow. turn on logging for RM and validate the time fo the whole flow to work. The time it takes for the message to come into the hub, Then the hub to process it, and then turn it around and send it to the device.
Either way the next relese of the hub firmware will include what looks like some updates to the Zwave software so you may want to check it again after that to see if that new software helps it out.
This is exactly what I was/am thinking about. Thank for confirming this.
Taking in account that ZWaveJS is nothing more than middle man between ZWave Radio and HE Platform I really cannot understand why and how the behavior of this middle man may screw up the entire ZWave Mesh which is handled by ZWave Radio firmware. Am I right? With the Legacy ZWave (ZIP) middle man everthing is near ideal but as soon as ZWaveJS is in the middle everything is screwed up. Well, everything is still functional but with a huge delays. So how come this is related to the Devices/Mesh if it handles by the ZWave Radio? As I said, to my EE eyes this makes no sense. Say in car, engine is running smothly, wheals are still round but with a differen transmission ride is suddely becomes very bumpy. So, very is a problem? Obviously the transmition is a problem. Is not it?
I am not saying zwave js is not responsible. I agree things are different,
To go back to your car anology there is a problem. You are assuming it is identicle, i would argue that Zwave JS and ZipGatway are not, so the analogy isn't valid.
On top of that all of our environments are different right. You likely have very different variety of zwave devices then i do. Your home environment is different as well. This is why so many folks have different results. All i am saying is lets find out what is unique about your environment.
I would probably start with a inventory of what devices you have in your zwave environment, What version of zwave they are running, and how are they connected like no security, S0, or S2 and LR or not LR. Then look at how many repeaters you have. and what is being used to repeat the network.
I wold imagine the algoriths for the mesh and routing could be slightly different and wonder if that could be impacting performance.
my exact sentiments - I said something like this in one of the ZWaveJS threads.
