Weird bug took Zigbee network offline

🛎️ Get Help
1

Here's a weird one.

I'm a new user. I created a new Rule Machine rule to switch an indoor warning light plugged into a Zigbee outlet on and off, as well as turning an RGBW bulb "Red" and on/off to follow the opening and closing of the garage door.. I simply triggered on a garage door state change, then used If..then to turn the outlet/bulb on if "Open" and a separate If...Then to switch the outlet/bulb off if "Closed".

I had the rule initially paused. I activated and tested it out. Both devices switched on and the bulb turned Red correctly. However, when the door closed, the devices remained on.

Back at the Dashboard, the both the bulb and outlet were completely unresponsive from the Dashboard or the Device details pages.

I rebooted once, but the problem persisted. I tried deleting and adding the Dashboard icons, but no difference. Then, I noticed that I had a system alert "Zigbee network offline" in the little "thought bubble" notification area. This time I selected "Power Off" to cleanly shut down the HE. I disconnected the power for a minute, reconnected power and allowed the hub to boot.

The Zigbee network was back, but the devices were still unresponsive. I needed to remove the devices, physically reset the bulb and outlet, re-pair, and repair all of the Rule Machine rules to add the two devices back in.

Quite a chore.

All back to normal now. Very weird how that rule seemed to crash the Zigbee radio hardware.

I thought I would report it.

Regards,

Don

2

Don't delete the zigbee devices from the hub just factory reset the devices and rejoin them to the hub and they will join back in as the name they previously had and still be in all the rules. A lot of times simply removing the battery and putting it back into the devices is sufficient in these cases too.

3

This is pretty unusual, but when the hub is having problems (doing too much work), we've been told that the Zigbee radio is usually the first thing to go. So, that brings up a few questions: what other apps and drivers do you have, paying particular attention to custom apps and drivers (or the beta Chromecast integration)? If they're all stock apps with simple configurations, maybe it was the rule. Did you have any repeats or anything in the rule that might have caused excessive work for the hub?

Also, from your rule description, it sounds like you did something like:

IF (Contact sensor is open) THEN
  Do things
END-IF
IF (Contact sensor is closed) THEN
  Do other things
END-IF

Since you only care to execute one or the other section of actions (and the value is unlikely to change while the other is running), you could do something like this instead (not quite there yet, just showing you the process):

IF (Contact sensor is open) THEN
  Do things
ELSE-IF (Contact sensor is closed) THEN
  Do other things
END-IF

But wait, there's more! Contact sensors only have two contact states, opened or closed. Therefore, if it's not opened, it's closed, so this works equivalently:

IF (Contact sensor open) THEN
  Do things
ELSE
  Do other things
END-IF

Not even the first of these examples should have caused your problem, so I'm not pointing this as a possible cause (though I suppose a lot of rules with a lot of inefficiencies could add up) but rather just as a general Rule Machine tip.

Also, for Zigbee devices, if you need to re-pair them, consider just leaving them in the hub database and resetting the device. Then when they are paired, the hub will recognize them as the same device, so all of your automations will still work (Groups and Scenes is one exception; if Zigbee group messaging is enabled, go in and click Done in each Group app since this involves a setting on the bulb that would have been erased.) This is unique to Zigbee; with Z-Wave, you are not so lucky. But there's also rarely a reason you'd need to do this (sounds like you might have tried the usual tricks...restarting the hub, turning the Zigbee devices off and back on, etc.), so it's doubly unfortunate if your devices didn't respond until a re-pair in the first place.

Hopefully you have better luck with everything in the future!

4

I was wondering if I created a loop somehow, but the logic was so basic, I don't see how.

I considered using the If...Then...Else syntax, except the Garage Door device seems to have more states than just "Open and "Closed". It also supports "Opening" and "Closing" in the Rules Machine, although I have never seen that state appear in the logs.

Just before the trouble started, I spotted this error in the logs:

app:1052020-05-15 06:59:00.236 pm errororg.h2.jdbc.JdbcSQLException: Column "name" not found [42122-197] on line 699 (periodicHandler)

...which looks like an SQL database issue of some kind.

The only user app I have running is the Alexa TTS Manager and the companion Child Alexa TTS driver. I did call these to announce the garage door state, so that may have been a factor. In fact, Alexa did not announce the state of the door when opened, as I would have expected. The trouble may actually have started then, not when I closed the door.

Thanks for the reply!

Regards,

Don

5

Ah yes, if it's not "contact" as I assumed, you my have more possible values to worry about. But again, that does seem unlikely to be the issue either way.

What kind of bulbs are you using? As noted in Hubitat's Zigbee docs, many smart bulbs are problematic if used in the same Zigbee network as non-bulbs. Devices missing messages or sometimes even "falling off" could be a symptom of this.

2 Likes
6

Yes, I agree the conditional statements don’t seem to have been an issue. The actions triggered by the opening/closing of the door were:

  • Change the on/off state of a light plugged into a smart outlet.
  • Change the on/off State of an RGBW bulb and set color to red if bulb was off.
  • Message my IPhone device.
  • Announce garage open/closed with date and time with the Alexa TTS setup.

I did some searching. The Alexa TTS seems to have caused hub slowdowns and issues in the past for some people. It’s a bit of a hack anyway, relying on browser credentials that expire , and a separate server to refresh the credentials. The whole thing seemed to be a potential trouble source and more of a novelty for me than a necessity, so I removed the app and driver as a precaution.

I am using what some consider bad repeaters, but they have been working very well in my smallish Zigbee mesh.

Don

7

I have never known this to be the case. There were reports of older versions of Echo Speaks causing hub slowdowns. But AFAIK, that has never been documented to occur with Alexa TTS. But I'll tag @ogiewon for his input.

The symptoms you described are exactly what happen with bad repeaters on a zigbee network. Bad repeaters are not always bad. They are bad sporadically (and unpredictably), with outcomes such as those you described.

3 Likes
8

Thanks! The network is too new to tell, but I'll continue to monitor the situation for stability and start replacing the older Zigbee repeater products over time.

I could see repeater issues causing end devices to fall offline or not respond. I have a harder time imagining a flaky repeater crashing the hub, but I suppose it might be possible.

I had NO visibility into the Wink Zigbee network, so having any kind of logging and routing info is all very new. I'm tempted to buy a cheap dongle and set up some mapping software.

Best,

Don

1 Like
9

Since you are technically inclined, can I suggest setting up an Xbee3? You'll see all the routing information you can. Plus a lot of devices preferentially will route through the Xbee3.

Edit:

Here's the link to the everything Xbee thread. Great set of instructions from @NoWon!

1 Like
10

No reports of AlexaTTS causing any slow down issues thus far. There were some unhandled error scenarios a long time ago, which I resolved a long time ago. :sunglasses:

2 Likes
11

Thanks for checking!

I'm going to chock it up to massive and near-obsessive fooling around with the Rules engine causing some corruption and watch for recurrence. :grinning:

Don