I bought 3 Everspring door contacts (EVR_HSM02) to use with my garage doors.
Due to these being zwave only, it is my assumption that they have to be included while in range of the hub. So thats what I did.
I included these onto the network while they were in range of my hub.
I then took these contacts and mounted them in their locations on the garage doors. This is some considerable distance away from the hub, but in range of three powered Zwave devices (the relays that fire the garage doors).
These powered relays have no problem communicating with the hub, but it seems the two sensors furthest away cannot. They never update status.
lets say the doors are 1,2 & 3. The sensors A, B & C.
the sensors are about 6ft lower down than the relays, so the setup is like this
1-2-3
A-B-C
All relays work in smartthings, but sensors B & C do not. Sensor B is closer to the hub than relay 3, yet it still doesn’t work. Also there is a Zwave+ socket another 15 ft further away than even these sensors, and that works fine - but it is powered and also Zwave+ so not a fair comparison.
I can only assume that the sensors have not updated a routing table, and are still trying to communicate through the devices that they could see when first included, or trying to communicate directly to the hub. which now the furthest two away can no longer see.
Any advice much appreciated.
Is there any way to force an update of the route for these battery devices?
that’s why you repair several times in sequence, to improve the odds of catching the sleepy/battery devices when they wake up briefly and independently (uncontrollably).
It takes a while and still not guaranteed.
EDIT - seems to me you should actuate the door to wake up the sensor, during the repair.
By moving the sensor “into range” and pairing, then moving it out “to final location”, then you kinda guarantee it gets a bad initial routing assignment.
There is a way to wake them for 30 seconds, so I guess its a case of waking them and running a repair, but will they even respond to the repair request if they are out of range - or is that just broadcast through whatever devices are capable of broadcasting?
Run the repair. You’ll get error messages if the hub is not able to reach the devices. But the odds are good that it will work.
Note that it can take a while for each individual device to finish updating its own neighbor tables even after the Repair utility complete, so you may not see the full results until the next day.
Exactly what happens depends on if you have any zwave plus devices on your network as these are somewhat more efficient in this area, but even if everything is classic zwave, it should work as long as the sensors are in range of at least one repeater on your network. ( The relays should be repeaters, so you’re fine there.)
You shouldn’t have to fiddle with the individual devices. Just check the error messages to see if any devices were missed, and if they were, run the repair again.
No errors coming from the hub. But no difference with the sensors. I know they are working as when I included them I tested to see if they would report open and closed.
It’s only since putting them in place that they no longer seem to work.
One funny point is that sensor 3 shows as open (door is closed) and in ide it states last activity an hour ago (or 2 or 3 etc). When I open the door, the sensor shows as open, but last activity moments ago.
I’m just using the default device handler that these get recognised as of Zwave door/window sensor.
I don’t know how I could expect a battery powered device to respond to a repair request if it is sleeping though. Surely a device needs to be awake to do that. Does the hub ignore failures from battery powered devices during repair procedures?
The hub tries a few times. If the device is unreachable, then there will be an error message in the log. (You have to look in the log in the IDE, you don’t get the error messages in the mobile app)
The sensors are in the hub’s Address table, so the hub knows the sensors exist even if the sensors are not reachable.
Again, though, you may not see the results until the next day.
I’m going to try keeping them awake while trying a repair.
It is interesting to note that in ide their last activity is listed as 5 minutes ago. Is this the last time the hub tried to contact them, or the last time they contacted the hub?
If the latter, then I will have to check they have bother parts physically located in a way that causes them to change status when open and closed.
Due to the nature of our garage door installs, their placement is not “normal”, but the two parts are close together when closed an apart when open. I think it’s a range issue with the two farthest away.
If they are reporting, it’s not the range. It’s likely the physical placement. Some models have weaker magnets than others, and that particular brand has one of the weakest.
You can use any magnet you like, it won’t matter, so you can try substituting a stronger magnet piece if there’s a particular placement you’re trying to achieve.
Also, just to be sure, you don’t have them mounted directly on metal, do you? That is mentioned in the troubleshooting FAQ. It can really throw off reed based sensors, although that would more typically take a couple weeks to show up.
All sorted, must have been some form of error during inclusion. Removed the device’s, re-added and moved to location swiftly after inclusion and they are all working well. For now.
