ZWaveJS casual observations

first off- this is not a complaint only wanted to share my recent experience(s) switching to ZWaveJS and Z/IP and back a few times...

I "debated" posting in feedback but figured I would just start with the lounge

I like to stay current, not beta current but I do try every production release and certainly sounds like ZWaveJS is an eventual inevitability if one wishes to stay current.

BTW I don't use any other radios on the hub, just ZWave ~75 devices in total (10 battery, most 700 maybe a dozen 800, all no security)

My first time switching was when it was first included in a production release - wasn't painful but had a few quirks that have been cited so I had to flip back to Z/IP for a bit ... then I went back to ZWaveJS - and every release since I've gone back and forth out of curiosity to see if there's any difference or improvements. Since 2.4.2 came out I tried again but I'm still on the fence about committing to JS... here's why:

I don't have anything that doesn't work - this is all very minor, maybe even splitting hairs but here goes...

routes - its seems like on legacy I get all direct maybe an occasional 1 hop on JS a few devices have 1 or 2, and 1 even had 3 hops

just cosmetic - but device graph still shows all devices the same way (I know how often are we looking at the graph, but all things considered its nice to see)

response from open/close rule - this is the real kicker, it's minor but noticeable enough... I've done some thorough testing and I am coming up with ~ 14 ms difference avg (better when on legacy)

It's a Basic Rule with a Zooz ZSE41-800LR Open/Close sensor (system driver), that when open and not disabled by a virtual switch, turns on a Zooz ZSE41-800LR Outdoor Plug (Zen Plug Advanced user driver)

Does 14 milliseconds really matter? Honestly if it was just turning on a light or something who knows if I would even notice or bother do so much digging but the open/close sensor is on a sliding glass door - and the plug operates an overhead air curtain to keep flying pests out, so when they are surfing the glass that extra buffer makes a big difference :slight_smile:

I think I've seen other folks on here saying they're getting better response times since switching but I haven't yet, at least not in this one scenario that latency stands out the most for me. Not yet anyway.
I believe I’ve given the hub fair time to settle in after radio changes (like anywhere from overnight to 2 days) and done full shutdown power cycles with good 5 min pauses before powering up.

I’ll keep trying when the next update comes.

3 Likes

I don't think this should be in the lounge, I would put it in Feedback.

I have seen a few issues with JS, and like you I have gone back and forth. For me, ZIP is more consistent and steady. JS seems to have a lot of "quirks". I don't think you are alone.

It is hard to nail the JS issues down exactly, sometimes it is just a bit of perceivable lag, sometimes a light won't turn on, or the status (Current States) don't reflect the physical device. It is so intermittent, that I haven't been able to capture anything for feedback in Beta, for the most part.

Yet at other times JS works fast and smooth, and it seems to work better for some particular devices.

Overall, I think JS is a work in progress. I think it would be helpful if people (maybe you) work with staff (bcopeland) if you have a consistent and repeatable issue and can capture it in logs where it can be seen and analyzed. I think things have been hard to nail down due to the complexity of device types and device drivers.

3 Likes

Thanks for your comments … I’m certainly willing to participate if providing any logging / details / etc helps the cause. Like you I too feel it’s a work in process- and i don’t mind that when we still have legacy as an alternate.

and TBH JS is way more stable and responsive than my inaugural experience with zwave on C-7 with whatever glitchy SI fw was out at that time …the bar has been raised for sure

(post deleted by author)