[Solved] Zigbee Instability is back!

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.

1 Like

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.

12 Likes

Great news. Many following this thread.

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

1 Like

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.

1 Like

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.

1 Like

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:

Any update if you'll release the hub connect app someday :smile:

I have a 3rd hub coming and looks really useful if other attributes could be exposed to the other hubs.

1 Like

HubConnect is very close to being ready for release. My focus has been on some user-friendly enhancements making installation and deployment as painless as possible.

I expect to have a release ready within the next 1-2 weeks.

15 Likes

@srwhite Forgive me for my simple question. I have read almost the entire post. Impressive work between you and the HE team, thank you.

I didn't understand the need for more than one HUB. Is someone willing to help me to understand the risks of it happening to my environment?

I realize I'm not srwhite, but I also have multiple hubs (4 now, 5 if you count ST, 6 if you count Homebridge, and I do) and maybe my response will assist in understanding.

Most Important: there is no requirement for multiple hubs. People are running a couple hundred devices off a single Hubitat Hub. Using multiple hubs is a choice we have and there are conditions where an additional hub is a benefit.

First, consider a damaged hub. Having everything on a single hub, means your entire Home Automation project is dead. Splitting your devices across two hubs means you're more likely to only lose half the Automation.

Second, radios and the connectivity between hub and Z-device seems to be a limiting resource. Modern Z-devices are often multi-somethings and, especially with power readings, can be very chatty. The quantity of very small command packets sent over the radio can be impacted when everything "wants to talk at once." The queue behind each radio (ZWave and Zigbee) grows and the action appears delayed. Doubling the number of hubs, doubles the number of radios and ideally, halves the queue depth.

Third, Apps and Drivers are able to impact the performance and stability of the Hub. Infinite loops and other programming choices made by one developer can consume memory or CPU. While th Hubitat is a quad cpu, gig mem, computer, It's still a finite resource. Most of us with multiple hubs have looked seriously at pushing "risky apps" to their own hub. Even in dual hub configurations, putting the risky apps on the hub with the least devices can have benefits.

Fourth, is the use of a SmartThings hub either to migrate from, or simply use in it's Cloud capacity to enhance your Home Automation project. WebCoRE has had a very difficult life on Hubitat and some have left it running in ST's Cloud, for example.

The conclusion you reach regarding the choice to add another hub or more is determined by those conditions. The great news is, implementing multiple hubs is so much easier/better via HubConnect.

1 Like

I bet you make a wonderful face when clicking "check for updates" as when a new one arrives......there goes 2 hours....lol

Have these changes made it into the stock FW? I am trying to diagnose Zigbee issues with my own system and have ruled out most everything at this point other then the Zigbee stack or the radio stick.

Yes, many releases back. If you're on the current firmware, all of the Zigbee fixes have been implemented already.