Okay, that makes sense when logically assigning rules to hubs. I think I'm going to to create my shared virtual switches on the actual hub connect server and share the switches with the child hubs for RM rules running on those hubs.
That makes sense. I don't use any virtual switches w/google home, but if I did I would probably do it like that too.
Thanks Jason. Curious, do you run RM on the HubConnect hub itself for any use cases?
As I mentioned, I use RM on all of my hubs.
If it is a rule only for LAN/cloud integrations (like pool bleach tank alarm via Hubduino) I would put the rule on my Server hub. (my server hub is probably what you are calling the "HubConnect hub")
If it were something like a Goodnight rule and mainly lights/locks, I would put it on my radio hub.
If the rule uses devices from both hubs, I usually put it on the hub that has the most physical devices used in the rule.
Okay, I didn't realize your HubConnect server and the hub you run cloud services on are actually the same physical hub. I was thinking of breaking these apart to keep the HubConnect server running fast isolated from slow running cloud service apps.
You obviously COULD do that - no technical limitation there. Not sure it is really needed/useful though.
Especially when you fast forward to the next version of HubConnect where you may choose to do the HubConnect proxy/broker/external filtering server (whatever steve is going to call it). I'm fairly sure that is how I'm going to architect mine, once hubconnect 1.7/2.0/version.next comes out.
Roger that. I didn't realize these events were being broadcasted to all hubs regardless if I'm sharing a particular device. I think in my use case I am protecting from bad apps causing slowness, so basically I'm going to have a dedicated hub for CPU hungry apps.
That, of course, depends on how you setup HubConnect. If you use the "socket" connection, all device events for all devices go between the hubs. It can be a great way to do it if you are sharing a LOT/all of devices between hubs.
If you do the HTTP connection method it only sends relevant events, which is a lot less overhead if you are only sharing a smaller number of devices, but doesn't scale as well if you are sharing dozens of devices.
The upcoming proxy server is kind of the best of both, but its negative is that it requires the proxy server to run outside of HE - on a raspberry PI, docker, etc.
I'm using the socket method, it appears to be lightning fast. Personally, the whole point of setting this up was to increase performance and to prevent slow hub periods. I'll take a look at the article. Which method are you using? Any delays when using HTTP connection type?
I currently use socket on all 3 hubs, but I have one hub that only needs to share 2-3 devices so will likely switch it to HTTP instead. HTTP is just as fast.
I'm actually testing an issue right now that seems to kill the hub when using hubconnect via socket method due to a different integration - MQTT - making such a high volume of events that the other hub can't process them fast enough.
If I implement the hubconnect proxy server (when it is released) then I'll probably do all of them that way instead of having some socket/proxy connected and some HTTP connected.
I like the idea of an external proxy processing/filtering the events and then sending only relevant events, as the machines I would run externally are MUCH faster than the hubitat hardware. So it should reduce hub loading overall pretty substantially.
Steve's post here illustrates that nicely:
Okay, sounds good. I also run a node server on a beefy desktop machine. I'll follow suit once the proxy enhancement is released.
Note: I'm not having any slow downs with socket. I'm having slow downs due to poor performing third party apps.
Happy new year!
Here's the Current states for my two Hubs, as seen from Server/'coordinator':
One shows a savings of about 66% the other is 85% savings.
As previously discussed, Event Socket is "free" to the Sending hub. It's part of the platform and you either listen to it or not. Up until recently HubConnect would listen to Event Socket but would send via http. V1.5 added bidirectional Event Socket. The ideas behind HubConnect Server (proxy) existed in Steve's mind before he went Camping last summer. By moving the filtering off the hubs, you gain benefits of both Event Socket and http (oAuth). Hubs send (for "free") all events to the proxy/Server and it does the filtering that http would have done on the Hub.
With http (oAuth) each Hub pays the price of filtering on sending.
With Event Socket each Hub pays the price of filtering on receiving.
With Server (proxy) no Hub pays the price of filtering, since filtering is done on the proxy.
The "cost" of Server (proxy) is setting it up. It needs an always on computer. Mine runs on a Mac Mini along side Homebridge, although initially I ran it on a Raspberry Pi. While not difficult, getting the config.json is subject to all the hurdles any json has for human typists. 
{ "hubs": [ { "name": "Server Hub", "ip": "192.168.7.64", "port": 22000 }, { "name": "ZeeRadioLower", "ip": "192.168.7.66", "port": 22001 }, { "name": "ZeeRadioUpper", "ip": "192.168.7.68", "port": 22002 }, { "name": "ZeeFourth", "ip": "192.168.7.65", "port": 22004 }, { "name": "ZeeFifth", "ip": "192.168.7.63", "port": 22005 } ] }
As I've mentioned elsewhere, I have 5 hubs split into 2 sets. A Production set of 3, and a Development set of 2. All 5 feed into one instance of Server (proxy) and the logs are certainly fun to watch. 
10:13:24 AM Server Hub --> ZeeRadioLower SENDING: [deviceId: 88, displayName: MultiSenZigbT (garage), name: temperature, value: 63.97] 10:13:26 AM ZeeRadioUpper --> Server Hub SENDING: [deviceId: 759, displayName: Multisensor6H (masterBath sink), name: lastUpdate, value: 01-Jan-2020 10:13 AM] 10:13:30 AM ZeeFourth --> ZeeFifth SYSTEM COMMAND: [name: appHealth, value: 1577902411098] 10:13:33 AM ZeeRadioUpper --> Server Hub SENDING: [deviceId: 759, displayName: Multisensor6H (masterBath sink), name: illuminance, value: 308] 10:13:37 AM ZeeRadioLower --> Server Hub SYSTEM COMMAND: [name: appHealth, value: 1577902417397] 10:13:44 AM ZeeRadioUpper --> Server Hub SYSTEM COMMAND: [name: appHealth, value: 1577902419051] 10:13:49 AM ZeeRadioLower --> Server Hub SENDING: [deviceId: 693, displayName: LaundryRoomWasher, name: voltage, value: 123.877] 10:14:21 AM ZeeRadioLower --> Server Hub SENDING: [deviceId: 588, displayName: MultiSensor6I (kitchen), name: motion, value: active] 10:14:25 AM ZeeRadioUpper --> Server Hub SENDING: [deviceId: 749, displayName: MultiSensor6E (upperBath), name: lastUpdate, value: 01-Jan-2020 10:14 AM] 10:14:25 AM ZeeRadioUpper --> Server Hub SENDING: [deviceId: 749, displayName: MultiSensor6E (upperBath), name: temperature, value: 72.0] 10:14:25 AM ZeeRadioUpper --> Server Hub SENDING: [deviceId: 749, displayName: MultiSensor6E (upperBath), name: humidity, value: 44] 10:14:29 AM ZeeRadioLower --> Server Hub SENDING: [deviceId: 693, displayName: LaundryRoomWasher, name: energyDuration, value: 222.58 Days] 10:14:30 AM ZeeFourth --> ZeeFifth SYSTEM COMMAND: [name: appHealth, value: 1577902471135]
I will mention that if he would have just done it through MQTT he wouldn't have had to make custom proxy at all. What he is doing is basically the equivalent of writing a proprietary MQTT broker.... 
A little bit of reinventing the wheel.
Custom Wheels
Popular in the Real World too. 
1 Like
true
When do we think the proxy server will be available for installation? I'm thinking about rebuilding on this architecture so wondering if I should wait.
It will be an evolutionary change. You will be fine with v1.6 and when 1.7 is released you'll just upgrade and without a proxy, it will function the same.
When you launch the Server (proxy) with a valid config.JSON it will open a WS connection to your hubs. But without the connections re-keyed to use it, nothing special happens. Then as you're ready, you can create and paste in the new key, and as if by magic, nothing happens It all just works. No trumpets, no chorus. It's all so pulchritudinous. There's even a new toggle to send the new Key over the old connection. 
Maybe I wasn't supposed to mention that.. aren't teases exclusively @srwhite ?
Stop that. 
2 Likes
HubConnect 1.7 will be out as a beta within the next week which will include the proxy server. 1.6.4 will still remain the recommended release for a short while until the new release gets some soak time.
I'll let that one slide..
+1
+1, beautiful!
