I am not a noob but far from an expert. Recently, I added a Zoos Tilt/Shock sensor to each of two adjacent garage doors. I have a few Zoos 32 scene controllers, and through the blueprint, I can have the LEDs on any particular button monitor a separate entity. So the idea was to program two of the Scene Controller’s LEDs to monitor the tilt sensors displaying red if the door was open and green if it was closed. The Scene Controller is near our bedroom so the idea is that a red light will catch our attention before bed time reminding us that we need to close one or both garage doors.
At first, it worked but within a couple days, I noticed that the state of Tilt Sensor 2 was often inaccurate. I started poking around in the Network Graph and noticed that Tilt Sensor 1 had a rather direct path to the controller and Tilt Sensor 2 went all the way to the extreme opposite corner of the house and (I think) then to another node before going to the controller.
I THOUGHT I had discovered the problem so without really understanding what I was doing, I manually created a Primary Path mimicking Tilt Sensor 1. That seemed to work but not leaving well enough alone, I did the same to the garage mandoor lock.
I have since learned that I should probably keep my grubby little fingers off the network chart options and let the system do it’s thing, but after the lengthy preamble above, here’s what the problems are.
My Door Lock showed failed. I reinterviewed the node and it came back but looks like I would expect from a failed initial inclusion with unknown manufacturer, product and product code. (See graphic attached).
I’m sorry for the long post. I probably didn’t include enough info, but still looking for help.
I have deleted all priority routes I created and clicked on rebuild routes. Before I start clicking on more things I apparently know little about, can I get a little help? The network graph does show that all devices do have a path to the controller FWIW.
You are overthinking things here. When a device goes offline or to sleep, it will become “Unknown”. If a device is far from the hub (usually a Z-Wave dongle on your Home Assistant host computer), or far from a repeater, you could lose connection and it will be “unknown” to Home Assistant.
I am unfamiliar with the sensor, but I will assume you are using this one.
In a Z-Wave network, devices communicate through a mesh topology, meaning each device can act as a repeater to relay signals from other devices. This helps extend the range and improve the reliability of the network.
Repeaters are typically mains-powered devices like smart plugs or light switches that can receive and transmit signals from other Z-Wave devices back to the central hub. This ensures that even devices that are far from the hub can still communicate effectively. Battery-powered devices are rarely also repeaters.
Regarding the map- Z-Wave devices periodically check for better routes to improve network efficiency. This can result in changes to the network map as devices switch to more optimal paths.
From your description, I would guess that your sensor is unknown because it is too far from the hub or a repeater device to maintain a solid communication link. Try swapping the sensors (assuming you have a 2-car garage) and see if the erratic behavior follows the device or the location. If the problem follows the device, you may have a poorly-performing sensor. If the problem follows the location, then it is likely your signal strength. If it’s the latter, you just need to add a repeater device between the sensor and the repeater.
Thanks for the reply. Yes, that is the correct sensor. One sensor is on each adjoining garage door, so just a short distance from each other and essentially equidistant from every other node and the controller itself.
One odd thing is that though both are a few weeks old, one battery is at 70% and the other is at 36%.
The other part of my question is about a Schlage smart lock that during my screwing around with building a priority route for it (which I now realize was a fool’s errand), the device showed dead. I re-interviewd the lock and got it back but it shows up as Unknown Mfr, device and model. Oddly, it is still partially functional as I can use the HA app yo lock and unlock the door (but not consistently).
That lock is only part of two automations, so maybe I should just exclude it and re-add it or delete it as failed and start over?
Thanks again for your help to my somewhat incoherent description.
That isn’t unusual. You don’t know how long the batteries were on the shelf before you got them. Is the 36% device the problematic one? The % of battery is a guess based on voltage and it varies wildly from one device and the other.
I’m pretty sure that it will until the lock broadcasts it’s properties.
Yes, the 36% is the problem one. Maybe I’l start with a fresh battery.
So the lock needs to wakeup at some point and broadcast it’s properties? I’ve tried to research how I manually wake it up, but haven’t found anything yet.
