Firstly I want to say thank you to the Hubitat team for adding z-wave routing details to the UI. Now I have spotted something that I am not sure I should be happy with. One of my z-wave sirens is hopping via a table lamp. Is there any way I can persuade it that the z-wave extender, which is also in a convenient position, would be a better idea? I have tried doing a repair.
Not currently, no. That said, if the zwave bulb is always powered on, it may be a fine repeater.
If the bulb is powere off for some reason, the siren will try another route.
Oh I thought z-wave wasn't as easy-going as zigbee for rerouting on the fly. People tend to turn off table lamps with the lamp's own little switch without really thinking.
The other thing you could try is power off the bulb and do a repair. The only problem there is it still may pick the bulb anyway due to route caching.
This is hilarious, I tried your suggestion of turning off power to the lamp and the effect is that the repair took ages longer this time, and now the extender itself is trying to hop via the non-powered bulb, so I guess none of it will be working now 
The bulb wasn't in its permanent location anyway so I think I will just remove it from the device list until I come to put it in the right place.
Yes, a repair will take much longer if a paired device is unavailable.
Unfortunately there is no way and that is the primary reason these systems are not a good solution for any critical security. I run both zigbee and zWave devices and when any repeater looses power the other devices sending data routed through it is lost. Yes, they will re-route but it takes time, sometimes it takes 20 seconds other times a minute or two. It has been my experience until the device re-routes data will be lost. If anyone wishes to test this all you got to do is cut the mains and see how your system reacts. Of course, this assumes your hub, switches, router, modem is all on a UPS. I wish there was a way to assign specific devices to always remain sleepy end devices.
Well I've only got the one z-wave bulb, I think I'll stick to zigbee for "convenience" devices like lights and power points, and only use z-wave for the obvious security related stuff like sirens and motion detectors - that no one would unplug or turn off just by mistake as they won't look like devices that you need to interfere with in the daily run of life. I've got reolink and nest cameras too, so I am reasonably well endowed with security warnings
Actually, can this even be accurate?
I have three floor levels in this house. The Aeotec doorbell is on level 3, the hub is on level 1. The extender is on level 2. The extender is shown as hopping upstairs via the doobell and then on to the hub. But sensorBP (back porch) and sensorFP are going via the extender then the main hub with no mention of going through the doorbell, which is supposedly the routing from the extender to the hub
Well, there is no way in Hubitat (and almost any other hub) to force routes. For zwave, technically there are things that can be forced on the routing (priority routes).
But to your point, you can't today in Hubitat - so whether the protocol technically lets you do it or not is academic.
I edited my previous post to show the rather strange routing table
Yup, zwave routes in its own funny way. It almost always "works", but isn't always the "route preferred by the user".
Since it uses source based routing, at least for hub initiated messages there are things that the hub can do to force a route. But it gets complicated, and can cause more harm that good in some scenarios if tinkered with without understanding - which is why consumer products don't usually expose/allow this and just let the routing algorithms take care of themselves.
For my routing bulbs, I either hide the string, remove the turn key on lamp socket, or permanently bypass the wall switch(connect wires together in box), or with inovelli switches, you can disable the relay and use switch as button controller.
That'll stop em from disconnecting my bulbs
You may have missed my point. The routing table shows that the extender hops via the doorbell to get to the hub. But other devices that hop via the extender do not show the doorbell in their hops.
If the extender goes me->doorbell-> hub
Shouldn't they be going me->extender->doorbell->hub ?
Nope. It isn't linear like that.
Sorry to be a pain but can you explain why the devices using the extender to connect to shouldn't have to follow the same path to the hub that the extender has opened to the hub? The extender has no reason to be going via the doorbell that is much further away and needs to go through more walls and ceilings as well as round a corner.
I'm simplifying a little, but...
Because the SOURCE DEVICE decides the route - not the repeater. The repeater just sends the packet on unmodified.
When the message packet gets to the repeater it already has the route information in it. The repeater can't change that. It just sends it where the source device told it to.
I don't know why the repeater chose the doorbell for messages it is sending. 
but that was it's choice. Sometimes a repair will fix it, sometimes not. If the mesages are amking it from the repeater to the hub, it will leave it that way if left to its own devices - if there is no problem in routing, then there is nothing to "fix".
Ok I think I understand that bit now. So the sensors are being sensible lol. The repeater wants a lesson or two
Always hard to tell why something picked the route it does. There is a lot of voodoo in routing algorithms...
But, like I said this is a pretty complex topic. Not a lot was really known about exactly how zwave routes things until very recently, as it was closed source/proprietary. A lot of speculation existed (and still exists), but it was just that - speculation.
Maybe it's having an emotional reaction to losing its friend, the bulb.
1 Like
Maybe so. LOL.
