“Even with my tendency to tinker, adding yet another system on top of Homebridge seemed like too much to me.” – me, two months ago
Yeah, I said that back in late May (in reference to Scrypted) after getting Homebridge set up and integrated with my HomeSeer home automation system. But here I am, two months later writing about another integration to my system. This time, it’s Node-Red.
NR is “a flow-based programming tool for wiring together hardware devices, APIs and online services in new and interesting ways.” I had read about it on the HomeSeer forums (back when I was re-organizing my home automation setup and switched to Ring from ADT Pulse), and made some notes to look into it later as it seemed like a lot of people were using it to extend and integrate their automations with other systems. Last weekend I had some free time and decided to poke around and tinker with it.
Like Homebridge, Node-Red runs on node.js and since I already had that installed on my HomeSeer Raspberry Pi (which is also running Homebridge) it made sense to just put NR there too (the Pi can handle it!). Installation was easy: after following the instructions for Raspberry Pi I had the UI running and accessible via a browser and then I installed and configured the HomeSeer piece which in addition to adding HS-specific “nodes” to Node-Red, also required setting up a webhook in HomeSeer so the two systems can communicate. Then, after configuring Node-Red with that webhook, I was able to construct a simple automation to control one of my Z-Wave lights:
The left hand portion of that screenshot above is the flow. You basically drag different kinds of “nodes” from the palette into the flow and then drag to connect them. In that test flow, I have two inject nodes that send a message with a “topic” of “control” and a “value” of either 0 (off) or 255 (on) (the middle properties panel). Those nodes send the message to the dining room lamp HomeSeer node which handles the message and turns the light on or off. Next you can see I have a debug node connected to view the message result returned from HomeSeer (the panel on the far right) and may also note the HomeSeer node shows the current status of the device underneath it (the “On” next to the yellow square). I could also have a debug node connected to one of the inject nodes if I wanted to see the message being sent to the HomeSeer node.
That’s a pretty simple flow, and I don’t really need Node-Red automations to turn my lights off and on, I’ve got that handled in HomeSeer events already. But that was a good starting point to learn my way around NR (and it took me a while to actually get that flow built and working). What I really wanted to do was something I wrote about back in my “putting it all together” post:
The one automation from Pulse I could not replicate is turning on all of the inside and outside lights when the burglary alarm is going off. This is because the only Ring alarm states available in the Alexa app for routines are Home, Stay, and Disarmed. There is no status for “Alarming” so I can’t trigger any routines in Alexa or events in HomeSeer based on that. For now … I put in a feature request on the Ring Community.
It’s been a year and half, and despite Amazon owning Ring (so you’d think this would be an easy addition), there’s still no way to trigger an Alexa routine when the alarm is going off. Oddly, this is an option in Homekit! So once I got Homebridge working, I was able to create an automation in the Apple Home app on my iPhone to do this:
But I still prefer to use HomeSeer as my central event repository and controller which is why up until now all my Alexa routines were doing was toggling virtual devices in HomeSeer which then triggered HomeSeer events accordingly. Now back to Node-Red …
NR has a pretty big library of user-contributed nodes and flows, and I found one for Ring. It’s relatively new (good timing on my part, I guess!) but I was able to get it working without much fuss. It helped that it’s based on the ring-client-api which is used by the homebridge-ring module that I’m already running in Homebridge (which, by no coincidence, is why I can see the “alarming” event in HomeKit). Once I had the new node installed and my Ring refresh token configured (copied out of my Homebridge config), I was able to start building flows between Ring and HomeSeer. This was a little more complicated since I was first receiving a message from a Ring node first, then performing logic/manipulation before sending a message along to the HomeSeer node(s). I got to learn some more about NR along the way (change nodes, switch nodes, etc.). I had to use the debug node a lot to examine the message structure coming from Ring and then figure out how to construct the appropriate message to send along to HomeSeer.
First I tackled the basic “alarm mode listener” which indicates if the system is disarmed or armed. In my Alexa routines, I could only trigger binary on/off events, so I had two virtual devices in HomeSeer: one for Armed Home and one for Armed Stay (if both were “off” the alarm was disarmed; when one was on, the system was armed in that mode). This made my events a little more complicated because I had to check the state of both devices. With Node-Red, I could send different values so I created a new virtual device in HomeSeer called Alarm Status and configured it for the three different modes:
Then in my Node-Red flow, I evaluated the “mode” coming from the alarm mode listener node (which has values of either “none” (disarmed), “some” (armed home), or “all” (armed away)) and sent the appropriate value (0, 100, or 200) to the virtual device in HomeSeer. Now I had a single virtual device reflecting the mode of the alarm, which simplified my events since they only had to evaluate the state of a single device.
Now the “alarm status” node, which can indicate if the system is alarming. Similar to the mode flow I basically wanted to turn on a virtual device in HomeSeer when the alarm was triggered so I could then run an HS event to turn on all the inside and outside house lights. I ended up adding two other virtual devices to store the date/time of the alarm event and the sensor that triggered the alarm. Here’s the resulting NR flow:
Two things to note: I had to check the state in the payload message to make sure it was “burglar-alarm” because the alarm status node would also send messages when the status changed similar to the alarm mode listener; I also added in the 2 second delay before turning on the virtual device because the HS event sends a notification to my phone with the tripped sensor name and I wanted to make sure that device had time to be set by NR before the notification was sent. After testing the flow a few times manually (with an inject node) to make sure the HomeSeer side was the way I wanted it, I triggered an actual Ring burglar alarm and confirmed it worked: all of the lights were turned on by HomeSeer and I received the push notification. Perfect!
Finally, I had Alexa routines for the Ring motion and contact sensors which would flip their corresponding virtual devices in HS. This was a pain to set up since I had to create two routines for each device: one to turn it on, another to turn it off. This was a lot easier to set up in Node-Red with the “device listener” node:
The “sensor type” switch node determines if the message is from a motion sensor or contact (door/window) sensor. The linked change node then uses a JSON function to determine if the sensor is faulted (on) or not (off), sets the appropriate value (100 or 0) and sends that control message to the appropriate virtual device in HomeSeer (based on the name of the sensor). I didn’t need to split apart the motion and contact sensors but did so just for clarity in the flow diagram. I don’t do any automations based on my window sensors, but I could easily add those into NR if I wanted to (although I’d also have to create their corresponding virtual devices in HS in order to trigger events).
With the three flows above, I was able to disable all 25 of my Alexa routines. No more tap tap tap tap tapping in the Alexa app on my phone to set up these integrations. And since NR is running locally on my HS server, I’ve eliminated another cloud hop (Amazon) in my automation path. I’ve already noticed this has made the motion sensor virtual devices more “responsive.” With the Alexa routine, I had to use an action of “wait until no motion for 1 minute” before turning off the virtual device in HS. Now, as soon as the Ring sensor reports no motion, it’s reflected in HS almost immediately. It’s also very easy to back up my NR config since it’s all just a big JSON file you can export.
Of course the weak links in this setup are my home internet connection and the reliance on a third-party (community) Node-Red package for the Ring integration. During my initial testing I did run into a problem where my Ring refresh token expired so the Node-Red nodes weren’t connected to Ring and thus no flows would execute. That wasn’t an issue when using Alexa routines since Amazon handled the authentication. The Ring Homebridge module apparently updates the refresh token on its own when it changes, I’m not sure the NR package does the same thing (although I haven’t had the expiration issue again yet, I’m still testing to see if I can replicate it) In the meantime I’ve logged an issue on the Github project. If my internet connection is down, my Ring base station will switch to cellular so alarms will still occur, but Node-Red won’t be able to connect to Ring so again the automations won’t work (but I’d have the same issue with the old Alexa routines). The bigger risk is probably the community package: if Ring changes something in the API and the NR package isn’t updated, I’ll have to switch back to Alexa routines again. For now, though, I’m going to keep tinkering.