Suggestions for setting up my second HE hub

Hi all,

I just received my second HE hub which I am planning to set up soon however I just wanted to try and get some suggestions from you nice people first.

Reason why I bought is that, I realised I have 47 Zigbee devices connected directly to my first HE hub and I understand that the limit is 32?

How would you go about segregating the devices? Would you do something like essentials on one hub and non essential on the other? If so, would the 'master' hub be able to use devices from the 'slave' hub for setting up rules with? The thing is, some of my rules involve essential and non essential devices so I am not sure how to go about that.

I wish the Hue bridge ( I have one here too) integration drivers available in HE would work with all my Zigbee bulbs (they only work with the HE's Advanced RGB/CCT Bulb ones) so I could perhaps move them all across and free up some slots on my master HE hub - I also tried the CocoHue drivers but they didn't work either. @bertabcd1234 Do you think you could upload HE's generic drivers for RGB and CCT bulbs onto your app please?

I also want (late this year) to have a 3rd hub as a hot-swap but that's easy I guess since I can just retrieve the settings from a backup and go from there. Have said that, does the backup file which you download from 'Backup and Restore' save all rules too? If not, how do I go about keeping a backup from all my rules for some sort of 'disaster recovery' scenario?

Anyway, looking forward to hearing from you.

Thanks in advance.

If you plan on using your hub for anything related to security I suggest any device you plan on using, be it motion sensors, door sensors, etc. be put on one hub with NO repeaters. The reason being is if you have a mains power failure any device routing through a repeater that loses power will fail to send their state, at least for several seconds, up to several minutes.

All my security related devices are on one hub and everything else on another. Since the release of Hub Mesh, it makes this type of integration much simpler.

This really depends on how many repeaters you have. I have close to 100 zigbee devices but many mains powered zigbee devices which act as repeaters.

Regarding Hue you should read this recent thread and recommendations from folks like @ogiewon:

3 Likes

I don't understand the problem as written, but if you describe it further, I may be able to think of a solution. (I'm assuming you know that the "Advanced Zigbee..." bulb drivers are for directly-paired devices, not any Hue Bridge integration, but if not, that is certainly one problem--these are all LAN integrations and need specific, non-Zigbee drivers as are generally provided or selected by the app.)

1 Like

That's a good point - Thanks a lot for your input.

What I mean is that I purchased a Hue Bridge a couple of months ago with the intent to migrate all my zigbee bulbs to it however none of my bulbs worked with the available Hue Bridge integration drivers as I deleted them from HE & added them to the Hue app/bridge:

Capture

Therefore I had to rollback the changes and directly add the bulbs back to HE but before doing so I tried the drivers from the CocoHue app but I had the same outcome.

Hence why I suggested that if you uploaded HE's drivers (as per below) to your app then perhaps I'd be able to re-add the bulbs to the Hue Bridge and use your app's drivers to control them.
Capture 3

I didn't realise that the HE's drivers for the Hue Bridge integration were non-Zigbee though so that wouldn't work anyway right?

I guess it’s too late now, but this alone is not usually a reason to buy a second hub.

As @ritchierich mentioned, there is a limit of 32 zigbee devices that route directly to the hub, without any zigbee repeating devices in between.

However if one has any zigbee repeater devices, each one of those will increase the number of end devices that can be part of your hub’s zigbee mesh. I believe with enough repeaters, you can theoretically have thousands of zigbee devices on one network.

Most zigbee devices that are permanently wired or plugged in (e.g. light switches) function as repeaters. Battery powered devices do not.

2 Likes

I think you have misunderstood how the integration with a hue bridge works.

Hubitat communicates with the Hue bridge over your LAN. That’s true for both the native integration and @bertabcd1234’s integration. There is no zigbee involved, the Hue bridge is using zigbee to communicate with bulbs that are paired to it.

It’s also possible to pair Hue bulbs to Hubitat, with zigbee.

However it’s not possible to see the code for built-in drivers, as they are closed source.

2 Likes

That's okay though, I might just keep it as a hot-swap backup device.

Does the backup file which you download from 'Backup and Restore' save all rules from all apps too? If not, how do I go about keeping a backup from everything for some sort of 'disaster recovery' scenario?

Apps/drivers - yes.

Paired devices - no. So you would have to re-pair the devices.

That's fine, thanks so much for confirming this.

Oh, and re-setup any cloud services/apps.

The Hub Protect service is what you'd use...

https://docs.hubitat.com/index.php?title=Hub_Protect

1 Like

Not sure if you're still interested in troubleshooting this problem, but that is odd. To be clear, you set up your Hue Bridge via the Hue Bridge integration app (whether the built-in one or mine--they both work similarly here), then used that app to add bulbs/groups? Nothing will work if you manually add a device (e.g., by creating a virtual device, even if you choose a matching driver) or if you use a driver for one integration that was written with the other in mind (so switching from/to my integration to/from the built-in does require re-adding devices, for example). If that doesn't work, I'd be really curious what's going on. Your Hue Bridge must be on your network and accessible from the same network as Hubitat, as it is a LAN-based integration. Were/are there any errors in the log, particularly any regarding HTTP?

That being said, as mentioned above, you don't particularly need to do this: there is no 32-device Zigbee limit per se; that number applies to "end devices," which means devices that are not repeaters (or routers, in Zigbee terminology). Each router/repeater extends this number by a certain amount, and with enough such devices there is no practical limit (just, I think, the theoretical number of "short" Zigbee device IDs per network--tens of thousands). But since you have Hue bulbs or at least other Zigbee bulbs, it may still be a good idea: some of these are known to be "bad" repeaters that may cause problems (e.g., eating/dropping messages) for other Zigbee devices on your network, causing odd problems. So, keeping bulbs off your main network--if you have any other kind of device--may still be a good idea. Either Hue or another Hubitat would work for that, though since Hue is focused on lighting, I generally find that setup easier to manage and integrate (and it's a bit cheaper, plus a tad more reliable in my experience).

1 Like

Sounds like the perfect solution but it's just unreasonable in price - It seems to be a common practice these days in the smart home industry, they lure you in with 'affordable and cheap' products and/or services then they rip you off as soon as they get a chance.

In the US $30 USD a year per hub for the backup service doesn't seem all that unreasonable to me but every situation is different. Also it depends on how many devices you have and the pain it would cause to have to redo everything if something happened or you wanted to migrate to a newer hub to take advantage of whatever new tech is out.

On the other hand I am not a big fan of "{financial} death by a thousand costs"... too many "micro" subscriptions really add up.. you have to choose carefully/wisely...

1 Like

I'd echo @erktrek 's comments, while I am willing to bear the pain of my HE system being down following a potential issue, I have the technical know-how and the patience to deal with that. If it were someone like my parents, without my assistance, I would recommend the subscription to provide that reassurance.

2 Likes

Let me re-phrase that, I'd at least consider it. Something that it essentially half what I would pay for a hub (per year) is a little steep, regardless of the underlying costs involved for a hub.

1 Like

For me being able to purchase a single migration would be nice. It could (should!) even be more expensive than the subscription.

2 Likes

I see where you guys are coming from and yes I do agree too - I just find it a bit frustrating, this type of backup is such an essential feature and yet they charge you an amount of money which would buy you a new hub every 3 years. Not to mention the 'Remote admin' (I use VPN instead) feature which if you choose to pay for that as well then, in my opinion, it becomes totally unfeasible.

What would you do if your car insurance company all of the sudden started charging you a third of your car's value for the annual premium? haha