Raspberry PI companion for HE

You can setup a public repository and everyone can be a collaborator on it to contribute containers.

2 Likes

@dman2306, it seems you nailed it!

I'll begin to read more about Docker. I'll see if I can create a basic OS image with Docker preloaded to start.

Many thanks for the suggestion!

Just to keep everyone up to date: I did build a basic Raspbian configuration with Docker installed.

Now I'm preparing the first image. I did choose the local WebCoRE server ... not trivial, but challenging!

Next: a backup service, with the option of storing the backup locally or sending it attached in a e-mail.

Keep tuned!

4 Likes

Any update on this? Also what is the benefit of adding/using a Raspberry Pi with HE?

These questions always puzzle me. If you don't know what you would use it for, why are you interested in it/if there is progress? Sounds like a solution looking for a problem in that case?

That said, there are some ideas on what a possible solution would do in this thread.

EDIT: And see @csteele much more useful response below. :slight_smile:

3 Likes

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.. :smiley:

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

:point_up:

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 :slightly_smiling_face:.

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. :slight_smile:

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