Wait, does that work at all ever? I didn't think the Hubitat skill supported that (yet?).
You keep this up and you just might force me to get another hub...
E.
Don't know, never tried that specific item. I have read here that people do it for status: windows/doors open, etc. What I'm saying is.. it might not work. Luminance from a multisensor is not sent across Link to Hub, but Temperature is. Therefore Alexa, even if she was capable, couldn't find an answer for Luminance.
I agree, which is how I managed to guess: "I'm thinking I'm about a year too early" 
As I said above, I chose to use Dashboard to measure what works. I've since added in Homebridge and Alexa, all of which do generally the same thing. If I can push-a-tile in Dashboard, I'm now confident I can push-a-tile in Homebridge and Alexa and thus: speak-to-push the button.
Maybe I was one of those people. 
I do do that, but via the Other Hub community integration and the SmartThings Alexa skill. If Hubitat can do that now, it's good to know I can stop doing that.
In any case, I certainly understand your point about the "extra" attributes not getting transferred for devices that support more than just a "primary" attribute or two (e.g., motion for a motion sensor). I was just sidetracked. And you're almost making me wish I bought a third hub when it was on sale this weekend.
Just checked.. still on sale at $89.95. $79.95 for the Radio-less one
1 Like
Ooo. If the "second hub" discount is still valid on a third hub, I'm sold.
I found I made a mistake, an oversight. (lack of sight, perhaps? ) For the Multisensor6's Link to Hub has an Omni Sensor selector and if I had just read the words, I'd have known to pick it, instead of picking "motion sensor" selector.
I removed the Multisensor6's and Dome's from Link to Hub, then removed the virtuals from 'Coordinator'. Then back to Link to Hub to add them back under the Omni option. On 'Coordinator' I put them back into the Dashboard and as if by magic, the values were populating. (Took a report cycle for the event to process and deliver an initial value.)
I don't use a Zwave Thermostat, so I don't see the trouble, although it's pretty easy to imagine. I have a WiFi Thermo and I've put it's integration onto 'Coordinator.' I got solar just about a year ago and since, I haven't tinkered with the Thermo trying to save electricity. Solar brought me Comfort, not necessarily savings, although as I get to see the full cycle, I'll probably end up saving 40-50% over the prior two years. That's what is driving ME to not "closely couple" the Thermo with Hubitat. I have automation flipping the Thermo from Heat to Cool then back to Heat twice a year as the seasons change.
I'm in the same boat with my sprinklers. I created a driver for it, but can't think of how to improve what I have. What I have is a cloud solution BUT if it misses a early early morning cloud connection, it will just repeat yesterday's. The cloud has integrated Weather and seasonal/monthly percentages to calculate a day by day water schedule, which the sprinkler controller fetches daily.
It is really any thermostat, not just zwave/zigbee - Ecobee, Nest, etc. But point taken.
It's been nearly a week and I thought I'd give an update.
I've completed the 'conversion' from a single 'production' hub to the triple. Everything is segregated by floor now and all automations are running in the appropriate place. Most are running on the 'Downstairs Hub', a smaller set running on the 'Upstairs Hub', while there are almost no Rules on the 'coordinator'. What is there is for the Thermostat to switch from heat to cool to heat a couple times a year. Lutron is integrated on both and I have to say, that's a nice piece of work.... from back when they had some development time to polish the app. 
Alexa, Homebridge and Chromecast are all active on 'coordinator'. It's fun to have 12 processors working this. I think i've got a Dodecaprocessor.
Splitting Upstairs Downstairs gave the most bang. The dual Zwave mesh, helped. The third hub, in it's current incarnation is limited by Link to Hub. Dashboard, being able to see the whole house as one, is great. Not being able to close the Garage Door from the dashboard, isn't so great.
I have it working well, not perfectly, and that's an amazing thing. I have run multiple hubs for years, all from different vendors and having one System is very much appreciated. I did find one quirk that I'll mention... when I split the devices between Upstairs / Downstairs the stairs themselves injected a problem. There's a motion sensor at the top, looking downstairs, and a motion sensor at the bottom, looking up. Without thinking I moved the top of stairs motion sensor to the Upstairs Hub. The two motion sensors effectively work as one and being OCD about it made it worse. I came to the obvious solution, of course: migrate the top of stairs motion sensor back to the 'Downstairs Hub.'
In other words, don't be literal in splitting devices Upstairs and Downstairs.
2 Likes
I’ve been following your progress on this and am undertaking a similar project, although for different reasons. Mine being issues due to the large Zigbee mesh I have.
I also adopted your upstairs/downstairs model too. That ended up being a good choice as I was able to build a small Z-Wave mesh and put the two chatty power meters on it, keeping that traffic off the main mesh. I connected Hue to both hubs to offload some of the automations.
One thing I did was set up HSM on each hub. This allows me to effectively define two security partitions and alarm them independently. The main drawback to this approach is that there is no way to easily sync HSM states so I’m relying on mode change sync. This approach also meant replicating all of my pushover devices too.
But mode changes being only one way are probably the biggest hurdle as I can not initiate a mode change on the master hub and have it reflected on the spokes. So right now I’m doing all presence based mode changes on the remote (basement) hub right now so they sync the main hub. That’s going to become a bit more complicated when I add a third hub soon.
I get that there are higher dev priorities so someday it would be nice to see mode changes become bidirectional as well as notifications and sirens. But for now splitting things up has had a positive effect for sure.
I should also add that I have not yet made up my mind to consolidate all dashboards on the master, or build them on each hub, with only a small subset of devices linked to the master.
I like the keeping the dashboard hosted on the hub where each device is connected and not remotely linking them unless necessary. But that means using the ugly link tile to change between hub dashboards.
@csteele what are your thoughts based on your experience?
That's what led me to consolidate to the Third Hub all those 'common' apps. Since my "footprint" is significantly smaller than yours, all but one of my devices "mirror" onto the Third Hub ('coordinator') and that's the Garage Door Opener.
Homebridge, Alexa Echo are a set of tools that don't allow multiple hubs. Lutron does, as I've mentioned. Homebridge can, if you're willing to call your floors "Homes" and switch between homes.
"in for a penny, in for a pound" and since I'm mirroring most everything from the Upstairs Hub and the Downstairs Hub, to the Third Hub for Alexa and Homebridge, felt like a Dashboard came for 'free'.
As you're fully aware, it's impossible to 'measure' the impact of 'mirror almost everything' but so far, I have no reason to alter my hypothesis: gig speed between Hubs over the LAN, and 4 core gig processors. It should be able to transfer without detectable impact.
@patrick revealed today that ApiXU has made it to the bad guy list (2nd time it's been mentioned, this time impacting Dashboard) and I have that running on the Third hub. This follows the original wild-■■■-guesswork regarding putting 'risky apps' where the radios aren't impacted.
Thank you for your followup!!!!
My upstairs/downstairs setup is also working great! The goal with this has always been stability and simplicity first then adding features as I go along. The less impact on the "device" hubs the better so now I'm curious about getting a 3rd hub as a controller type setup.
Currently my hub link only flips a couple of virtual switches and a water sensor. Have HM running on the main hub. Don't have pushover but using my old sendmail notification device/node app for texts and email.
It's too bad they got rid of the Nest app or I would consider putting it on a 3rd hub as well instead of the upstairs/downstairs ones.
Also I am using ApiXU but have not experienced issues - unless I have without knowing it.. where did this get reported?
ApiXU gets a large string and then slices and dices the result into individual Attributes. 24x7 Hubitat designers were expecting Attributes to be small strings, not URLs or images. DB design gets tricky in those circumstances when you're expecting "true", "false", "90" and get results 100 times bigger. Choices made about indexes etc. probably fall apart and then performance falls. I'm extrapolating here.. I have not been given any kind of detailed explanation. Just hints and the hints lead me here.
I've given Bangali the code I worked on to make each attribute optional. Because for the most part, we tend to find answers to our weather needs in 10-15 vs 50-60. The code I created was brute force and not elegant, and I'm assuming he's working on the elegant version 
My Third hub doesn't have much to do. It's primarily got the task of receiving the flood of events from the other two and distributing that to the subscribers. And, no surprise, the subscribers are all pretty much the same. Dashboard and Homebridge Fundamentally do the same thing... "Rec: SwitchX on" and then either change the color of a tile or spit out a message to the Homebridge server. Alexa.. same.. but different. Message format is probably the entire difference
I have almost no rules, which is a surprise, I had been thinking I'd do more with all these "common apps" but mostly just the annual Rules for the Thermostat.
I guess the 3rd hub has little to do OTHER THAN protect the other two from clogging up
The idea seems really compelling - yes maybe a little overkill but worth it for stability and issue separation. Also I would prefer to keep my internet/cloud apps isolated to just that 3rd hub.
I am really all in on the "keep it local" mantra..
Distributed processing FTW!!!!
Yeah I am only really using it for illuminance triggering nothing else.. maybe temp or weather conditions in the future.
I decided to overcome the limitation in the Garage Door Opener in this Three Hub scenario.
The problem is Link to Hub will only add the Garage Door Opener under the Contacts heading. In other words, it transfers the status of the Garage Door Opener and doesn't allow the Dashboard Tile on the Third Hub to be a button, meaning I cannot open / close the Opener.
Inspired by a driver @ogiewon created, Virtual Illuminance Sensor, which @Cobra modified to become a hybrid presence sensor... I created a hybrid Garage Door driver. It combines three Capabilities:
capability "Garage Door Control"
capability "Sensor"
capability "Switch"
and all three are interlocked and activating any one, activates all of them:
sendEvent(name: "door", value:"closed")
sendEvent(name: "contact", value:"closed")
sendEvent(name: "switch", value:"off")
Then I created, on the Third Hub, a Virtual device and initially picked the builtin Virtual Garage Door Controller. I then changed to use my hybrid driver. Now, I was able to add this to Link to Hub as a Switch to send it to the Downstairs Hub (where the real Garage Door Opener is Joined.) A simple Rule tracks the Switch setting and causes the real device to open or close.
Then in Dashboard, (which exists only on the Third Hub) I was able to add the Virtual Device as a Tile using the garage-control template. Now it Looks Like the tile I had there, but actually works.
I felt I had to do this because I looked at the Dashboard the day before and saw the Garage Door is Open, yet pushing the tile does nothing.. natively it's a Contact so of course it isn't two way. I had to go into the Downstairs Hub's device page and push the button there. (So much work, yea, I know.. spend a hour to save myself 20 seconds.)
The builtin Virtual Garage Door driver mimics the physical garage door by going through the phases.. closed, opening, open, closing, closed. My hybrid driver isn't doing that because it's just a mimic, not real, but it's on my wish list
3 Likes
@mike.maxwell any update on how having a separate HE for hue is working out? Any definitive advantages/disadvantages?
It's not just hue over there, it'a all my zigbee bulbs.
So far I have the following (all the groups have zigbee group messaging enabled)
First Floor (the bulb hub is located here)
Living room:
4x LEDVANCE (sylvania) BR30 RGBW and 1 OSRAM LIGHTIFY BR RGBW in a group
2x Philips LST002 (hue RGBW strips) in a group
2x Philips LLC010 (hue Living colors) in a group
Second floor
Office 1:
1x Philips LCT001 (hue lux)
1x IKEA of Sweden TRADFRI bulb E12 W op/ch 400lm (candelabra bulb)
Office 2:
2x Philips LLC011 (hue bloom)
There's one final group that includes all of the above bulbs and is only used to turn off all the lights
That's it, no repeaters so far
I've lost control of the lux in the office once or twice, it's come back on its own, so I could probably use a repeater near this room at some point, I'm specifically avoiding adding one right now as I just want all these bulbs to play together for the time being and see how well they do.
If all these bulbs were on my main hub with all the zigbee sensors, and the few zigbee actuators I have it would have been a disaster, i know this as this was the case a year ago, with half that many bulbs...
I've not had any issues with group messaging, and other than the office, no control issues.
There are no automations on this hub, just the devices, the group app and a custom hub sync app I've been poking at in my spare time.
I have a lot more bulbs to deploy. just haven't had the time to add much more to the mix.
