That's in beta no talky!
1 Like
Sorry, you're quite correct, I removed the post.
Just builds expectations and if something happens and they decide to pull it then people get pissed off because of something they wouldn't have known about otherwise.
3 Likes
The Developer of HubConnect @SRWhite has 500+ devices in his home and another 100+ in his RV. Last I heard he had 4 hubs, one being the RV, which of course can't be merged into any existing since it has to be mobile. I collaborate with Steve on HubConnect and had already built a 3 Hub system before he created it. It took a few days for the product to develop enough to allow me to abandon HubLink/Link to Hub. As I have said all over these forums, I simply imagined my home as being two homes.. or perhaps apartments makes better sense. Either way, I have an upstairs hub and a downstairs hub. A third hub is for 'outward facing' devices such as Alexa, Google Home, weather, etc. The 3rd hub is the core of the system. All devices are sent to the 3rd hub and distributed outwards from there. Dashboards are created and exist only on the 3rd hub and since I love Apple's HomeKit, all devices are distributed via Homebridge to Apple, which functions as my 'pretty dashboard'.
What Steve found and detailed is that with a architecture like this, each hub 'hears' updates for the entire system. Each hub must process each Event and discard a majority. That's inefficient. Obviously receiving an Event and discarding it can be quite quick, but it's CPU power that is better served elsewhere. For this exact reason, HubConnect's NodeJS proxy Server was created. It functions as a de-duplicator and filter such that only the Events that need to be processed by a specific hub receives them. It is very efficient.
For a system, such as mine, with a hundred+ Z-Devices spread over 2 hubs and another 40+ devices on a central core Hub, all interconnected via a NodeJS proxy server, I have processing power on my Z-Device hubs to spare.
Remember, the primary communications mechanism suggested for HubConnect is using EventSocket, which is just what it sounds like.. a stream of Events being sent by every hub. It was built for Dashboard and is how they get their data. It is 'always on' in the sense that every event is sent to the stream, before it is evaluated.
MakerAPI is very similar EXCEPT for the need to select/subscribe to devices. That's an extra layer that eats processing.. it has to be done somewhere, but the HubConnect method is to offload it. EventSocket sends everything and is as close to 'free' (no load) as such things get. HubConnect must listen to the stream and discard what is not needed.. MakerAPI does the discard before sending. The burden exists on one of the two connected hubs... but only HubConnect offers the feature to completely offload it. 
3 Likes
I have this exact setup. 1-3 are C4 hubs and #4 is my coordinator C5. Itâs worked very well. I originally had LAN automations on my coordinator and it required frequent reboots so thatâs when I purchased another C4 for LAN integrations such as AVRs, Thermostats, UPS, Google Calendar, etc. Given the coordinator listens to all hubs via HC 1.6 it does have less memory and does require a weekly reboot but this setup has worked out well for me for the last 6 months since I bought the LAN hub. Splitting Zwave and Zigbee has been great for the last few years.
I haven't paid much attention to the Node.JS/proxy stuff. Sounds like it could be quite impactful.
sounds interesting .. i have nodejs on a windows server to give out alexa cookie updates, but kinda defeats the purpose to have everything that can be local on the hub(s) and not require you computer up 24x7
I run a raspberry pi for nodejs stuff. It doesn't use much power and it's simple to setup.
1 Like
I'm bordering on 250 devices now, I still don't think I've ever overloaded a single hub.
3 Likes
Funny, somehow my primary, non-radio hub started getting real flaky 48 hours ago, then 18 hours ago, even a power-cycle didn't do anything. I had to perform a soft-reset and restore the backup from the ...same day... -- how does that make any sense? 
so far it worked okay over night, but where's the logic in that? If the problem existed for days, restoring a backup should have been detrimental. Go figure.
Fingers crossed that some better tools are in the works (hints at beta?) which might perform some protective measures on a per-app basis. Freeze misbehaving code, etc. Would go REALLY far to make this platform rock-solid.
What sort of automations do you have? Chromecast? FollowMe? Alexa? With that many devices, you must have hundreds upon hundreds of RM instances. I've got dozens of scenes/groups, and maybe 115 rules across both hubs. That's with semi-complicated rules, without breaking them all out into single-trigger rules.
I'm trying to remove "wait-until" style logic, because that seems to get really messed up when the hubs get sketchy. Still have many triggers per rule though. Stuff like this:
I don't see how you could get away from having this much code as a bare minimum to handle the task though. Perhaps with a ton of individual rules that enable/pause some master rule, but it seems that would end up creating even more overhead.
Memory leaks perhaps? Though you would think a power cycle would fix that.
Chromecast - no
FollowMe - no
Alexa - yes
I don't use RM much at all, looks like I have 11 rules. I tend to use apps much more than RM for everything.
1 Like
Wow, I'm shocked how few automations you have for so many devices. I would have thought most people actually had more than I did, since I had to start from scratch a few months ago.
I wouldnât say I have few automations, just that I donât use RM much.
1 Like
Me neither... but in my mind that's just another reason that HE is such a great platform. Being able to choose how you want to handle your rules either internally or via some 3rd party is awesome. That flexibility, the ease of device management, allowed customizations (apps/drivers), and local processing are all reasons I recommend and am committed to using HE now and into the future.
1 Like
I think a large portion of "power users", myself included, opt for using smaller apps like simple automation and motion lighting instead of rm4 where possible. Rule manager is good for things that can't be done in those, such as conditional statements, but the smaller apps tend to run faster and are less demanding on the hub.
5 Likes
Yup. I do that plus a lot of custom apps. Main reason for me is I find the RM UI too cumbersome.
1 Like
RM can also be less efficient at times because it has to account for a wide variety of use-cases. To @lewis.heidrick's point - simpler more focused apps means lower resource usage/overhead.
1 Like
Hello @SmartHomePrimer,
I have quite a few devices on my hub, for about 4-5 years I've had Vera and later added Alexa. I liked the ability to customize as much as you can with Vera, when Alexa came along it linked fine with my Vera. However, over time it got sooo frustrated because I would FREQUENTLY get the dreaded "the device's hub is not responding". I never knew if it was an Alexa issue or Vera, and really didn't have time to figure it out, and even so it maybe something that I can't fix.
I've had a Hubitat hub for a couple of years, added one device and left it that way until about a week ago. I finally decided to convert everything over to Hubitat because I noticed that the light that I did put on Hubitat, NEVER was unavailable when I used Alexa - but I thought, well there's only one device so it's not as busy as my Vera.
Consequently, it took me all day but I got everything moved over, even some devices that were difficult to connect to Vera.
After all the work of moving to Hubitat, I was thrilled, after about a week I've had NO issues of Alexa communicating with Hubitat. The bottom line - You guys make Alexa look GOOD!!. With the renewed motivation I'm looking forward to really customizing my Hubitat.
Couldn't be happier, at this point!!
Robert
5 Likes
