I have (2) Zooz ZSE43 tilt sensors (battery powered) in my garage that were installed prior to me adding a Zooz ZEN76 switch in the garage. Currently, all 3 devices route directly to the HE. The north ZSE43 works most of the time, but occasionally fails to indicate the door being closed. It may fail to indicate door open as well, but I rarely check the status with the door open. This sensor is further from the HE than the south sensor. I'd like to get the ZSE43 sensors to route through the ZEN76 switch. How can I make that happen?
Short and oversimplified answer: you can't. ZWave routing is not user-configurable and once it finds a working route it will stick with that route even if it is not optimal.
Did you include the tilt sensor after the power switches were already in place? It is possible you could exclude the tilt sensors and re-include them with the power switches already there and it might route through them, or it might not. To @thebearmay's point below a repair might have some effect also.
What's interesting though is your signal strength and RTT all look strong though there are a bunch of route changes, which doesn't seem to jive with the signal strength. Those stats are all reset at reboot - I'm guessing you rebooted recently. Would be interesting to wait a few days and see what's going on.
It is possible the failure is not related to zwave at all.
2 Likes
Sometimes, but not always, doing a ZWave repair on a single device will allow it to find a different route, but there is no way to specify a set route. If these are battery devices, make sure to wake them prior to doing the repair.
2 Likes
Patience... I know that's a frustrating answer but give it a few days to settle in -- it will likely resolve itself.
Attempting to shape/steer/influence z-wave routing is a sure-fire path to madness... Place good repeaters in good places and it should all sort itself out eventually - it's just not ever immediate gratification.
3 Likes
Excellent point. @user3571 is this a new install or has it been around for a while?
This is a new installation.
No, the tilt sensors were the 1st devices and the switches were added later.
I guess I was considering excluding the tilt sensors and adding them back in. Not advisable?
If you don't have a lot of automations tied to the tilt sensors that would be the quickest way to get them to find a more appropriate route.
Well... the general rule of thumb is add repeating devices first, let things settle, then add non-repeating devices. I don't think what you're suggesting will hurt, but it might have no effect at all.
See this:
https://docs.hubitat.com/index.php?title=How_to_Build_a_Solid_Z-Wave_Mesh
1 Like
The tilt sensors are only on my dashboard. Do I remove them from the dashboard, exclude them, include them, and then restore them to the dashboard? I also wanted to replace the batteries as they're at 24% & 56%, which is a bit troubling as they've only been in service for 3 weeks now. Would that be best done after they're excluded?
That would be the correct order. Battery drain is probably due to a lot of retries…
2 Likes
That battery life is odd. I would think you'd get a year or so out the batteries. I wonder if they are generating a lot of retries and that's sucking the life out of your batteries,
What I usually do is create a virtual device like "tilt sensor A virtual" and use the swap devices function to swap the real device for the virtual one. Then do your exclusion and your inclusion and swap the devices back.
1 Like
You may be able to assign a priority route using PC Controller paired with a zwave stick as a secondary.
@Tony may know more.
Priority routes are indeed a 'thing' in Z-Wave but there's no mechanism (AFAIK) for HE users to set them...
Currently, new Z-Wave routes can only be established in one of two ways:
-
Calculated by the hub and transmitted to the device (Only the hub/Z-Wave controller is able to determine a Z-Wave path based on node adjacency, hop count or RSSI). Routes (and a few backup routes) get calculated and distributed to a device only when a 'neighbor update' is requested by the hub (during a scheduled maintenance or user initiated repair) or at device inclusion time.
-
Mesh flooding by a device via explorer frames, triggered only when there have been permanent failures of the current working route and all stored backup routes (in each case after multiple retries and their associated timeouts). That's what's happening during the extreme delays that are sometimes observed.
Without intervention (or flat out failure to deliver a message), Z-Wave doesn't optimize marginal routes (ones that always eventually work, albeit only after multiple retries potentially involving multiple second delays).
The reason for 'waiting for the mesh to settle' is usually appropriate (for Z-Wave) is because in a poorly performing mesh there's a high probability that retries (and permanent failures) of stored backup routes will eventually happen (during which time explorer frame flooding gets another shot at establishing a new working route). But when sleepy devices are involved, it can take a long time for everything in a mesh to improve.
3 Likes
I've just had somewhat of an epiphany in regard to the troublesome north tilt sensor (S1 on the drawing). It only reports closed correctly when my car is in that garage stall. My goal would be to get it to hop through the switch S3.
Question: Do my sleepy devices (tilt sensors) know whether or not their change of state message to the hub was successful or not? The mention of retries seems to indicate that sensor must be waiting for an acknowledgement from the hub that the message has been received. I guess if the hub doesn't know that the device can't talk to it, why would it even think about improving the route. Not sure how to proceed from here. Maybe do the exclude/include thing with the car out of the garage?
There should be an ack received (along each hop) for every message successfully transmitted (or repeated along the way). If there's no ack, then the 'retry, wait, repeat, fail/try backup route' scenario happens. The hub won't ever try to improve a route (as in, find another via frame flooding in the absence of a scheduled 'neighbor update') should this scenario eventual succeed.
One potential issue with garage door sensors is that when cars are in the garage, they can interfere with the signal path. Garage door tilt sensors (I use the Ecolink TILT-ZWAVE2.5-ECO sensors) work best if installed on the topmost panel of a multi-panel door. That way, the sensors trigger quickly as the door is opening and do not show closed until the door is fully closed. That also places the above the height of most vehicles.
In order to insure a good signal path between my sensors and the hub, I suspended a Z-wave signal repeater from the ceiling of the garage using an extension cord so there is a clear signal path from the sensors to the repeater even if vehicles are in the garage. The repeater, and both garage door sensors are normally connected directly with the hub at 100 kbps, but if there is ever a signal issue with the direct path, the sensors can connect through the elevated repeater.
Well placed repeaters can turn a flaky z-wave mesh into a stable one. It is better to have to many repeaters than too few.
2 Likes
That is how I have them installed
I could probably install a repeater in the outlet for the double garage door opener. It's in the ceiling midway between the door and back wall.
Putting a powered device into the same outlet as the gdo is plugged in can help too. A ZEN16 or ZEN17 makes an excellent line powered repeater and dry contact input for wired door sensors. And it can sit/mount on the gdo or strapping.
1 Like
I just ordered a ZEN17 as I do want to be able to control the doors as well as monitoring them. This should act as a repeater for my ZSE43 tilt sensors and if that doesn't work out I'll have the option of using "stupid" reed switch sensors.
2 Likes
