Hub Firmware Beta 0.25.22

I still have to investigate the “errors” for when the device fails to update the mesh info. Hang tight, I will provide some info. I am curious as to what situations devices consider “error”.

2 Likes

I’ve seen that for a while now. Sometimes it runs clean, the next time it has logs entries about unable to update mesh info from active devices.

2 Likes

@Kianoosh_Karami

Here is one

Last three repairs I did. They’re all over the place. (Asterisks in messages are added by me for emphasis). All devices are online/active.

**Z-Wave Repair (03/02/19)**

Started: 2019-03–02 2:05:30 PM
Finished: 2019-03-02 2:36:38 PM

* Kitchen Table: Failed to Update Mesh Info
* Driveway Gate Opener: Failed to Update Mesh Info
* Formal Living Room Chandelier: **Failed to Update Route**
* Patio Door Lock: **Failed to Update Route**

**Z-Wave Repair (03/02/19)**

Started: 2019-03–02 2:42:10 PM
Finished: 2019-03-02 3:14:51 PM

* Master Bathroom Fan: Failed to Update Mesh Info
* Game Room Overhead: Failed to Update Mesh Info
* Kitchen Table Fan: **Failed to read protocol info**
* Water Shut-Off Valve: Failed to Update Mesh Info
* Guest Bathroom: Failed to Update Mesh Info
* Study Bookshelf LEDs Failed to Update Mesh Info
* Driveway Gate Opener: Failed to Update Mesh Info
* Clothes Dryer Outlet: Failed to Update Mesh Info
* Entryway Chest Lamp: **Failed to Update Route**

**Z-Wave Repair (03/02/19)**

Started: 2019-03–02 3:20:54 PM
Finished: 2019-03-02 3:51:40 PM

* Water Shut-Off Valve: Failed to Update Mesh Info
* Clothes Dryer Outlet: Failed to Update Mesh Info

I was alluding to investigation with regards to what prompts devices to fail the action.

1 Like

Yikes!!! I cannot believe your mesh is even working in those conditions. You likely have ghosts in your mesh or repeaters that are offline. Screen those errors for unknown devices. Power cycle each failed device. You may need to even exclude and include devices to repair your mesh. I said it before and I say it again…

@Kianoosh_Karami, nice share! It seems to me that repair takes longer on .22 than before, or maybe I haven’t done a repair in a while :slight_smile: It would be nice if we could see what repair does as it runs, rather than just the exceptions :slight_smile:

@aruffell, @Nezmo , that’s what you want to see …

Yeah, you will see that…if you have crappy devices… :thinking:

2 Likes

I’m jealous, lol.

1 Like

Get rid off your bulbs and your repair will look like mine :slight_smile:

I have no Z-Wave bulbs.

I will add, my mesh seems to be operating just fine. I did have some flaky devices which were causing terrible operational delays all over. I removed them and since all has been fine. That was all before the repairs I posted above.

Dang it! What are the “LEDs” in your list? I really think you have a crappy repeater if not some ghosts. Only one can create havoc.

Obviously “all” is not fine based on your repair logs. But if you are happy with your mesh, then that’s good. It would drive me nuts to see those in my logs :slight_smile:

Fibaro RGBW Controller (FGRGBW-101).

1 Like

The problem is that the messages we do get from a repair do nothing I can see to help us troubleshoot. Every time I run I get messages on different devices. We do not get info on what device(s) may actually be causing the issues.

1 Like

That’s because the hub doesn’t know either. All it knows is that these devices fail for some reason. The hub is unaware of what the cause is. It’s the “detective” in you that has to figure out what the problem is :slight_smile:

Here is mine again

I opened and closed the garage door, rebooted the hub remotely and ran the repair again…

Now I can call my lunch over and go back to work :slight_smile:

I get it. Doesn’t make it right.

As for being a detective … I’m not about to start taking out devices to troubleshoot. That would be a virtually impossible task. The bottomline is we need more visibility in to the mesh. Relying on ST Support is not an option these days.

I hear you, but in the absence of both we have to work with what we have LOL

@HA_fanatic

If I understand the info you posted, your setup behaves similar to mine. Around 9 minutes to do a repair. If the repair has any errors run it again until no errors.

@Kianoosh_Karami

So the question, while 9 minutes a repair is great, less than the hour the math suggests.

Can the zwave repair be modified to…
Suppose instead that the repair took twice as long, 18 minutes, but logic is to wait until all devices have no errors.

And the logs could report status as it goes,
Example log messages
all devices contacted successfully
Devices still updating neighbors
5 devices still updating neighbors
4 devices still updating neighbors
3 …
All devices updated
Zwave repair done, no errors

1 Like

He did say it should be “considerably smaller” :smile:

It would be nice to see which devices cleared and then stop at the first error and say you dummy go fix this device then try again :-:rofl:

@HA_fanatic

Well now we are just asking for more and more functionality :slight_smile: lol!!

My guess is that there is a limit to how much the hub knows about why the errors are occurring.

Usually in my case, it is just time, I need to re-run zwave repair enough times over a long enough time, that the devices are all able to find all of their neighbors.

Most of the time in my case, the zwave repair errors does not require me to do anything with the end devices, just re-run zwave repair.

In fact there have been times when the device, lets say a zwave in wall dimmer, in which the device needed to be power cycled to correctly work (air gap or breaker) but the zwave repair for that device was clean!!!

The device did need a power cycle to properly work, but the zwave repair was clean before the power cycle!!

In other words, the zwave repair did NOT detect that the device was not working correctly.

Yeah, that just shows the repair is effective only so much. Just because the device is updated in the routing table, doesn’t mean it transmits the other commands properly.