so I had an issue that was plaguing me with nearly all automations stopping working for 4-5 days as I had no time due to work to look at it. the chance came last night to troubleshoot so I sat down and looked at the logs…and saw a lot of my motion sensors were reporting an issue with capability “Tamper Alert” on line 49… A few days ago I developed a device handler for the new Fibaro motion sensor and I started the development on an unpublished copy of the original fibaro motion sensor code which was developed by Mr. Wackford which I originally used to set the parameters of my fibaro sensors but didn’t uninstall from a few of my sensors.
So basically those sensors failed to work correctly, one of which was my upstairs hallway sensor which job it is to disable the alarm if someone wakes up in the night and decides to go downstairs to get a drink etc…
So as I said i’ve been busy with work and working away but as it turns out I found out that my son triggered the alarm as the upstairs sensor wasn’t working the other night and the siren was triggered he didnt know how to disable so turned the power to the siren off (but there is a battery backup) so the alarm Sounded for 5 mins and turned off.
The siren is centrally located in the house and as it turned out a lot of relays and lights etc were using the siren as a repeater so the fact it was powered off was causing havoc with a huge number of devices.
So a simple mistake by me which stopped a few motion sensors reporting correctly had knock on consequences with my zwave network and caused severe disruption to my ST install.
I’m left with a single concern after this episode, this is the distinct lack of Zwave tools. It was not obvious which device to check as I had roughly 15 devices reporting errors during a zwave repair.
And l wonder how many other people making a similar schoolboy error would be on the forums slagging ST immediately? The other factor was that around the time this issue started the hub was also updated. So I could have drawn conclusions too early 
anyway let this be a lesson to you all to dot your i’s and cross your t’s before raising a support ticket or posting on the community with bad blood
Also a reminder of why best practices calls for at least two repeaters per zone… 
engineer’s joke
Section 3: Mesh Networks
- Why should you always have at least two repeaters per zone?
a. To balance the harmonics
b. To increase signal strength
c. Because some day someone is going to unplug one
Trust me, if you’re a field engineer, this is really funny. 
I understand the best practices with repeaters, but why do errors in devices and apps have to go unreported? (except when manually digging through the logs)
How about a little warning icon on the “Things” tab for the device? We show open/closed/motion/no motion…, but never “Warning”
Boy, oh boy. These are even worst than my medical jokes.
More tools would definitely be nice.
It’s unlikely that you’ll ever get a real-time warning with a mesh network: mesh just isn’t designed for that.
However, quite a few systems (like Iris) do a once a day wellness check which can be useful.
Recently several community members here have been experimenting with looking at the logs rather than polling the devices, which is a clever way of avoiding too much traffic on the network.
Here’s a recent release of one smart app that might do you some of what you want:
I already have this. My experience with ST is however even with though another repeater is available the failover doesn’t work reliably and some devices just don’t respond properly. And best of luck running a zwave repair the hub still tries to use the device with the issue.
We finally have serious resources committed to Device Health, which is the project to tell you when your device isn’t connected and things like that.
The most foolproof way to make sure a sensor is using repeaters properly is to rejoin it after the repeaters are in place. You actually don’t have to remove it first to do that, you can just go into “connect new device” mode and press the button however you would to include/exclude the sensor and it will rejoin. However, you have to look at the hub logs on the web ui to see it join. It won’t pop up in the app because it’s not a new device. We’re planning a better interface for that procedure but it hasn’t been prioritized yet.
That’s good news as its been my pet peeve especially if like me you’ve been messing around with fibaro’s UBS as when you taking it offline to solder and mess around it causes havoc until it plugged back in or removed from ST…this factor has me worried, definately further debug tools are needed. So good news all round
For my understanding, I thought all zwave devices acted like repeaters in a mesh network and the same for zigbee? So I am trying to understand what you asking for here:[quote=“duncan, post:9, topic:41774”]
The most foolproof way to make sure a sensor is using repeaters properly is to rejoin it after the repeaters are in place.
[/quote] So how do I tell which of my devices are repeaters? Better yet, what is the preferred way to know where I need repeaters to be put in place as you say?
All battery powered zwave devices do not act as repeaters, only mains powered ones do.
Battery-powered devices do not repeat.
Most mains-powered devices repeat, with the exception of smoke alarms. So light switches, Inwall receptacles, pocket sockets, relays, mains-powered motion sensors, some light bulbs.
The quick rule of thumb is to place a repeater every 40 feet inside a typical US home, but a lot depends on local architecture. This issue is the same as WiFi dead spots; you may need to add a few extra to get around specific architectural barriers.
You do not need to buy single purpose “range extenders”–the newer light switches etc all work just as well as repeaters, and there’s no reason to waste a hop on a device that does nothing but repeat.