You are unlikely to see a repeat of the problem where the Zigbee radio went down. We think it had to do with the timing of your update and some middle of the night hub maintenance tasks. But, we are still looking into that as the possible cause.
3 Likes
Just curious. What zigbee devices do you have? Is it all xiaomi? Any routers? How many devices?
Thanks for the update
No routers or extenders.
Nothing connected to z-wave...
Connected to Zigbee radio
All Xiaomi devices
- 2x Original Motion
- Original Door Sensor
- Original Button
- 2x Original Temp/Hummidity
- 1 Aqara Motion Sensor
- 1 Aqara Leak Sensor
- 1 Vibration Sensor
I have not there yet to move the backup devices from ST. ST has been powered down.
So I'm glad to hear that the evidence is pointing to an unfortunate chain of events that took the Zigbee radio offline. I never thought it was the Xiaomi devices, but suspected it might be a conflict. Looks like it was a fluke occurrence.
I apologize for any confusion. It seemed like you describing a Zigbee radio that kept going off line, not one that went offline just once. Anyway, I'm glad to hear it's now been stable.
So back to the Xiaomi. Hubitat's position on the Xiaomi devices is a very valid one, I thing you can see that. Just because millions of people drive their car on the right, doesn't mean the people that are driving on the left are doing it wrong. In other words, no one is really wrong here (but Xiaomi is a little wrong 
). SmartThings doesn't support Xiaomi devices either. In fact, I don't think anyone buy Xiaomi officially supports Xiaomi today. This is not to say that is doesn't work.
Now you need to get some routers. Xiaomi devices do not have strong radios in them. They run on very small batteries, so you cannot expect them to have a very high power output. They need repeaters to stay stable. Many of us here and on the SmartThings forum have figured out how to do this, an it's working well. But, that doesn't obligate Hubitat to support any part of that integration. That's all on us.
The IKEA Trådfri outlets definitely work. I have mapped this and several others have as well, included @veeceeoh who has graciously given a lot of his time to port drivers for us on HE from SmartThings. The Trådfri outlets are not powerful repeaters, but they are very inexpensive so get a few of them so you have a really well distributed mesh network. With these in place, all the testing and evidence indicates you'll have a stable Zigbee network for them.
2 Likes
I hate to say it but things are not looking so good for Hubitat tonight. I deployed 6 of the 11 new SmartThings gen 4 plugs tonight. I went around and ensured that all of the battery powered devices in on the floor reconnected. I wasn't even done when I started noticing battery powered devices dropping after a few minutes
There are no other SmartPlugs in the vicinity of the devices that dropped that are connected to Hubitat. What's very odd is that one of the devices was literally 6-8" (yes, inches) from a newly deployed SmartThings v4 plug. It dropped after about 12 minutes. A battery pull and the device acted just as if it were new out of the box.
I'm sorry, but I have to conclude from this test that it is NOT a mesh issue. The temporary Iris mesh I'm running alongside (channel 24) Hubitat (channel 19) has been rock solid all afternoon. Hubitat's Zigbee is already starting to fall apart.
I don't get it.
Possible that the Zigbee radio in the stick is simply faulty? No one here that I've seen is having the level of issues you're describing.
From what I have seen on my case, from others, etc if I had to speculate is either the radio is enter some sort of sleep/Standby mode and not awaking on zigbee events.... or it has a high latency issue.
But thatsI me speculating.
Which radio?
The stick... One
Support keeps suggesting it's a mesh issue. But I transferred all but a couple plugs over to Iris as well as a few battery devices. Those have been great. I've deployed 6 of the latest model SmartThings plugs, reconnected some battery devices, and now they're dropping off same as before.
Not a mesh issue as far as I'm concerned.
All your test were with battery devices included?
I don't believe it ever sleeps. Doesn't need to. Battery powered Zigbee devices definitely do sleep to preserve battery, and wake up when they have an internal event, like a door trigger, button push, motion, leak detection, vibration, tilt, etc.
Which devices brand/type are dropping off?
Iris/Centralite
Yes. I moved a handful of battery devices over to Iris today, especially ones I have had issues with before. Those stayed connected all afternoon.
OK. Those are typically rock solid when the battery is good. Sorry if I ask questions that you've answered already. The thread is long, and i'm normally a reader, but just not into going through it all when I can just ask.
What bulbs are connected directly to the hub? They're terrible routers and have screwed me up. Sengled are the only ones that won't cause a problem.
@SmartHomePrimer Is there any situation where you can hypothesis a scenario with the issue be battery devices independent of brand?
Not sure I understand the question clearly. If you mean, can a weak battery cause the issue, absolutely. Can a weak mesh cause the battery device to miss its checkin and so drop off the mesh? Yes, absolutely.
You failed the question.
Let's assume all battery devices have brand new batteries.
Can you postulate a scenario where the radio (on the stick) would drop the packets from the battery devices?
I know that non battery devices check in more regularly. My postulation is if you have a big quantity of battery devices that will normally check in (due to be pairing very close to each other, time wise) at around same time as there isn't any event triggers to trigger them in between, you will the radio enter a standby mode or close the zigbee connection until it receives a knock on the door. As the radio could take just a few milliseconds to wake up, those packets knocking on the door will be lost.
After when not receiving a response from the door (to save battery) they would not try to send the packet back until they are again initialized.
