I have about 300+ devices split across three separate hubitat hubs. I then have three hubconnect-homebridge server interfaces running on my coordinator hub, and then three docker instances on my server running homebridge.
This works quite well, until I have to restart docker the server... the last time that happened the hubitat coordinator hub became unusable for about an hour while homebridge restarted and got everything up and running again. couldn’t turn off the lights for bedtime... WAF was low.
Thanks This got me going. I think I have it working on a basic level.
Can you tell me where I can find instruction on how to understand, write and/or use "Custom Drivers" that might also jump start my understanding of these.
@storageanarchy I'm not trying to argue... anything at all actually Just making observations that even if they don't help or apply to you specifically, will help someone new to this line of thinking... this week, this month or even next year.
I think it's much more common now to have a home with 2 or more Hubitat Hubs.. this year and HubConnect has made the difference. At the same time, I doubt anyone buys their first HE thinking "I'll need to buy several more" I think that's something we see via wisdom, (intersection of Knowledge and Experience) Another Hub is not a big cost when you've already decided that Hubitat is the way to go, finding one of the known advantages to multiHub deployment to be the tipping point..
When @dan.t completed his Homebridge enhancements, I also added multiple Homebridge Hubs to my config, at one time running 3 of them from the single HubConnect Server Hub. Each received a portion of the traffic... into three instances running on a Mac Mini. I did it for two reasons... 1) to assist Dan with testing his marvelous work, and 2) because I wanted to know how to get three HomeKit appliances connected. The Apple side of the puzzle.
I myself would personally like to thank You and @srwhite for the work you've done with HubConnect. I would thank @dan.t but I don't use homebridge, although i'm sure its still warranted.
Because of this app allowing possibility's for more hubs, thus driving more hub sales the actual price of the hubs just since I've started Hubitat in March has decreased 25% (sadly buying my 3 before this) making them almost as cheap as a single Lutron device. Thereby making new entries to this ecosystem very appealing to users of competitive platforms.
In no way would I ever return to a cloud functioning platform, to me that's the Webster's dictionary definition of insanity. In fact, my ambitious goal is to eliminate all cloud devices, which I started today by ordering a Zen thermostat to sideline the garbage Ecobee platform.
Let me know how you like that thermostat. Only thing missing is the ability to monitor humidity at the thermostat. My ecobee 4 has been compared to a calibrated humidity sensor and it’s dead on accurate. With a large saltwater aquarium in my living room I need good humidity monitoring.
Will do, I have 3 more Hampton Bay Fan Controllers to do first. I actually adjust my ecobee 4's temperature setpoint by humidity level automatically with rule machine, but I don't use the humidity reading of the actual ecobee at all in the rule (mine the humidity reading there is inconsistent all over the place). I use the several zooz 4-1 motion sensors humidity readings throughout the house. When the humidity of either sensors rises above the limit I set for each room they are in. It adjust the temp set point down 1 degree. When the humidity is back where I like it, it raises the set point 1 degree.
I'm using HubConnect in http mode, if I change it to websockets, do i have to re configure everything? I will lose any devices doing this? If the answer is no, how I change it? I have one coordinator, 1 HE hub, 1 ST hub, both HE are using the radios, ST only using cloud integrations.
no, you won't have to reconfigure everything... only one thing and that is the Connection Key on each Hub you change.
I just tried it. My development Hub was using http(oAuth) and I changed it (on Server) to use EventSocket and copied the Key from Server to Hub and it is working fine, still.
I'm not sure if I should be starting a new thread or just adding to this one.
I have been successfully using hubconnect with my smartthings device for a while until maybe a week or so ago. I currently only have 4 devices on smartthings that I want to sync with HE. These are ZXT-120 IR remotes for ACs, so it works as thermostats. These are the last items I'm trying to transition over to HE but there are no working drivers yet.
The syncing between the two hubs have been working pretty well for at least a month, but as I said earlier a week or so ago, it just stopped. I've tried rebooting both hubs, but no help. When I go to the device in HE and click the sync button, the device states sync up nicely, it just doesn't work automatically in real time.
In the logs I see that pings are received from smartthings. Temperatures are also sending, but only occasionally will "thermostat modes" that display the cool, heat, off states are sent. I don't know if the thermostat modes were always sent in the past because I never looked at the hubconnect logs when it was working.
I would check the SmartThings forum. I think I read that there was an issue with a recent firmware release that they were trying to fix.
From the SmartThings forum "We are going to release a hotfix on Tuesday, September 10th for SmartThings Hub 2015 (v2) and 2018 (v3). Firmware version 27.8 will include improvements for some LAN icommunication issues and connectivity fixes for multi-endpoint devices."
I don't think my ST hub received the firmware. maybe it did? Firmware version is showing as 000.027.00008.
Was 27.8 supposed to possibly fix this problem or was it 27.8 that started the problem? If it was pushed on 9/10, the time line matches with when things were going south for me.
I thought it was supposed to fix it. I only use ST for updating firmware, so no experience with your situation.They had posted a work around if you can find that and try it.
Paging @csteele and @srwhite...
Trying to help another user, any possibility to pass digital or physical events to client hubitat? right now it comes through as "on" or "off", but on server hub the additional attribute is present-digital or physical.
I suspect it's not possible with today's mechanism. Physical vs Digital is, I imagine, because I sure don't know, a function of where the event came from... if a driver injects the event, it's physical, if not, it's digital.
The flow of a physical event on one hub instantly becomes digital on another because the only driver in the path is on the 'real/physical' hub. This is at least partially a phenomenon of the EventSocket. The 'real/physical' hub outputs the events into the Event Socket and it no longer carries the physical flag. The receiving Hub + HubConnect never know how it was created, I suspect. HubConnect is pretty agnostic about events. The arriving event is injected into the receiving hub unmolested.
I was afraid of that. I'm the "other user" Rxich was referring to. Not a big deal for me. I only have one switch where I'd like to use this, and I can just put the RM rule on the hub that owns that switch.
But how about logging? Maybe something in my setup isn't quite right, but I'm not getting anything in the logs on the server when linked devices from the client activate. If actions are initiated on the server, then I get logs (switch on/off), and rules on the server work fine for things like switches on the client changing state. But there is nothing in the server logs when a client switch or motion sensor changes state. I guess I can see making this optional, but I don't see any way to turn it on.
In HubConnect's Server App, there's HubConnect Utilites in the lower half of the main page. On the utilities page is an option to turn on debugs on all connected hubs. It does not automatically turn off.
Just making observations that even if they don't help or apply to you specifically, will help someone new to this line of thinking... this week, this month or even next year. 
I think that's something we see via wisdom, (intersection of Knowledge and Experience) Another Hub is not a big cost when you've already decided that Hubitat is the way to go, finding one of the known advantages to multiHub deployment to be the tipping point..
