All ways seems like a roll of the dice. While I’m not using a zwa-2, I have duplicate sticks. So in an upgrade scenario I’ll take an NVM backup of the currently running stick; restore to the backup stick; test the backup stick then do a firmware update on the backup stick and run with that for a few days. If it’s not an improvement or if it’s bricked I can always go back to the other stick.
Yes. Went like a charm, but there has been no noticeable improvement on anything. I don’t think performance was in scope IIRC.
Hi,
i recently switched from Fibaro HC3 to ZWA2 and i’m experiencing some issues. While the network (123 nodes) seem to work ok, the ZWA2 gets jammed quite often.
The ZWA2 is placed in the middle of the network, connected over POE. ZwaveJS UI runs as a docker container on my TrueNas server that hosts also the HA VM.
After a lot of poking around i could say that most of the jams occur when a route is not working so either the controller or the node has to do a network wide call to establish a new route.
Anyone else having this jammed issue ? and how often ?
Regards,
I recommend the advice posted earlier about rebuilding routes one at a time for each device starting with the closest one. Otherwise you’ll be waiting FOREVER for the network to stabilize. I suffered from a lot of things not working reliably at first, which is why I started this thread. But the advice to rebuild routes manually, while a real PITA, especially if you have a lot of battery devices, solved the problems for me. My network seems rock solid now and many of the routes are faster than they were, in general, with fewer hops. All of that indicates that the radio is indeed more powerful. You’ll get there.
So you dont have any ZWA2 jams in the activity logs ? Because i did rebuild the routes, and the network works when the ZWA2 is not jammed - which most of the time it auto recovers in 2-3 seconds. During that time obviously nothing works and the network has a delay.
TBH, I wasn’t logging the status, but after seeing your reply, added it to Recorder. When I first installed the ZWA-2, I would notice the blue LED go off A LOT initially, and I didn’t know why. But, in the ZW UI, I did see an intermittent message appear when that happened about controller “off line” or something like that. After rebuilding the routes and things working correctly and stabilized, I haven’t paid much attention, but also never notice the LED going off anymore.
Since 3 pm yesterday, I have logged 4 jams, two were 1 second in length, and two were 3 seconds in length. I don’t know what caused the jam, and not sure that is even logged. I have about 100 devices and probably around a thousand entities. I disable any I don’t need, but that is a never-ending chore since ZW/HA keeps adding new ones with various upgrades, some that are nonsensical for the devices they belong to. Like a “water sensor” for a motion detector. Weird. I also standardize wake up time for battery powered devices, minimize reporting to ONLY those things that I use, and set timings for those to minimize traffic while providing the granularity I need.
It takes ongoing effort, but it is worth it to keep things running smoothly. Hope that helps. Maybe someone with more knowledge of the ZWA-2 or ZW controllers in general can chime in to tell us what might be causing the jams, and if some are “expected” on any network. I suspect it is inevitable. Cheers.
This i don’t understand also. I have motion sensors for roller shutters now 
. Had some other weird stuff popping out also
I had a conversation via email with some of the developers of ZWaveJS and UI developers a while ago about this, and the gist was that every device provides the server with the capabilities they possess in the way of Command Classes when “interviewed”. I don’t think these command classes necessarily define what particular functionality these classes constitute (e.g., HA entities), so the developers are left to guess and/or predict some of them based upon other devices, perhaps ones better defined. This is likely why these rogue, nonsensical entities come about.
Some of this information comes from device capabilities files that either the producer provides (rare) or, in most cases, that someone on this team creates by hand. I did a couple of these myself, and modified a couple of others several years ago because I was the first one using the particular device and a file did not yet exist, or a new version came out. This was shortly after the then-new “ZWaveJS” system replaced the older ZWave library used by HA originally.
These files define the Config Parameters that you are allowed to set for each device, all the info you see when you click Config in the zwave-js-ui. Sometimes these are created based upon user manuals that come with the device, and have to be updated with each new FW release for each device if anything changes, or new parameters are added (which happens often). Maybe that process has improved, or become more automated, but I doubt it. It is time consuming, and we should all be VERY appreciative of all the things that go on behind the scenes to allow us to do what we do with HA. (People can support these developers through contributions on GitHub if so inclined, and I highly recommend it. Some of it is covered by Nabu Casa enrollments, so people can help by signing up there too. It’s a useful and handy service.)
Anyway, it’s all magic. So, I grin and bear it, at least with some understanding of what’s happening. Cheers.