Two (or more) Hubs questions

📢 Feedback Feature Requests
1

I am thinking through re-purposing my 2nd hub into the Upstairs/Downstairs model. I encountered a series of questions about the 'single use' apps we have: Lutron, Amazon Echo, Dashboards, etc. All of those are only able to function to/from one Hub. There can be multiple Lutron bridges, sure, but can't have two hubs talking to one Lutron bridge. Amazon Echo is similar, one integration per.

The obvious answer is Link to Hub and assign one hub to the role of 'single use coordinator'. Almost 100% of the system's devices would have to be known to that hub, In fact, it's easier to visualize the interconnects if one assumes a third (radio-less) hub is added. All of the devices from the "with-radio hubs" are linked to the third hub where all of the 'single use' integration occurs.

Collapsing the architecture back to two physical hubs is easier once the 'duties' are visualized. Still, one of the two hubs is gonna be busy :frowning:

Naturally, I'm wondering now if I'm late to the game of thinking about this and others have a better design in mind. ??

2

This supports multiple connections.

3

Why would you want to use two hubs? Each one is going to do double duty. Both performing the actions it's assigned for it's devices and then reporting those devices to the other hub. Seems like it would be worse system performance not better.

4

Having one hub deal with the radios, and the other all the applications could be worthy to investigate.
Hard to say if mirroring devices from one hub to the other has more or less overhead than running the radio stacks though.

5

I thought about this when I answered elsewhere: gig ethernet (Link to Hub) and gig quad processors and gigs of mem. I think it indicates the Link to Hub/Hub Link traffic can accept a quite high number of transactions.. I mitigate that statement by thinking there's 'hundreds' of transactions per second and not 'thousands' and certainly not 'millions' - and so mysql's reputation for transactions per sec wouldn't be encountered.

6

It occurs to me, you could be using MariaDB which is reputed to be faster.

7

I would LOVE to have all user apps on my dedicated/non-radio hub... BUT...

It would be a lot easier to do that if we could get more device types able to transfer via Hub Link... No thermostats, for instance, means you have to put the Ecobee integration on whatever hub you want an app to be - no real choice there.

I've also found that in syncing dimmer levels, it does weird things when you try to do the logic on a virtual dimmer repeated from another hub. Maybe the messages come in too fast as it is dimming and it misses some?

Not sure, but my Dimmer Sync app definitely DOES NOT work correctly on virtual dimmers repeated from another hub, and it definitely DOES work correctly when run locally with the dimmer devices...

8

Multiple hub layout design is a very interesting question I'm glad we are discussing this.

In my Upstairs/Downstairs setup I do not have Lutron so am not sure what I would do in that case.

I do have 2 echos - 1 in the kitchen and one in the basement (do NOT want them in the bedroom or upstairs) so they are covered by the main (Downstairs) hub. If I had one upstairs I would just associate it with the upstairs hub right? If I wanted to do a "goodnight" command I would simply have a virtual switch or something that goes through the link.

As far as the dashboard goes - I have so many devices I ended up breaking them up into separate dashboards anyway. Also since I run a separate PI server/web server I could set up a tabbed "shell" page OR single page with a bunch of inline sections that display different dashboards based on the urls - if that makes sense.

In terms of apps the quick and dirty answer is I would probably try and run duplicate apps on each hub and use some sort of virtualized device or maker api for control to have them do what I want.

My recent experience has shown a real benefit to running 2 separate/independent hubs especially if you have a large number of devices.

9

At a high level, what's this app do?

10

Thinking about this further does Echo care about multiple hubitats? I'm guessing not since it can handle multiple different kinds of hubs.

Can the skill handle multiple HEs though?

11

I've tried it and she seems oblivious. :slight_smile:

But in my imaginary design, it wouldn't matter, Amazon Echo skill would be installed on "the coordinator" The Skill would "see" virtuals... not that it would care.

12

I've borrowed a 3rd hub, and if I can it registered, I'll give "the coordinator" a try. If it proves out then folding that role onto one of the two will work too.

13

Pretty simple - it was a way of combining a few RM rules into one app.

  1. Manages ON/OFF of slave dimmer(s) based on ON/OFF status of master dimmer.
  2. When master dimmer level changes, change slave dimmer(s) level.

When using it on a virtual dimmer from another hub, syncing the dimmer level works as expected. But when turning the master OFF the slave ends up getting set to a random dim level as the master is fading OFF.

I get the OFF status on the master, and the app starts turning the slave off, but then I get a setLevel change on the master as it is dimming off and then my app sets the slave dimmer level based on that...

Maybe I could check the ON/OFF status of the master in the dimming event handler too and work around this...

The ON/OFF code is very simple:

def masterONOFFHandler(evt){
	LOGDEBUG("Event Value: " + evt.value)
	if(evt.value == "on"){
		LOGDEBUG("ON Check True")
		def NewLevel = masterDimmer.currentValue("level")
		if(state.modeCheck == false){
			LOGDEBUG("Not in correct 'mode' to continue")
		}
		else {
			slaveDimmer.each{
				LOGDEBUG("Turning ON " + it)
				it.on()
				it.setLevel(NewLevel)
			}
		}
	}
	if(evt.value == "off"){
		LOGDEBUG("OFF Check True")
		// Do not do modeCheck on OFF. Always turn off, otherwise slave dimmers get stuck ON if already on
		// at time of mode change.
		slaveDimmer.each{
			LOGDEBUG("Turning OFF " + it)
			it.off()
		}
	}
}
14

@mike.maxwell

The problem appears to be a custom device driver issue - not an issue with Hub Link or my app. I'll troubleshoot further. I can't replicate the problem if I change the device driver back to the stock one.

Sure would be handy if you guys would share your built-in driver code... lol

And it still doesn't change the comment on wanting the ability to pass a thermostat. :smile:

15

not sure how your custom driver is reporting level, some of how this works is dependent on the actual device type.
In general if you are doing a query for the level after the level command is issued, one needs to wait until the command has completed first...

16

Which makes sense.

I thought the commands were delaying sufficiently between each other - but maybe not. I'll look at it sometime. I just switched back to the in-box driver for now.

17

I've built out the Third Hub as "a coordinator" It has no radio stick. Link to Hub is delivering almost all of the devices to it, from the other two hubs, the ones that have radios. (One is exclusively ZWave, the other began as all Zigbee, but has had 8+ ZWave migrated over to become "upstairs")

The third hub has what I consider to be the "common apps" -- Amazon Echo Skill, Chromecast, Dashboard, and Homebridge. Next on my migration plan is Lutron and ABC. On the custom driver front, ApiXU is moved to "coordinator" where I will be able set virtual switches for the few weather decisions I need.

Because this is a migration, at the moment all three hubs are Linked. My ex-primary hub, now "downstairs" has 194 devices after all the linked added themselves. It points to a Feature Request to be able to better manage, per Link, what devices get exchanged. I'm getting some duplication on the Third hub.

The second Feature Request is to get more state data passed. Dashboard is blank for certain devices, Presence, for example. @mike.maxwell

While I'm in the transition of moving each hub to it's new role, I'm expecting them to be a little messy, but at the end, I will have some problems to solve. One, is due to my choice of zero Zigbee on the "downstairs" hub. I'll need to get a couple of the Zigbee motion sensors Linked between the two Radio Hubs. As I said, being able to limit the devices being Linked on a hub to hub basis would help, I think. So far I am NOT seeing any impact with all this Linking going on.

05%20PM
Screen Shot 2019-01-23 at 11.21.05 PM.png615×562 39.8 KB

1 Like
18

Update.
I've got it all cobbled together. My second hub has more than half the upstairs devices migrated off the first hub. The third hub "Coordinator' has Amazon Echo Skill, Chromecast, Dashboard, ABC, ApiXU and Homebridge so far. I tested Homebridge today.

I began by creating 8 Dashboards on 'Coordinator Hub' and at the same time, migrating devices Hub to Hub. Those of you that use Link to Hub know that as you deleted devices, the matching linked virtual does not get cleaned up, meaning: manually delete the linked devices,

At this time, I'm thinking I'm about a year too early to be doing this experiment. A lot of the Dashboards show missing attributes.. for example: an Aeon Multisensor6 has 7 states from events: Motion, Humidity, Luminance, UV, Temperature, Tamper (acceleration) and Battery. Only Motion and Temperature appear on the linked device. I'm predicting it'll be a year before this item is resolved.

What does work is Motion Sensor, Contact Sensor, Door Locks, Garage Door Openers, Tilt Sensor, Switches, and Dimmers, all independent of radio.

I picked Dashboard as my first test mechanism because it's local to 'Coordinator Hub' and if it works, it bodes well for Alexa and Homebridge. Everything that doesn't work via Dashboard will certainly not work via an integration.

Although I have not completed the migration to "upstairs" every device that is left to do has the same type of device migrated already. I then started on Homebridge. I had already gotten two hubs to work via multiple instances of Homebridge plugin. I created a third instance, and picked all the switches, dimmers and presence sensors. I had to create another Home in the iOS Home App, but it worked right away. Then I spent the usual 40 mins tap tap swipe to get the devices into their 'correct' rooms. When it was time to create a HomeKit Automation for presence, I realized I needed the usual hack.. a hybrid driver to allow HomeKit to set/reset a presence, yet be able to present a presence icon on Dashboard, etc. I haven't driven around to test it but that test will occur naturally tomorrow.

I use Alexa's integration poorly. Mostly it's a chance to "show off" home automation to unsuspecting visitors. Thus, I haven't even tried it out yet. I do not believe I'll be able to have two hubs use one skill so I'm expecting I have to delete everything and rebuild it using 'Coordinator Hub'.

Thus far, I've gotten a first approximation of what I'll get at the end. It's not bad, probably because I try for full automation.

One huge success is Lutron and my collection of Pico's. It's true, multiple Hub connections are possible. The 'Upstairs Hub' has a duplication of 'Downstairs Hub' Lutron Integration, and ABC (stephack's Advanced Button Controller) is working. In effect I've got upstairs Pico's and Downstairs Pico's. and each seems to work.

2 Likes
19

Update for Alexa skill.
On a PC/Mac browser from https://Alexa.amazon.com I disabled the Hubitat skill and agreed that doing so would delete all my smart devices. I then enabled the skill and was taken to Hubitat portal to login and pick the ONE hub. Then did Discover and the devices I had picked showed as new. Which is the really long way to say, I switched Alexa to use 'Coordinator'. :slight_smile:

I have to rebuild my 3 Groups, but a very quick test shows it's working... for me... and that's a huge caveat. If you are one to ask Alexa what's the temperature of some room... if that value does not cross the Link to Hub, of course it won't work.

20

This is the biggest issue on the hub link in my opinion. Mirrored/synced devices don't pass all parameters. They can only pass a small amount of select/pre-programmed parameters - it isn't a true mirror of the device.

Because of that you can't mirror any custom or complex device - most multisensors, thermostats, etc won't work.

For me it made my second hub only useful as a development hub.