Devices use the security keys to encrypt and decypt messagees. If you don’t have the security keys setup your controller won’t be able to talk to the devices.
As far as the states go your states should be in sync when an event comes from the device but may be out of sync when controlling the device from either hub. For example if i turn a light on at the switch it should report updates to both hubs that its on as long as the associations are setup. But if i turn the switch on from the st it may not show as on in homee assistant.
Thing is, the ST controller and the Zooz will have different security keys, right? In my case, i let the SL PC Controller create the original set of keys when i registered the Zooz as a device in ST, which enrolled it in the network. I used the keys in PC Controller to set up Zwave JS UI. I have no problem controlling any device from HAOS. Some devices don’t have the 2nd controller because they support only 1 node, so I’m not expecting those to update HAOS. The ones that do have both controllers are not reliably updating HAOS which is my concern. Does it seem like I’ve done anything wrong in the setup to cause this?
Second concern is the Zwave JS UI is not recycling properly when i reboot or restart it. I have to interview the entire network again aaaaaargh.
You didn’t do anything wrong. I am getting the same results but on a device by device bases. My 500 series only reports updates to my primary controller whenever turn it on and off via the button on the device. Then when i control it using z-wave commands from the secondary controller it updates the state on the primary controller but not the other way around. My 800 series smart plug works as expected. When I turn it on and off from the button on the smart plug it updates the state on both controllers. Then if I turn it on and off using z-wave commands from one controller it will update its state in the other controller no matter which one I use.
Thanks for trying all this Cornell! Does HAOS have any kind of a poll/refresh action on a per-device basis as ST (where you pull down on the device page and it causes ST to refresh its state from the device)?
Does it seem like HAOS/ZW JS UI is less tolerant of errors in the ZW mesh? For example, if I run the polling function of PC Controller using the same ZW stick from HAOS, it shows a number of missing packets (which I assume means the mesh dropped either the request from the controller or the response). Is anything non-zero an unhealthy mesh? I have seen delays in cmd processing from ST on my mesh, for example, before introducing HAOS. Could it be HAOS is just less tolerant?
@glenmm
I use HAOS and the integrated Zwave JS, never had a Zwave product fail to include. I have Fakro window winders, Aeotec leak sensors, Aeotec outlets and dimmers, HomeSys dimmers. Even the dodgy Remotec ZXT-600 IR controller pairs first go.
It seems the OP solved their problem by putting the device close to the controller. Without knowing what generation the device was, it is hard to know what the issue was, but that is an issue very early devices use to have before network wide inclusion was a thing. You had to have the device closer to the controller to pair as pairing was at low power and couldn’t go through a repeater. These days ZWave uses Network Wide Inclusion and Inclusion is done at full power and not reduced power.
Zwave JS is one of the more reliable opensource ZWave implementations. When I first started, HA was still using OpenZWave and that , quite frankly, was garbage by comparison. Nothing against the developer, he tried really hard, but it just wasn’t a good implementation in the end.
If you have issues with your ZWave network or delays, firstly look where your controller is. If it is in a cupboard, or worse, a network rack somewhere, that will cause problems as the controller needs to be open to communicate with the network wirelessly. You could try adding a secondary controller to the same network. Don’t do what someone earlier suggested and have multiple primary controllers making up multiple ZWave meshes. All that does is create more interference as they are running on the same frequency. The only reason to create a second ZWave mesh with a second primary controller is if you have so many devices your primary network can’t add more. That would be several hundred devices. Having multiple meshes formed is like having multiple WiFi SSID’s broadcasting on the same frequency. You can do it, They will connect, but they will interfere with each other
I don’t think there’s a network-wide issue with interference between the 2 controllers. On certain devices, when I click Statistics, I see counts of dropped RX. One switch in particular has a higher count that the rest. What does a dropped RX on a device mean - that the device transmitted something in gibberish/a command that the controller tossed, that the ZWave mesh received a corrupted/incomplete packet? Would improving that device’s neighbor/route help to address that, or does it indicate a problem with the device itself?
If it’s just one or two devices in an entire mesh, could be just commands or garbage. Some devices, although they are compliant, do send some non complaint info as well
If the whole mesh goes slow, it’s worth looking for RF reasons why.
It’s kind of like wifi. So many variables could cause dropped packets
Controllers aren’t the only devices that send commands.
Every node along a route will receive the transmission from the previous node, and then send it out again to the next node until it finally reaches its destination. In addition, other nodes (i.e., all your devices) may decide to send something spontaneously, such as when a motion sensor triggers.
In most cases, a device will listen to the radio channel before transmitting its own message, to avoid conflicts. That technique avoids most interference.
But not all nodes can hear all other nodes. If A can hear B and C, but B and C cannot hear each other, B may send a message simultaneously with C. The result is that A gets a corrupted message, which it has to discard.
In any system like ZWave (or Wifi, et al), you should expect to see some level of “Rx drops”, especially as your installation grows so that there are more nodes and they can’t hear each other.
@jh95959
Yes of course, in a mesh network, each router will boost the mesh, but they do all have to communicate back to the controller, via whatever hops / route they use, so checking the controller is a good place to start when troubleshooting RF issues. The next place to go would be new devices.
If the entire mesh is misbehaving, you have to look at RF conditions, so the controller is a great place to start troubleshooting.
Packet dropping is expected, and if it does not affect the entire networks performance, ignore it and move on. The fact people look at the data usually means they have issues they are trying to work out. Of course, there are some that just monitor stats everywhere even if there are no issues, but these are a minority in my experience. Anyone else looking at stats usually have issues they are trying to find.
As a note, not every node in a Z-Wave mesh will receive and retransmit, FLiRS and RSS devices do not retransmit packets. These are mostly battery devices, but not always. Devices that sleep are generally either FLiRS or RSS devices.
If your Z-Wave network is mostly FLiRS or RSS devices, as in mostly battery, then the controller and position of the controller becomes more criticial.
A good management technique is to capture and save statistics when everything is working. That then serves as a baseline to compare the same statistics against when there’s some issue to be found. Often the difference will be very obvious and point the finger at the source of the problem.
@jh95959
Totally agree with you on this point. It would be nice if everyone with Zwave / Zigbee / WiFi or whatever is used did an initial reading when things worked. It would make my job lot easier troubleshooting.
Tinkerers/makers, whatever you want to call them are an increasingly smaller portion of the Home Automation community. Even Home Assistant, which use to be the butt of jokes about growing back virginity and giving up dating once you installed it, has become a lot more main stream…
I’ll stop my waffling now. Sometimes I do miss the old days of bespoke YAML files.