I am a happy user of Node-RED (NR) and Hubitat (HE). I have an RPi running Linux and Node-RED, HomeBridge and WireGuard. System works great, keeps overhead on my HE hubs on the low side so naturally I have to start messing with things. I have also been playing around with Home Assistant (HA).
I prefer HE over HA when it comes to device handling BUT HA has some very good capabilities including great addons, integrations and a super flexible dashboard.
The interesting thing is I can install and manage most of my existing companion server setup from within HA itself - Node-RED, WireGuard, Mosquitto (MQTT Broker). HA has it's own Apple Home "bridge" so Homebridge is not necessary. There is also two excellent HA->HE & HE->HE bridge apps available for HE but I usually go direct to NR using the HE Nodes.
The downsides are complexity of the setup, adding Yet Another Layer and HA itself can get mind bending with the YAML config and possible breaking changes after an update. Since a lot of the complexity revolves around the devices themselves and certain behaviors offloading stuff to HE & NR reduces (not eliminates) the need to go digging into complex configuration files.
I just set up a server and am testing the Ring integration with HA/NR & HE. So far working great.
Using HA as an App Manager is compelling. It's a slightly more controlled environment than straight Linux but still flexible enough that you can get to the "guts" if necessary.
Currently am playing around with moving my NR Homebridge Ring logic (Doorbell, Floodlight Motion lighting) over to HA / NR to see how responsive it is in that setup.
I had looked at HA way back when I was still on Wink and wanted the Apple Home link. At that time I decided to go with Homebridge (had looked at HOOBS but it kept crashing my network). Then Wink went away and I discovered HE and later Node-RED. I found that HA-HomeKit was good, but quite often the devices would get out of sync or not respond. Not sure if it was Wink or HA, but I did not have that problem with Homebridge.
I use the Ring plug-in with Homebridge. Works great with Apple Home and since I only use the motion activity in the Ring Doorbell to trigger lights in HE. I use a virtual switch in HE, expose it to Homebridge/Home and the ONLY automation that I have in Apple Home is to flip the switch when motion is detected. NR triggers the lights to turn on/off. Haven't seen any delays with this.
One of the reasons I went with the Homebrdige image and used HB-config to install NR.
I use the Ring Plugin in Homebridge as well. In NR I am using the slightly wonky but serviceable "node-red-contrib-homebridge-automation" which can receive events directly from Homebridge devices so no virtual switches needed. Ring->HB->NR->HE
I like Homebridge a lot but there seems to be more available for HA.
I tried this but there was an issue with my setup. I have 2 instances of Homebridge running (one is for testing) and the plug-in would "combine" devices from both instances into one. Went back and forth with the developer and we finally came to the conclusion that it would not work for what I was trying to do.
Yep same happened to me so I ditched my test Homebridge setup. I think you could have 2 instances of HA both connected to the Ring.. I'll have to test this.
To report back.. it is as expected. This is definitely NOT for the casual tech person. The issues I have are mostly HA related - where and how to find and edit config files etc. etc. Also the UI is a bit mind-numbing when trying to locate things. You think HE has a UI issue?
Having said that was able to resolve most of my issues (still working on the NR context store) and use the Ring integration.. Below is an example of my 2 floodlights, the HA nodes can handle multiple entities per node which is kind of cool.
Note: Yes Ring can do this built in BUT if I shut off those features in the Ring app and use NR I have more control over how long the lights stay on etc. Very cool. (note: same using Homebridge nodes too)
The next step is incorporating HE alarm when the doorbell is pushed.. Like with the floodlights, have been doing this using HomeBridge and NR.
edit: And here it is... works pretty much the same as the old sequence.. green box is the Aeotec Siren device in HE.
For my use-case this is very compelling. My current plan is to incorporate it into my home system replacing my current companion server and see how it works over time. One of the nice things about NR is the ability to easily import/export sequences/flows etc so this is a relatively trivial task.
Pros:
Acts as a "system manager" easily installing / maintaining addons like Node-RED, WireGuard, Mosquitto MQTT Broker and other things.
Provide additional capabilities (integrations) like Ring and other services that are not quite as mature, cause additional overhead or outright missing from HE.
Hardware flexible and upgradable, runs on different platforms.
Expandable via addition of controllers like Sonoff Zigbee USB 3 dongle. This is good for future proofing.
System is relatively easy to backup/restore provided you download backups.
Lots of information available due to popularity.
Active development - this is a pro/con due to breaking updates.
Dashboard is powerful and looks great.
Cons:
Steep learning curve for all but the simplest things, Configurations can be complicated even for the seasoned technical person.
Updates can break things.
Device management a lot more difficult than HE. Indeed HE is my go to for all things Zigbee and Z-Wave and this is not likely to change anytime soon.
No viable Hardware offering - trying to find a preconfigured system from HA is problematic. "Blue" is discontinued, "Yellow" is being ?crowd sourced? - worry about long term support. For now rolling your own seems the best way to go right now either an RPi or Odroid N2.
While there is a lot of information available it tends to become outdated quickly due to the rapid pace of updates. It's easy to get confused and hard to recover.
Community can be rough and unforgiving at times, noticed more than a few frustrated posters. HE forums is the gold standard of course!
So are you saying that any device that is paired directly into Homekit can have it's events seen by NodeRED directly (no virtual device link needed) ? So i could , for example, get temperature notifications out of a sensor that is paired directly into HomeKit? That would be most useful.
Does anyone know of any way to get such 'events' within HomeKit out and available as status or triggers? The various app clients that connect to HomeKit display these status updates in realitime, maybe by accessing the HK DB directly so it is possible but I have yet to see any way of exploiting them in another HA system..
Yes - it's an intermediary. But some devices will not pair with HA that way. and no BlueTooth ones.
Also I have quite a few EVE Thread devices that work really well but will only pair directly to HomeKit. The easier on/off ones I can manage with a virtual switch relay within HomeKit but the ones that have numeric values or even textual values I can't.
I certainly concur with your initial benefit of going with a HA "companion". There is a tremendous amount of additional flexibility and functionality in using NodeRed with HA. No question.
However, in dealing with real world clients and the issues that arise, I find that "manintenance" can eat into the time alloted for any project. Things change, new releases demand changes, client requirements change. I really want less tools (with more functionality), rather than more tools (even with greater functionality).
Please note that this won't stop me from incorporating new tools when I absolutely see no other way of delivering critical functionality other than incorporating a new tool. However, I'd much rather have fewer tools than more tools.
I hear you!! Extra work does not a profitable venture make.
For the companion servers in my case the benefits outweigh the potential issues - excellent rules controller (Node-RED) which takes the load off the hubs, Integration with Apple Home (Homebridge) for the "iFolks", Remote Access (WireGuard) for remote maintenance and updates + other stuff. If you have a good baseline setup that takes into account things like system backups and failover you can minimize the pain.
I have NR Companion Servers (no HA) installed at several clients and of course 3 at my house (one production, one testing, and this new HA experimental one) . One client's system has been running for almost 2 years the others around a year or less. Overall my experience with this type of setup has been excellent so will continue to recommend and install.
Installing HA as the "master control system" and keeping the devices on HE and rules on NR would really seem to simplify things in terms of system management but I need to see it in action over a few months first.
For now I will NOT be incorporating this HA concept anywhere except for my home system as there are too many unknowns.
Wanted to give everyone a simple example that just happened of why this setup could be beneficial but also is problematic for the folks who don't have a technical background or are not interested in tinkering. Apologies on the extra long post.. All my lights/switches are in HE and are being controlled via Node-RED.
In Node-RED I have a subflow I call "Button Taps", a subflow is kind of like a function, it contains your custom sequences and can be deployed like a regular node - very handy. I am using this to control our master bedroom sconces and our master bedroom lighting using 2 picos. I have one pico and my wife has the other. I set up some sequences that allow me to single tap control the sconce on my side of the bed, double tap to control the sconce on my wife's side. My wife's is set to do her sconce with a single tap and mine with a double.. you get the idea. By triple tapping either pico both sconces turn on/off depending on the button pressed. This has been working really well.
above: My original sequence, green nodes are HE devices, the pico is disabled due to it now running in HA/NR
After the most recent HE update, there was a new "double-tap" capability added to the Lutron app. Now picos could fire a double-tap event as necessary. This is a nice feature that unfortunately broke my Button Tap subflow. Turns out that triple or quadruple tapping only fires a double-tap event. There also seems to be a weird issue in detecting the double-tap event in my subflow for some reason - did not look into it but is probably a bug as it is supposed to handle double-tap events.
Nevertheless I needed to do something as PAF (Partner Approval Factor) was dropping fast.. noticed Home Assistant had a Lutron integration so decided to give that a whirl. Was able to pair HA to my Lutron bridge but unfortunately while the switches showed up, the picos as entities did not. That meant I could not use my pico stuff in Node-RED like I needed to. This was a bust... did some searching and found an alternative - a custom integration by "upsert" for the lutron-caseta-pro. Unfortunately we now get to the why HA is not really for non/light-technical people. Had to do some lower level setup - including copying directories, editing HA's dreaded "configuration.yaml", getting erros + a bunch of restarts. Finally got it to work and then imported and tweaked my Node-RED sequences from my main instance. Had to create a simple helper subflow to adjust the output to what my sequence was expecting but no big deal. Also made some minor improvements etc.
above: blue node is an HA "entity", green nodes are HE devices
In summary - was not planning on doing this but sometimes stuff happens and you need to figure out workarounds. Thanks to the additional capabilities of HA was able to keep everything running smoothly. Things are working great so far and the picos are very responsive - very much like they were in HE.
The main trouble with HA has always been figuring out how to do things if they aren't a standard part of the system and if you encounter problems, trying to fix them without causing more issues which then can become a nightmarish quagmire. The learning curve is steep and there is a lot of complexity just underneath the hood.
This is why I usually recommend sticking with straight HE or my favorite - the HE/NR combo.
Thanks for posting. I am currently going the exact same path as you. Former HA user so it's not so bad but sure is consuming most of my time tinkering with it.
Node-red was the biggest learning curve for me but well worth the effort. I am hoping my HE hubs will eventually just a holding place for my ZigBee/z-wave devices.
HE - ZigBee/z-wave devices
Node red - rules
HA - Homebridge/dashboards
Edit : I have wireguard but also Tailscale. There's a Tailscale addon in HA and it's working like a charm.
Each system has it's strengths and weaknesses.. A careful combination of the 3 seems to be very promising and provide lots of flexibility. For my home stuff this is a no-brainer. For my clients I have to make sure it's fairly bullet proof before committing to something like this. At the end of the day I have to support it of course.
Doesn't Tailscale uses WireGuard as a backend? TS looks very interesting, do not want any sort of cloud account though.. prefer everything local not that I think you need it. Will have to play around with that thanks!
So in terms of "tap" issue above the folks at HE are giving us the option of using the old Lutron driver again - available in the next hotfix..
The workaround I outlined though is still a good example of why ancillary services such as Node-RED and Home Assistant used in conjunction with HE can be useful.