I had suggested a feature years ago which was being considered but don’t know what happened thereafter. Instead of having the user run zwave repairs manually which can be painful for many, when the hub detects degraded communications it should automatically run a zwave repair. Or automatically schedule a z-wave repair once a month at the dead of night, that should be simple enough to keep things running smoothly.
1 Like
@HA_fanatic
Well I am not necessarily saying that. In the situations I was seeing, the device was mis-behaving, but communications might have been fine.
I would assume that a clean zwave repair implies commands and being routed
@RBoy
That’s a great idea! Except that until the system can be enhanced to run a zwave repair and fix all errors in one zwave repair, running zwave repair automatically has the possibility of leaving the mesh in worse shape.
This would be true in my environment as it takes 3 or 4 zwave repairs in a row to get a clean zwave repair.
And then send new sets of batteries to replace in the locks. Z-wave repair uses 100% of its power. An unattended repair can kill the batteries very quick.
Repair commands are specific to repair. Device capabilities are different clusters.
Anyone having issues with Schlage locks not reporting status or at least taking an incredibly long time?
I am using @ethayer’s DTH and Lock Manager. I remember reading about changes related to locks so I figured I would try using whatever ST proposed as DTH. I excluded the lock and tried including it with the new app… fail… it found it as a Z-Wave Device, told me it did not support security features and the lock itself said the inclusion failed.
I excluded it again and tried to include it using the classic app. It took way less to find it and it proposed the default featureless DTH.
The reporting issue did not improve. The lock seems to report the status change only it you open/close it via the app.
The locks used to report their status way quicker a while back (possibly before this last series of betas). I have lots of beaming devices all around the locks, and I already ran several network repairs (no error related to the locks)
you can manually change the DTH it uses in IDE to the stock Z-wave lock which runs locally and also works in STSC.
if you remove the custom DTH and then attempt to join the lock it would default to the ST stock DTH.
I thought it had already selected the default DTH but it had picked yet another custom DTH. I changed it to Zwave Lock with Codes but it still showed Cloud so I ended up picking Zwave Lock. While it seems to have improved a little, it is still way worse than it used to be.
Maybe a regression from <18.18 where there was some issue that prevents Schlage lock status reporting?
After setting it with a DTH that runs local, did you do a zwave repair?
And if you did, can you get a clean zwave repair, no errors?
Not sure this is the correct place for this question.
I have 2 new zwave repair failure messages and wanted to know what they meant, more than just what the error states.
Failure to update route
Failure to delete route
Got these 2 different messages from 2 different devices.
When I get “cannot update neighbors” I am assuming the neighbors are other devices that might be “asleep” or busy or whatever.
But for the cannot delete old route, why would a device be unable to delete a route?
I thought I’d post an update to my thread above where I stated that my FortrezZ water meter would go offline after each and every zwave repair I did. Well today that finally stopped!
I don’t know if I’m below some magical device count and the FortrezZ device can now handle the table size, or what, but this is a first since forever.
fyi @Kianoosh_Karami
I keep running repairs and keep getting lots of “errors” reported for varying devices. Things appear to be working however, regardless the number of times I run the repair, the errors do not decrease, they go up or down each time.
This is the most recent one:
Ignore the “Zwave Controller” as it is the HomeSeer USB
Zwave stick I use to update device firmware. The other devices shown keep changing so there doesn’t seem to be a connection with one specific device or area. In the past the behavior was different and issues had a repeating pattern and would tend to decrease by running several repairs.
1 Like
Have you received 25.24 yet?
Not yet. My v3 is still on 25.22
Since 0.25.24 has now been released, please use this thread for future comments: Hub Firmware Beta 0.25.24