Two (or more) Hubs questions

[Cobra]

@DarellCraighead

What about automation - all on one hub? or half on each? I would think managing as much as possible from one would be better

I’m placing pretty much all of mine on one hub with the sticks removed.
Easy to backup and restore on to a new hub if it fails.
No radio problems to drag down the hub
Radio hubs won’t have much in the way of custom apps to cause problems
It also means I have ‘spare’ sticks (2 in the Uk per hub) as I bought all my hubs with sticks (C4) to replace any that fail

One thing to note though, I don’t use many (if any) built in apps, mine are all custom
(Apart from the ‘connection’ apps like chromecast and sonos etc.)

Andy

[csteele]

@DarellCraighead

I would think managing as much as possible from one would be better

That was my architectural choice as well.. time will tell.

Because the linkage is so fast, relative to the radio(s) it's perfectly feasible to send everything to the coordinator and let it perform all the automation. Up to the limitations of Link to Hub, that is.

I've spoken of this in other places, but my Garage Door Opener is the best example. Link to Hub exposes it as ONLY a Contact Sensor to 'coordinator' (think tilt sensor).

Presence for me, since it is created on Homekit / Homebridge, exists primarily on 'coordinator' and thus I either send Presence to the 'floor hub' or I send Garage door open / close to 'coordinator'. The 2nd is not an option so I send presence to the 'floors.'

Dashboard is on 'coordinator' only and thus I'd like to have the ability to open and close my Garage Door. Again, virtual switch to the rescue.

Do not interpret any of this to say: must use three hubs. I imagine two will work just fine. Manual "Load Balancing" between two hubs, so that one is heavy with Apps and light on Radio use, would probably work as well.

The big benefit I've 'seen' is the doubling of the radio bandwidth. The range of responsiveness is tighter now. Two hubs brings all of that and at only 2/3 the expense.

[csteele]

back up in msg 38, I mentioned restrictions with Link to Hub and how I worked around it.

Two (or more) Hubs questions

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 …

and msg 46 I covered the same ground...

Two (or more) Hubs questions

I can tell you what I've done and can point out the restrictions. The split wants to to be imagined as if the property was "two tenants" ( a pair of rental properties.) The Rules are going to work best on the same Hub as the devices. In a few cases, a specific device will need to be on the 'wrong' hub. Example: A stairway between floors with a motion sensor at the top and another at the bottom. The light is controlled by the motion. But a strict "split by floor" design would have one motion an…

In the past couple of weeks I've dropped Link to Hub / Hub Link and am now fully using HubConnect written by @srwhite. It is what I wanted from Link to Hub: sending all the attributes and events, It's extensible and naturally I'm not seeing any issues with it or I wouldn't be mentioning it here.

It installs, not surprisingly, like Link to Hub, in that there are two parts, the "server" end which goes on the 'coordinator':

and then "remote" which installs on each individual hub:

Where you select the devices that will be reflected to the 'coordinator':

AND

The result is a set of devices on the 'coordinator' or 'remote' of the same name but using virtual drivers, rather similar to the Linked drivers.

The installation and setup is fundamentally the same as Link to Hub and Hub Link, not surprisingly. The differences are all in the attributes and events that are reflected.

I am able to put a Garage Door tile on Dashboard and when I click the tile, the garage door opens (or closes.) Rather anti climatic since that's exactly what happens on a single hub. Only if you are using multiple hubs AND you notice missing attributes or events, does the restoration of them seem so impressive

I am now able to send between my three hubs with ease. I can put automations on any hub, but better is that I can interconnect those Apps that live on 'coordinator' with the Rules that could benefit with no workarounds.

I've gotten my Aeon SmartSwitch 6 sending energy, power and voltage along with switch and for my Dome On Off Switch, acceleration. All of these values simply improve Dashboard.

I don't have my SmartThings running any longer, but Steve (@srwhite) does and he's got SmartThings tied into his 'coordinator' Hub also, which means HubConnect replaces "Other Hub" too.

I realize this is of interest to only a tiny few, but I think knowing that the restrictions have melted away might encourage others to consider a multi-hub architecture... even if it's just adding to your own wish list.

[csteele]

An update to my drawing:

{Image updated in message 75 to show SmartThings}

I wanted to have the diagram show that some products and tools work just fine on both hubs and don't benefit from a third hub.... Which comes to a question...

How many people around here are using more than one hub and find Link to Hub restrictions are impacting them? That's the group of people that should explore HubConnect.

[Solved] Zigbee Instability is back!

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.

@srwhite is close to releasing it, he says. There's not a lot of learning curve to it. It works as expected. If there's adequate interest, I'll put together a how-to with screen caps.

[erktrek]

Oh heck yes... I would be very interested in that!!!! Thank you for mentioning it and of course all your work and once again thank you @srwhite...

[csteele]

What devices are you using via Link to Hub that need more attributes (events)?

I just added a handful of additional attributes for the RGB Bulb, which is great and makes it feel more complete, but I'm pretty sure, now that I'm done, I wouldn't have used those attributes in any automation.

Here's how it's defined from within HubConnect, as an example:

"rgbbulb": [driver: "RGB Bulb", selector: "genericRGBs", attr: ["switch", "level", "hue", "saturation", "RGB", "color", "colorMode", "colorTemperature"]],

I looked at my Hank RGBW and can see this list:

Current States
RGB : [255, 162, 23]
color : #ffa217
colorMode : RGB
colorName : Orange
colorTemperature : 2200
hue : 10
level : 1
saturation : 91
switch : off

And then for the Fibaro RGBW LED Strip Controller, I'm seeing:

Current States
colorMode : RGB
colorName : Dark Green
effectName : Fire Place
hue : 0
level : 49
lightEffects : {"1":"Fire Place","2":"Storm","3":"Deep Fade","4":"Lite Fade","5":"Police"}
saturation : 0
switch : on

In other words, all RGBW are not created equal. I picked a combined list of attributes I thought I might be useful in Automation.

You can create your own in HubConnect, in a fill-in-the-blanks style, but I'm interested in what YOU are finding missing. ME, I needed a complete Garage Door Opener.

Steve gave me that on day 1:

"garagedoor": [driver: "Garage Door", selector: "garageDoors", attr: ["door", "contact"]],

[erktrek]

The short answer is nothing yet - right now I only have some virtual switches. I was purposefully holding off in order to get a sense of how to connect things between hubs and also trying to be careful - now I want to incorporate my 3rd hub as the controller. As my rules/apps evolve it will probably increase my need for more attributes events etc. HubConnect sounds more flexible.

I have Nest thermostats, am using certain attributes of the MultiSensor6 like illuminance. I have an osram RGBW light strip, Water sensors, Dome Water Main shutoff, Orbit watering timer, Power reporting of a Zooz outlet, Maybe Apixu, SONOS etc..

[bill.d]

Is it possible for you to share your virtual garage door device code? I've got a different issue than multiple hubs, I'm trying to get a HomeKit garage door into Hubitat. TIA

[jrau272]

for me garage doors and zigbee locks. these are not passed appropriately. I’d like to be able to have my locks on different hubs and manage everything with lock code manager in one place.

[csteele]

@erktrek

Oh heck yes... I would be very interested in that!!!! Thank you for mentioning it and of course all your work and once again thank you @srwhite...

I should be clear....

If I was very generous with my self evaluation I'd say I contributed a maximum of 3% towards this project. Truth be told, I probably slowed it down with all the questions. Developers know that collaboration brings intangible benefits... I'm hoping those 'paid' for my nuisance factor.

[srwhite]

@bill.d

Is it possible for you to share your virtual garage door device code? I've got a different issue than multiple hubs, I'm trying to get a HomeKit garage door into Hubitat. TIA

I'm not sure if that will help in this case. The drivers for HubConnect are really nothing more than stubs with the majority of the functionality in the parent app. Here's an early peek at the GDO device driver code.. Not sure if there is anything there that will help.

/*
 *	Copyright 2019 Steve White
 *
 *	Licensed under the Apache License, Version 2.0 (the "License"); you may not
 *	use this file except in compliance with the License. You may obtain a copy
 *	of the License at:
 *
 *		http://www.apache.org/licenses/LICENSE-2.0
 *
 *	Unless required by applicable law or agreed to in writing, software
 *	distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
 *	WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 *	License for the specific language governing permissions and limitations
 *	under the License.
 *
 *
 */
metadata 
{
	definition(name: "HubConnect Garage Door", namespace: "shackrat", author: "Steve White")
	{
		capability "Sensor"
		capability "Actuator"
		capability "Garage Door Control"
		capability "Contact Sensor"
        
		command "open"
		command "close"
		command "sync"
	}
}


/*
	installed
    
	Doesn't do much other than call initialize().
*/
def installed()
{
	initialize()
}


/*
	updated
    
	Doesn't do much other than call initialize().
*/
def updated()
{
	initialize()
}


/*
	initialize
    
	Doesn't do much other than call refresh().
*/
def initialize()
{
	refresh()
}


/*
	parse
    
	In a virtual world this should never be called.
*/
def parse(String description)
{
	log.trace "Msg: Description is $description"
}


/*
	open
    
	Opens the garage door.
*/
def open()
{
	// The server will update open/close status
	parent.sendDeviceEvent(device.deviceNetworkId, "garagedoor", "open")
}


/*
	close
    
	Closes the garage door.
*/
def close()
{
	// The server will update open/close status
	parent.sendDeviceEvent(device.deviceNetworkId, "garagedoor", "close")
}


/*
	refresh
    
	Refreshes the device by requesting an update from the client hub.
*/
def refresh()
{
	// The server will update on/off status
	parent.sendDeviceEvent(device.deviceNetworkId, "garagedoor", "refresh")
}


/*
	sync
    
	Synchronizes the device details with the parent.
*/
def sync()
{
	// The server will respond with updated status and details
	parent.syncDevice(device.deviceNetworkId, "garagedoor")
}

@jrau272

for me garage doors and zigbee locks. these are not passed appropriately. I’d like to be able to have my locks on different hubs and manage everything with lock code manager in one place.

Locks are fully supported, including adding/deleting codes, setting code length, etc. Lock Code Manager has been tested to work on the HubConnect-linked locks connected to the two models of Z-Wave locks I own. I've got 7 total across two remote hubs. The coordinator hub (no radio sticks) has LCM installed and is where I manage all lock codes. No issues, and even the code reporting works as expected.

Here's what is logged on the coordinator hub (virtual lock) by LCM when I unlock the physical lock via keypad code entry:

app:2222019-03-13 10:34:28.998 pm infouseHandler- usage event:Steve on Lock, Kitchen Door

app:2222019-03-13 10:34:28.996 pm debuguseHandler- device:Lock, Kitchen Door, name:lock, name:unlocked, data:{"1":{"name":"Steve","code":"????"}}

[Linvale]

An update on why you've not had a report on my progress.

I'm going to try and do some stress testing on the present system (single hub) before I take the plunge.

Actually, the present single the system (with about 150 zwave devices) is really working extremely well at present. A few days away without me "tinkering" seems to allow the mesh to settle down.

I have a succeeded in creating basic javascript program that can poll devices and collect time to (apparently) respond. I.e from issuing an on command via the maker API to the response being logged to the websocket. Just need to create a simple interface this next week.

I am thinking of running a series of tests at various times to explore the apparent latency - basic light switches/outlets at first.

I want it to be a non hub driven app (so doesn't impact on hub load other than in reading and seponsing to a simple commands).

Do you think this is a valid approach?

Would you be interested in the results - even before and after splitting hubs?

Any other suggestions on other valid metrics or approaches to assess performance?

Peter

[csteele]

I've thought along similar lines because of watching my Homebridge logs (tail -f ....) and noting that there's a quantity of info that would go well with graphing.

I've said this a different way, but the hub has a max speed that is really about as good as it gets with 2019's available products. When it's working well, 200ms to 250ms occurs reasonably often. (I know this only by having a delay and not just researching the "too long" data, but previous to see what 'normal' might be.) I'd say averaging 300ms is great... and I have a ZWave network. My Zigbee use is small.. tiny.

At the other end is the extraordinary delays. 17+ seconds response is rare and my worst (recorded/documented) was 27 seconds, back in a single Hub architecture.

What I "Feel" has happened with 2 or 3 hubs is to: 1) reduce the occurrence of delay events. In a single Hub case, I saw delays once, usually twice a week.. now it's once a month. 2) reduce the max delay. The hypothesis is of course, that the hub is bogged down doing something else.. who knows what else but it's off doing it, and the queue grows deep. With a smaller load on each hub, the queue depth is reduced, I'm hypothesizing. I haven't seen anything in the 17+ range since splitting. Maybe it's less, since they're not happening as frequently I'm back to being surprised and thus not counting accurately.

I think your data collection could be valuable, thanks.

[Linvale]

I have exactly the same - lightening fast 99% of the time, 1% horridly slow.

No obvious pattern. Hence data collection and analysis. I'll share what I discover if this works out.

Really appreciate your ideas.

[csteele]

Another iteration of the drawing:

And some Feature List...

HubConnect replaces the native HubLink/Link to Hub apps and offers the following enhancements:

• Support for multiple device attributes (i.e switch, power, voltage for a Zigbee Plug).
• Battery status is available for any device that supports it.
• Switches, Dimmers, RGB Bulbs, and Buttons are 2-way devices which can be controlled from
• the master hub as well as the remote hub in which they are connected to.
• When a remote device is controlled from master, status updates (i.e. switch) are sent
• by the remote device to ensure the device actually responded to the command.
• Supports SmartThings including bi-directional devices.
• Hub Health - Each remote hub pings the coordinator every minute. If a hub fail to respond
• for 5 minutes it is declared offline.
• A virtual "hub presence" device is created for every linked remote hub. If the remote
• hub is responding, the status is "present", if it's offline the status is "not present".
• This uses the "HubConnect Beacon Sensor" and is done so rules can be created to notify
• when a hub is not responding.
• Hubs do not need to be on the same LAN. Both the hub and remotes create oAuth endpoints.
• These endpoints can be accessed over the internet.
• Communications between the master and remote hubs can be suspended for maintenance.
• This is useful when rebooting the master hub as it prevents the remotes from logging http
• errors due to the master hub not being available.

[waynespringer79]

Is there any particular order that should be followed when doing "Hub Updates" with mulitple hubs?.....Cordinator hub first/last......both at the same time? Doesn't matter?

[csteele]

It would depend on the update. So far, none of the upgrades I've seen have any direct impact. I've upgraded mine in whimsical order the past 3-4 times. There is a switch on Server to gracefully sever communications.

It certainly wouldn't hurt to use it

[waynespringer79]

That's good to know, I'm only 3 weeks into the switch and already hooked thinking of expanding to more than 1 hub, and thought I'd know this first as I have a bad habit of learning things the hard way..

[cvccole]

I am getting ready to try HubConnect again after spending several days trying to get MQTT working. Main reason is that the first time I installed HubConnect on a factory reset ST Hub and my HE Hub as master. All I could do with my rgb bulbs was turn on & off & dim. I am 99% sure that I followed the steps exactly. Is there certain drivers for the rgb bulbs that this needs to use to pass on color choices to ST? Currently most of mine are using the magichome wifi driver. Which works great on HE. Fingers crossed

[csteele]

I probably could/should go back and read your previous to remind myself of your system, but, I didn't

I'm guessing your RGB bulbs are on ST and you wish to control them from HE.

I have that situation built explicitly for testing and I can say it does work, for me..

I added a Qubino RGBW Controller to ST and have about 2-3 ft of RGBW LED strips attached.

On Hubitat, I have it in a dashboard using a Color Bulb template, and I can control it as I'd expect.