I’d thought I’d post something I just experienced while performing a Zwave Network Repair. Here’s what I sent to support:
I just ran a zwave network repair, and I had 2 devices “Failed to update route”. Both are battery powered devices!
Upstairs Multisensor [B4]: Failed to update route
Upstairs Siren [98]: Failed to update route
Why did battery powered devices get included in a zwave network repair? Since these are sleepy devices and don’t route zwave messages, does my mesh think they’re suppose to route messages and now I have a mesh performance issue?
Let’s see what reply I get (which I bet will be to exclude the devices and redo all the automations). Anyone else come cross something like this?
The battery powered devices still have their own neighbor tables – that’s how they know which repeaters to use for their own outbound messages . So they definitely have to be included in a network repair, or they would never use new repeaters that you added. Same thing if you physically move the location of the battery operated sensor. You need to update its neighbor table or it won’t get its own messages sent out.
As far as what the error messages mean, see the error message FAQ,
In this particular case, “failed to update route” probably just means the battery operated device was asleep when the repair request came by. It’s up to you whether you want to run the repair a second time and try to get it then. If you haven’t physically changed the location of those two devices and you haven’t added any new Z wave repeaters near them or physically changed the location of any old repeaters that were near them, you don’t need to run the repair again, they can still use their old neighbor tables.
Sleepy devices are generally really stupid. They’re all about extending battery life. So they don’t know nothing that happened when they were asleep.
The only exception is battery power zwave locks, which do know enough to check for old messages (that’s what “beaming” is about. But they won’t do anything about a repair.
Remember that is the way repair shut down your entire network. No messages get through during that time. So you can’t do the devices one at a time.
If you miss a sleepy device when you run repair and for whatever reason it’s important for that particular device to update its own neighbor tables, you just run the repair again. Some field techs will ensure the device is awake by triggering it right before the repair starts to run, but it’s not usually a big deal.
Note that if it’s a Z wave plus device there is a chance that it will do its own route exploration once it is awake, but again, that tends to be less to a battery operated devices because we really want to limit the operations they perform in order to extend battery life.
I don’t remember battery devices in any of my previous network repairs, which is why I found this odd. I admit it’s been months since I’ve done one, so maybe newer firmware updates changed this, but I don’t recall battery devices reporting errors like that before.
If they were Z wave devices, they were definitely included. Every device on your zwave network is. But maybe you just didn’t happen to catch any asleep.
It’s always possible. We’re dealing with two separate issues here: the third-party Z wave standard and the SmartThings implementation of that standard.
With regard to the general question of why would battery operated devices be included in the Z wave repair, it’s because they have their own neighbor tables that they use for their outbound messages, and those tables have to be updated from time to time. So A Z wave repair utility includes all the devices on your zwave network.
With regard to the specific question of whether a zwave repair of a SmartThings account is returning more error messages than it used to, I can’t answer that one.
