See picture above. I did exclude of dongle A2, factory reseted, and then inclusion. When hub is at A2 location, i can control it fine. Then I take hub to A1 and set that up too. I put Hub at the location shown in picture. From there I can control A1 fine as its only 4 meters away. But Hub has hard time reaching A2 which is only 10 meters away.
It seems the zwave dongle power is weak?
Any commands i send to A2 doesnt go. Sometimes it works, sometimes not.
Commands end up showing in Scheduled.
There are no interference devices like fridges, nothing. It's a empty house.
When I move hub close to A2, then it can control it fine and instant.
I know there is a way that A2 will treat A1 as repeater. How do I do this?
Or do i need to just wait and give aeotec A2 dongle time to find A1 as a repeater?
There is nothing you need to do, or much you can (directly) do actually. The routing algorithm is baked into the zwave backend/SDK and is not user adjustable on this hub (it is on some other hubs oh, but even in those it's an advanced feature and often causes more problems than benefit).
You can try unplugging or moving repeaters or the Hub itself, then do a repair or trigger the end device at the device to try to force it to pick a different route, which sometimes works but just as often it will fall back to the original route over time if it thinks it's better.
Or you can add more repeaters until it finds a route that it likes better.
If you are on a C5 or earlier Hub it may help to try to do a zwave repair on the end device once in awhile.
Another thing to try is when Hub commands don't work to the device, try manually waking / triggering the device at the device. That should force it to find a route back to the hub that works.
On a C5, a zwave repair is an all or nothing affair. Either repair the entire network, node by node, or do nothing. When I first started building my zwave network I'd run a repair right after adding a new device, and with only a dozen or so devices it'd take like 15 minutes. Now that I have close to 40 devices, it takes about 3 hours to run a complete repair, so I haven't done it in quite a while.
If it doesn't throw some beaming repeaters in the mix. I really don't rely on switches in a lot of places to repeat properly because let's face it, in most cases the switch our outlet is surrounded by a metal box. When I built out our new place, I used pvs boxes everywhere, not a metal box in site. I still use repeaters but only have 4 in a 5600sqft house. Hub located in laundry room on 2nd floor (middle of house) and have good strength over all. Same for zigbee stuff. I ended up not needing a repeater for my Lutron stuff once I moved it to the laundry as well (that's the direct center of the house)
So hub got closer to A1 but further from A2. I thought since A2 is hopping from A1, it'll be fine.
But to my surprise I could not send commands to A2 anymore. When hub moved back to original position, it started to work again. Was able to move it back and forth and reproduce the issue.
So that just means the Hub increased its transmission power? That would be the only explanation.
I dislike not being able to see the inner details of how each device is hopping. And its power transmissions etc.
No it doesn't only mean that. It could mean many different things. You can't see antenna orientation or the radio waves, so you have no idea what is happening between position 1 and position 2 without a sniffer and frequency analyzer.
A sniffer setup, and located properly, can help with some of that. Every packet shows its intended route. It still does not show the list of possible routes inside a device, of course.
I don't remember if you said which version of the hub you have, but the C7 hubs show the route a packet takes in the wave settings display. They will also the neighbor table (as the hub knows it anyway)/topology as well.
Also, any time you move a device or the hub you should try to initiate a command FROM THE DEVICE so that it can verify it has a route. If it does not it will try other ones, or send an explorer frame as a last resort to find a new route. If the device sends messages unsolicited, this should happen automatically on the next report it tries to send. If the device never sends unsolicited reports, though, you will have to initiate a message from the device manually.
A similar thing happens when sending commands from the hub, but it is not the same and has less options for rerouting, as it doesn't know for sure what neighbors the end device has after you have moved the hub. So since it is working with an old routing table it can just as easily assign a bad route it thinks is good based on the old location, but is not any more.
It really just sounds like you need more repeaters. Especially if you don't want to get to the device to force it to send a message (because it is in the wall/hard to get to).
Hubitat recommends to add zwave devices and then dont do any automations and let nodes heal itself.
If I did add automation straight after adding zwave devices, i know the devices wont be as responsive since they dont know the optimum route yet. But wouldn't it self heal within 1-2 days anyway? or does adding automations STOP zwave from auto healing?
Somewhere on the internet it said adding automations right away will cause alot of problems down the track. Just wanted to know if its temporary or permanent problems?
