[Solved] Zigbee Instability is back!


Hey NoWon, I know this is an old post, was it by chance an Enerwave Zigbee Outlet ZB-333 ?
I just had the same thing happen to me, about 2 hours after I paired it, pulled it right off as sonn as XBee showed the ghost, and the ghost vaporized.
Even on ST the logs showed a constant stream of zbjoin messages for this plug, guess it never intialized properly.


no they were Orvibo outlets I had 2 and both did it. Removed both no more problems.


It needs more work before I consider it done. It's a lot of code to install and I am not sure if I have enough time to provide any kind of support on it. No promises other than I'll consider releasing it.

Thank you for the kind words. Zigbee is running smooth like butter now. :slight_smile: I don't know when the fixes will be put into production, but they're coming.


I did notice some slowness with my Hue Motions after the 2.0.5 update sometimes up to 15-30 seconds until it registers motion. I know there was updates to the driver and I did hit configure for all my Hues after the update. I did not have any issues before the update. My Iris motions are also working fine.


Almost there...

I have 13 devices (that I know of) left to move to Hubitat. Unfortunately since Hubitat doesn't allow LAN event subscriptions in apps it's going to take a bit of re-writing the drivers for 10 of them.

Finally can see the light at the end of the tunnel!


When the firmware update is coming? :joy: I know, I know


Thank you for your perseverance. I would have given up long ago. Following this thread has helped me believe this is the right choice for me. I just got this hub to replace my Iris hub.
I guess the good news is this happened while the Iris servers are still up as it would not have been available as a debugging tool in about 5 weeks (ends 3/31)
Again thanks for your effort and explaining your step by step approach so even a dummy like me could understand.


Could you just expand on that... it seems pretty significant for a ‘local’ hub implementation but I’m hoping I’ve misunderstood.


No misunderstanding. @chuck.schwer covered the topic in this post.


Move complete!

The move from SmartThings to Hubitat is now complete. I still have the Arlo cameras and Ring Doorbells running in ST, linked to Hubitat, but all other devices have been moved over! There is only one device (that I know of) that remains to be connected. It's a SmartPlug for the basement dehumidifier (which actually died a few weeks ago) that was used to control it. As soon as I finally get around to replacing it, I will re-pair the plug. With that in mind, I'm declaring the migration to be complete.

Technically, my system now consists of 4 hubs; the coordinator hub and three remotes (Hub 1, Hub 2, and SmartThings). I've created a custom app called HubConnect to link all of the hubs to the coordinator.

As I mentioned, I split both meshes across two hubs; one for the basement & 1st floor, and another for the 2nd Floor, Attic and detached garage. The coordinator hub has all cloud integrations, plus devices from both hubs and SmartThings.

This strategy is serving me well. I'm localizing automations to their respecitve hubs whenever possible, building automations on the coordinator whenever a rule requires devices spanning multiple hubs. The diversity of this arrangement has really given me unprecedented flexibility and reliability as well.

I had to make another tweak to the Zigbee stack yesterday to accommodate growth from moving the remainder of devices from SmartThings. The meshes are holding stable after that change. Dashboards are just about complete although I estimate that between 60-80 automations remain to be rebuilt.

As soon as the production changes for the Zigbee stack are released I will be able to, in good conscience mark this thread as resolved.


Great news. Many following this thread.

How are you able to make changes to the zigbee stack?


And I suppose your app links the devices exactly as they are in the original hub? I mean, for example, a Xiaomi Cube has multiple functions, but the hublink/link to hub apps will just share buttons.

I hope you release your app.

Now back to your project, I'm very happy you got everything working, probably I was the #1 here, without any power, to try to do anything to make you stay. Well, I did nothing, but you still here and that's great because you have gave us a lot of good info and help to resolve stack issues. Thanks.


Quite pleased that everything reach a great outcome.
It was nice to see that after the initial challenges HE and you were able to identify the issues and work together on improvements to the zigbee stack.

I also would like to see that app.
Wish as well that HE can growth in EU as importing the hub is currently too much of a high cost to have 3/4 hubs.


What benefits do you get from running the Arlos on ST and bridging the hubs? Is this just to solve the problem of passing motion detected events through to Hubitat, or are there other benefits? I do this with IFTTT, which is a bit slow and obviously internet dependent, but I think any Arlo integration will be. Are there other benefits to help rationalize plugging my ST hub back in and setting up the bridge?


For the moment, Hubitat does not support the Arlos. The integration seems to be slightly faster than IFTTT.. But more importantly right now I can expose battery and sound detection in addition to motion.

Current States
battery : 90
motion : inactive
sound : not detected

For me it's cleaner... I don't have to mess around with creating virtual switches or contact sensors. Nothing irritates me more than having a switch that's really a motion sensor, or contact sensor that senses motion. It's way too "hackish" for me.

I can also expose the methods to trigger recording as well. I haven't gone to that level yet.


I haven't decided whether I'll release it. There are currently 4 apps (server parent, server instance, HE remote, ST remote) and 23 drivers to install. It's certainly not for the casual user. That's a lot of custom code and a lot of potential things that can go wrong.

I have made sure that all core attributes are exposed where applicable; i.e. battery, humidity, etc. I have several Halos, and those have a crap-ton of attributes (smoke, carbonMonoxide, battery, temperature, humidity, switch, level, pressure) not exposed by HubLink so that one required some effort.

As I said, not sure I'll release it, but I'll give it some consideration once I've been able to burn it in over a few weeks.


Is zigbee stack part of firmware?
Is there any way to beta test ot for me?
I did migrate around 100 zigbee devices to hubitat about year ago and run into zigbee problems. (Iris contact sensors staying open, some binded devices didn't turn on while some did, lightbulbs turning on sometimes and sometimes not etc.) On smartthings run everything without hickup so i migrate all bact to smartthings . I have lot of jasko zigbee dimers, they just recently added physical reporting to driver, so i try another migration week ago.
Unfortunately same problems. I thought only thing is that my hubitat zigbee stick is bad since all devices are on same place, coincidentally they released c5. So that is on my way now. If its just some bugs in zigbee stack i will have 2x hubitats to play with :slight_smile: