I suggest looking at this to understand the first two most popular uses...
2 Likes
I'm moving from SmartThings and have a lot of devices and automations. I've read that since HE is executed on the hub itself it can get bogged down if you have a lot of devices and automations and require reboots. One suggestion was to use multiple hubs to split the load. Instead of paying $139 for a 2nd HE hub, I figured $45 for a RPi would be better if it can do it. However when I posed that question I was told that it wouldn't really offload the work, so am wondering how a Raspberry Pi can be useful with HE? What are some use cases? Thanks!
2 Likes
One thing some people do (myself included) is use Node-RED for most of the automations/rules. It is definitely not REQUIRED by any means - as rules in Hubitat work great. Some prefer the graphical/flow based rule layout, easy copy/paste, easy backup of rules, etc in node-red though.
Also, Node-RED can be run on as powerful of hardware as you want (although running it on a RPi is common), thus making CPU/network loading a non-concern. Node-RED can also integrate with more web/lan/wifi based things than hubitat can, which can be convenient in some scenarios.
4 Likes
You can't generalize like that.. 
If all of the "load" is ZWave or Zigbee traffic... adding a rPi to offload anything won't help.
A rPi is simply another computing element and it will help in doing compute based things. A large quantity of people that visit this Community have found that Node-Red helps to offload some, or all, of the Automation. (The things done in RuleMachine or its cousins: Simple, Motion and Basic)
Many here also use Apple's Homekit and that choice needs an always on computer to bridge between. Raspberry Pi running Homebridge is often the first (try it out) use.
When I first got started with Node-Red, I deployed it on a Raspberry Pi.. just to see if it was going to benefit me. I found that it would but chose to move it to an always on computer that was already running Homebridge (a Mac Mini with a primary function of Media Server -- has plenty of power left to run small NodeJS packages.)
5 Likes
If you wish to experiment and determine if YOUR home automation project will benefit.. I suggest using the Raspberry PI image created for this and paste in a sample flow.
Node-Red Import code
[{"id":"8e0a5af7.371978","type":"tab","label":"Flow 1","disabled":false,"info":""},{"id":"8a099872.da1138","type":"hubitat device","z":"8e0a5af7.371978","deviceLabel":"","name":"Motion Sensor","server":"c3a39a36.1bf95","deviceId":"2187","attribute":"motion","sendEvent":true,"x":280,"y":180,"wires":[["7638323b.020d1c"]]},{"id":"7638323b.020d1c","type":"switch","z":"8e0a5af7.371978","d":true,"name":"Open/Closed","property":"payload.value","propertyType":"msg","rules":[{"t":"eq","v":"open","vt":"str"},{"t":"eq","v":"closed","vt":"str"}],"checkall":"true","repair":false,"outputs":2,"x":550,"y":180,"wires":[["e2b47acb.58d428"],["a158e0eb.80168"]]},{"id":"b44dae91.44a8","type":"hubitat command","z":"8e0a5af7.371978","deviceLabel":"","name":"GarageYard Light","server":"365aba51.f34af6","deviceId":"226","command":"on","commandArgs":"","x":1250,"y":167,"wires":[]},{"id":"60e2ff45.cd22f","type":"hubitat command","z":"8e0a5af7.371978","deviceLabel":"","name":"GarageYard Light","server":"365aba51.f34af6","deviceId":"226","command":"off","commandArgs":"","x":1251,"y":240,"wires":[]},{"id":"b155bacc.43ace8","type":"inject","z":"8e0a5af7.371978","name":"","repeat":"","crontab":"","once":false,"onceDelay":"0.7","topic":"","payload":"true","payloadType":"bool","x":110,"y":180,"wires":[["8a099872.da1138"]]},{"id":"367c47d0.605918","type":"comment","z":"8e0a5af7.371978","name":"sample of Motion Lighting","info":"","x":168,"y":121,"wires":},{"id":"e2b47acb.58d428","type":"change","z":"8e0a5af7.371978","name":"Cancelable","rules":[{"t":"delete","p":"payload.value","pt":"msg"},{"t":"set","p":"payload","pt":"msg","to":"stop","tot":"str"}],"action":"","property":"","from":"","to":"","reg":false,"x":752,"y":173,"wires":[["a158e0eb.80168","82fb6b82.aca588"]]},{"id":"a158e0eb.80168","type":"stoptimer-varidelay","z":"8e0a5af7.371978","duration":"1","durationType":"num","units":"Minute","payloadtype":"num","payloadval":"0","name":"","reporting":"none","persist":false,"x":900,"y":253,"wires":[["60e2ff45.cd22f"],,]},{"id":"82fb6b82.aca588","type":"time-range-switch","z":"8e0a5af7.371978","name":"Sunset-Sunrise","lat":"33.596842","lon":"-117.188050","startTime":"sunset","endTime":"sunrise","startOffset":0,"endOffset":0,"x":942,"y":173,"wires":[["b44dae91.44a8"],]},{"id":"c3a39a36.1bf95","type":"hubitat config","name":"MyHubitat","usetls":false,"host":"192.168.7.64","port":"80","appId":"780","nodeRedServer":"http://192.168.7.129:1880","webhookPath":"/hubitat/webhook","autoRefresh":true,"useWebsocket":false,"colorEnabled":false,"color":"#000000"},{"id":"365aba51.f34af6","type":"hubitat config","name":"SixthHubitat","usetls":false,"host":"192.168.7.62","port":"80","appId":"3","nodeRedServer":"http://192.168.7.129:1880","webhookPath":"/hubitat/webhook6","autoRefresh":true,"useWebsocket":false}]
2 Likes
Hi guys,
I found this post that is, essentially, what the Companion is about:
I've been really, really busy and I could't check it out, but it seems to be the thing!
1 Like
Most people can get by with one Hubitat hub for their z-wave, zigbee and LAN based device connections as well as automation logic. Thatās what it was designed for, after all.
For edge cases like @csteele, multiple hubs and other always-on servers have their uses as well 
.
But unless you have some idea that you have a specific need ahead of time, personally I wouldnāt recommend starting out with more than one Hubitat hub just because youāre transitioning from ST.
2 Likes
Even though you are absolutely correct in that a single HE hub is generally all you need I would never consider deploying an HE system for my residential clients without some sort of "companion server" usually running Node-RED, Homebridge and (maybe) Wireguard..
I've done this now on several projects with one dating back to last August. While not super long term yet it has demonstrated it's worth to me in terms of remote support, maintenance etc.
Also I think reducing the number of apps as much as possible on the HE hub(s) really helps with resource issues - though with each hub update things seem to get better and better.
1 Like
I'm using a Pi to run Node-RED for motion lighting because I found that performance using HE sucks (often a second or more to trigger) whereas using the Pi it's almost instantaneous. This is possibly because I do a little checking of things before I switch the light on (like check it's evening/night mode, or if a "light on during the day" switch is on, etc) but even without these elements it was so slow on HE. Now I'm really happy with the performance using the Pi but it is another separate system to maintain which can be a bit of a drag. I think a strong enough hub which could run other tools like Node-RED along with the core zigbee/z-wave radios and the main rule system and a web server would be optimal.
I do like Node-RED because it's a graphical way to model a flow so is quite cool, and you can copy paste then edit etc. Plus it means you are at least in some way 'protected' in that you could. drive a different hub in the future if you decide to switch supplier without having to redo all your rules. But frankly it's got quite a learning curve and I actually really like Rule Machine. It's so incredibly powerful and now I know it well I find it very easy to use.
Last use for the Pi is that I ended up developing a completely custom dashboard system which runs on Apache Web server on the Pi and is awesome for displaying exactly what I want but synchronised completely with HE using MakerAPI and the eventsocket.
I've posted about these topics over the last few months in case you'd like to read more.
3 Likes
Agree...
I believe that the vast majority of Hubitat purchasers need only one hub, and zero 'companion' CPUs. The second biggest pool of purchasers have a 'companion device' in the form of a Hue bridge or a Lutron SmartBridge PRO.
To me, once you crack open the 'companion' solution, the sky is the limit. I'm very happy to have a quad core CPU in the hub, would I reject an 8 core? No. Two hubs is currently the only way I can get 8 cores running Hubitat. I do believe it's harder to manage a collection of solutions, no argument from me. But I'm not daunted by that and perhaps even excited to do the integration. It's the smallest pool of Hubitat purchasers, by far, but isn't insignificant either, I believe. 
3 Likes
I think it's a trade-off some things are more complex (setup/config/hw maintenance obviously) but others are subjectively easier... Rule creation/management for example. While I recognize the ever increasing power and flexibility of the RM suite of apps for me the NR flows/sequences are more approachable and manageable. Plus with hardware control I can get as sophisticated as I want without worrying (too much!) about over-stressing the HE hubs.
I see NR and HE as a fantastic and reliable combination. It would be painful from a cost/capability/support standpoint to do the projects I do without having both together. Again this is purely based on my personal experience and what I am willing to support.
1 Like
I'll add to that the power of function nodes which allow for maths functionality that isn't (currently - but we can hope) present in RM.
1 Like
A rpi can also serve as a "companion" to your HE hub(s). I use mine primarily to provide additional features in storage and visualisation of time-based metrics (influxdb + grafana) and to host my Conbee2 stick for Hue dimmers and Ikea switches. I also plan to use one for setting up a vpn and other admin type stuff, e.g. managing backups of HE, influx, etc.
2 Likes
Thatās the idea behind ācompanionā! To add functionalities to HE.
Me too - VPN and a backup manager. And I do plan to use a mail client to send the backups to the cloud (use gmail as one).
And with Docker images/containers itās possible to add such functionalities with relative ease, isolating each one from the others, avoiding messing up things between functionalities.
Iām planning to use WebCORE & NodeRED to boost the automation routines and I believe that with Docker it will be great!
3 Likes
I LOVED the WebCoRE interface when I was with SmartThings and then for a brief time HE. I even ran my own WC server so I could be independent of the cloud. Unfortunately both HE and the WC port were having growing pains and after several hard hub lockups had to stop using WC. I know this has changed and things are working great (still lurk on WC threads) but am still concerned about resource usage on the HE hubs. Note: not just WC but with everything app related custom or otherwise.
NR has been fantastic for my use-case. I have the flexibility to add more systems as needed. I can switch things around and with minimal tweaks keep my existing "rules". In terms of the interface - it looks really complicated when you see a particular sequence but in reality it is incredibly simple. The whole visual flow thing really works well for me. Extra nicety is it's opensource and completely platform independent.
On HE I've been able to reduce my app count to 3 or 4 apps - usually Maker, Groups & Scenes, Homebridge v2 etc. I get consistent runtime "busy" stats of .02% (devices) / .03% (apps) over 8 days/16 hours on my C-7 with 64+ ZW+ devices and .01%/.02% for my C-5 with 90+ Zigbee & Lutron devices over the same period. Those seem like good numbers in terms of hub resource utilization and maybe highlights the benefits of offloading.
1 Like
If I get a 2nd HE hub and use Hub Mesh on all my devices would that split CPU usage?
It depends, of course
If you have a hub that is I/O bound (the Z-Radios are having a hard time keeping the queues empty of messages) and you move all the Automation to another hub, then I would not say you have split CPU usage.
The first hub doesn't have a CPU burden because Events are smaller and more easily managed than the traffic on the Radios that create an Event. Between the low speed and the Acks and (potentially) retries, the Radios carry a lot of the burden.
Events then, transferred over a LAN/Ethernet connection at 100MBit are tiny and rapidly sent/received by connected hubs. The 2nd hub gets an Event and just like with the first hub, there's not much to processing it into the internal DB.
Then comes the actual burden on the CPU.. calculating any result needed by Automation Rules. Often those result in more Z-Radio traffic.. which must be sent over the LAN, in a tiny amount of time, to slam into the backend of the Z-Radio's queue.
It's a good mechanism for balancing the total load, but the load is usually dominated by I/O to/from the Z-Radios more than CPU.
If all you desire to do is offload the CPU, then you can consider an Instance of Node-Red. The Hubitat hub would be more or less dedicated to Z-Radio while Node-Red does all the Automation. It's difficult to understand your goals from a Single line (20 word) question, but I hope I've made the issues clearer.
All of the above is why I have two Z-Radio devices that split that portion of the load and then a 3rd hub to handle the CPU for both.
2 Likes
I have a detached garage 175' or so from the main house with a small barn roughly half way in between (closer to garage though). I am not able to get Z-Wave out to either of them (probably due to hops) even with Z-Wave Plus devices. I am able to Zigbee out that far and have a few Zigbee devices in use out there. I have a few orphaned Z-Wave devices there too that I would like to be able to use (fan controller).
I was going to put a 2nd HE hub in the garage where it can control the Zigbee and Z-Wave devices in the garage and barn. The garage has gigabit Ethernet and WiFi access while the barn only has WiFi. I guess I'm just not sure how Hub Mesh is implemented. Does it share resources and therefore reduce overhead, or is everything copied to both and therefore overhead is actually increased? Devices in the house will control some of the devices in the garage and barn. Does it matter which hub I use to create the automations? If I create some automations on one hub and some on another is that actually where the automation is run or how does that work with hub mesh? Thanks!
So in general with a multi-hub configuration by location it's a good idea to keep most of your rules local to the hub that controls the devices your rules affect. Doing this should decrease both hubs overhead and protect against crashes - if one hub goes offline the other will continue to work. For rules where you need to share devices either hub will do but probably the main hub is what you want. I don't really recommend sharing all your devices if you don't have to. Less complexity the better.
Disclosure: I am using Node-RED for my rules and control of my 2 hubs so have no need for hub localized rules or hardly any apps at all. Before NR I had 2 C-4s by location (and a C-5 for cloud stuff) and definitely used local rules on each hub. Back then there were much worse overhead issues due to firmware growing pains with some hubs locking up almost every couple of days or so. Splitting the hubs did the trick while HE got the fw sorted out.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
