Author: Justin

I like technology. It gets me in trouble with my wife.

Node-RED Basics

Justin

If you’re here, it likely means you are at least aware of both Home Assistant and Node-Red and even if you’re not, this is a good place to learn. I hope to provide enough info in this article to help someone who is new to Node-RED, understand the basics.

If you’d rather get your information directly from the source, nodered.org provides all the information (and more) that I am covering here. I plan to provide examples and other articles to show concepts along with the info, but nodered.org is a great place to start as well.

This info can be found here – nodered.org “Node-RED Concepts”

.

.

What is Node-RED?

Quoted directly from nodered.org –

Node-RED is a programming tool for wiring together hardware devices, APIs and online services in new and interesting ways. It provides a browser-based editor that makes it easy to wire together flows using the wide range of nodes in the palette that can be deployed to its runtime in a single-click.

nodered.org – Working with messages

To further expound on this, Node-RED is a way to visually program and code. Nodes are wired together to form a flow. A message containing a payload is passed from node to node down the flow. These flows form an automation. The flow starts at the beginning, and as the payload travels down the flow, different things happen depending on the node used, this is the automation of the flow.

An example of a Node-RED flow, that turns on a light based on motion events.

.

.

What is a Node-RED node?

Quoted directly from nodered.org –

A Node is the basic building block of a flow.
Nodes are triggered by either receiving a message from the previous node in a flow, or by waiting for some external event, such as an incoming HTTP request, a timer or GPIO hardware change. They process that message, or event, and then may send a message to the next nodes in the flow.

A node can have at most one input port and as many output ports as it requires.

nodered.org – Node-RED Concepts

Nodes can be thought of as a representation of something happening in your smart home. For example, there are “stoptimer” nodes that will trigger a timer based on the incoming message, and stop that timer based on the incoming message. There are nodes that monitor events, be it from a Home Assistant service or a piece of hardware on your network like a motion sensor, that will trigger based on how it was configured. There are call service nodes, that will start, stop or change a service, such as light.turn_on, light.turn_off and light.toggle. These are just a few examples of almost countless types of nodes.

.

.

An overview of the Node-RED workspace.

This is the Node-RED workspace. Along the top, we have different tabs for different flows, or automations. On the left, we have the node palette, and the right we have the sidebar. The deploy button is also up at the very top right.

There are a few different way to access these areas of the workspace.

For the sidebar, it can be accessed by pressing “ctrl+space”, hovering your mouse curser over the edge of the screen, or by selecting it in the top right hamburger menu.

To access the node palette, it’s basically the same process.

There’s one more way to access the node palette and that’s by “ctrl+left” clicking a blank spot on the workspace.

.

.

Inject nodes, debug nodes and debug messages

I think that one of the first things someone should know, is how to use the Inject, and Debug nodes. These can be invaluable when it comes to troubleshooting why something isn’t working.

Start by ctrl+right clicking a blank spot on the workspace, and selecting “inject” –

This will drop an inject node on the workspace. Double click the inject node, which will open the edit screen for that node. Click the “timestamp” drop-down and change it to “string” –

Now, fill in the name, and type something in to the string field. Click done. These can be anything for this example. –

Now, grab a debug node, following the same process as before, but instead of selecting the inject node, select the debug node. Once it drops to the workspace, double click the debug node, and leaving everything else the same, give it a name. This can be anything for this example.

After clicking done, you will be brought back to the workspace. Now, connect the two nodes by clicking the output of the inject node, and dragging to the input of the debug node. You’ll notice the deploy button is now bright red. Click the down arrow on the deploy button, and for now, select “Modified Nodes”.  If the inject and debug nodes are connected, click deploy.

After this is done, click the tab that’s on the left of the inject node, open the sidebar and click the tab to open the debug messages. Now, you can see  the payload in the dubug message, which will be whatever it was you typed into the string field earlier.

Double click the inject node to open the editor, and type something into the Topic field. Then click the tab on the inject node, and you’ll notice the topic you just added does not show the message.

This is because the debug node is configured to only show the msg.payload, and we need to set it to show the entire message. Start by double clicking the debug node, to open the editor. Select the down arrow next to msg, and select “complete msg object”.

Once this is done, click the tab on the inject node, and you’ll now see the complete debug message. Click the arrow to expand the message, and you’ll see both the payload, and the topic.

This is a very basic breakdown of the Inject and Debug nodes, but you now know the basics on how they work.

.

.

A few basic examples of flows.

Persistent Notification Example

A persistent notification are the notifications that show up in the left hand side bar in your Home Assistant Lovelace frontend.

These ‘uns.

Here is the official documentation on creating these – Persistent Notification

Setting these up is pretty straight forward, and we’re going to do it the simplest way possible, using an Inject node, and a call service node. Grab both of these nodes, and connect them as we previously discussed in this article. They will look similar to the below screenshot.

Open the inject node, and basically remove everything from it, then click Done. In the call service node config, set Domain to persistent_notification, set Service to create, and set Data to {“message”:”This is a test notification”}, then click done.

Now when you click the tab on the inject node, and go take a look at your Home Assistant front end, you’ll see the notification bell with a badge, letting you know there’s a waiting notification.

When clicked, you’ll see the test message you put into the call service node.

Tada!

Restart Node-RED example

This is another straight forward example. Start by grabbing an inject node, and a call service node and connect them, like you did in the first example. Open the inject node, remove all the fields and name it Restart, click done. Open the call service node, and set Domain to hassio, set Service to addon_restart, and set Data to {“addon”:”a0d7b954_nodered”}. Click Done.

Now, when the tab on the Restart inject node is click, Node-RED will be restarted.

TV Ambient Lighting, with Node-RED

Justin

I have a Hue LED strip mounted to the back of my 65″ TV, and I like to have it change color, according to input and activity on screen. It’s a pretty straight forward and easy setup, but one that people really enjoy.

Listed below is my setup and config, but I will try to show how to do this in the simplest way possible, in the hopes that it will work with whatever your setup is.

Hardware, and related integrations and addons:

(Amazon links are affiliate links, where I get a small commission of purchased item)

Software

  • Home Assistant
    • Node-RED addon
      • Built in nodes – (Nodes that are included with Node-RED)
        1. function node
        2. event: state (server-state-changed) node
        3. switch node
        4. call service (api-call-service) node

Don’t worry if you do not have this exact configuration, since we’ll be using all generic nodes, this should work with virtually all configurations.

To start, we’re going to need to get the status of the TV. To do that, we’re going to use the Activities from the Harmony Hub and remote. The Harmony Hub integration will automatically pull all the activities you created when you first setup your Harmony Hub. The names of those activities are located in the harmony config file located at the root of the Home Assistant config directory. Using the file manager of your choice (I use the Visual Studio Code addon) navigate to this directory and take note of the activity names. Case is important, so make sure to note them exactly as they are.

Now that we know the activity names, we need to figure out how to filter them and use them to kick off flows. To do that, we’re going to grab an “events: state” node, and configure it like so:

Then we’re going to grab a debug node, and configure like so:

And then we are going to connect the two, open the debug window and then start an activity on your TV remote. You’ll see the debug output on the right. This shows all of the information passed on by the state node

If you drill down to “data.new_state.attributes.current_activity”, you’ll see the name of the current Activity, in this example it is “Google TV”. We now need to take this path, plug it into a switch node, and filter the activities. Start by copying the path by clicking the little > emblem.

This will copy the path to your clipboard.

Next, grab a switch node, and paste the path that you copied into the Property field. Then, in the fields below make sure == is selected and then enter the Activity names. This will filter everything that comes in through “data.new_state.attributes.current_activity” to the corresponding output. Nothing else will get passed through. Now, connect the event state node you created earlier to the switch node, and connect properly labeled debug nodes to each output on the switch node. Don’t forget the PowerOff activity!

Switch node configuration

With them all connected, when you start an activity from your remote, you can hover over the debug output and it will highlight the debug node that it came from. Doing this, you can verify that the switch node is routing the payload correctly.

Now that we know when we press Google TV on the remote, it will route through the Google TV output of the switch (along with all the other activities routing through the correct output), we can start programming the lighting per output.

Grab a “call service” node node, and we’re going to program it to turn on the light when PS5 is selected. I like to Google the RGB code of whatever service it is that I’m working with. For example, I would Google “Netflix logo RGB color” and it will give me the RGB code for Netflix Red. Same with Playstation Blue, etc. With that info, the call service node to turn the light Playstation Blue, would look like this:

Domain is light, service is “turn_on. Click the three dots to open the JSON editor to program the settings for the light. “brightness_pct”: 55 will set the light to 55% brightness. “transition”:1.5 means that the light will reach 55% brightness when turned on in one and a half seconds. “rgb_color”:102, 92, 190 is the RGB color for PlayStation Blue. “entity_id” is the name of the light you want to control. You will need to repeat this until you have all the outputs done. One for TV, one for Nintendo Switch, etc.

Lastly, don’t forget about the PowerOff activity, to turn the lights off when you turn off the TV. It’s the same setup, different service. Grab another “call service node”, and program similar to before, except the only thing you need to worry about is the service, which is now “turn_off, and the entity_id of course. It will look like this:

The completed flow will look like this:

Here is a video showing how it can look. Keep in mind, in the video, I’m using a more advanced version of the flow to change colors based on the currently selected app in my Google TV, but the effect is the same. I may do a part two later to show how to do that. Also, don’t mind the creepy whispering at the end of the video, I was lightly bullying my buddy cause his TV isn’t this awesome.

Finally, here is the code.

Time based automations, with Node-RED

Justin

Time based flows are probably the easiest to do. In this example, you can see that I’m using an inject node set to trigger at 8pm to set my Ecobee thermostat to 73*. The same with setting the alarm, turning lights on and off, etc.

Setting up something to trigger at a specific time is easy. Grab an inject node, and configure it similarly to this:

The payload can stay as a timestamp if you want, I just always change it to what I want it to do, just ’cause. You can see that it is set to repeat at a specific time (10:30pm), everyday of the week. In the first screenshot you can see that the 10:30pm node arms the house if the house isn’t armed, starts the subflow to close the garage if open, the subflow to turn off the front porch light if on, and the subflow to turn off the backyard flood light if on.

For the “Every 30 minutes” inject node, it connects to a time range node that only allows the inject node to work between 11 pm and 4:30am. This will check to be sure all the things I want to happen over night, happen, even if they are somehow missed by the 10:30 trigger. There is a better way to do this, but this is how to do it in it’s most basic form.

Here’s what the every 30 minute inject node looks like:

Here’s how the time frame node looks:

The big green node at the top of the flow is the bigtimer node. It operates sort of like a time range node and an inject node. I have it configured in it’s most basic way. It sends a message at sunset, and another at sunrise, which toggles my exterior light automations. Here’s how that node looks:

These are very basic ways to setup time based automations. In the future I will show how to set everything up in one fluid flow, but this will get you headed in the right direction.

Here’s the code.

Using the “stoptimer” node, in Node-RED

Justin

The stoptimer node has two functions. It refreshes the timer whenever it receives a new message, which is useful for motion automations; and it can start a timer when something happens, and stop the timer if something else happens.

They are very useful in motion lighting automations.

In the flow screenshot above, when the kitchen motion sensor is triggered between sunset and sunrise, and if none of the living area lights are on, the kitchen can bulbs 1 and 3 are turned on at 10% for 25 seconds, and then they are turned off. We’ll get to the turn off loop I’m using later in the post.

In this flow, every time the motion sensor is triggered, a new message is sent down the line. If that message reaches the stoptimer before the 25 second timer has ended, it restarts. This will keep the lights on until 25 seconds after the last triggered motion event. Make sure that the stoptimer duration is not shorter than the refresh duration of your motion sensor. My sensors refresh every 15 seconds, so any timer above 16 seconds will keep the lights on as long as motion is detected.

So, what if you want to stop the timer?

I have automations setup to monitor my outside refrigerator, because my knucklehead kids will leave the door cracked and it will defrost. So I thought I’d put something together to help stop that.

Here’s what that looks like:

In this flow, the top two flows monitors the refrigerator and freezer doors, the bottom two monitors the temps.

For the doors, an “event:state” node is monitoring the door state. When the door is opened, it sends from the top output which starts a stoptimer for 3 minutes. If the door remains open past that three minutes, a notification is sent to Telegram, which alerts my wife and I. If during that 3 minutes, the door is closed, it sends from the bottom output which triggers a “change” node that changes the msg.payload to “STOP”, which then is sent to the stoptimer node, and the timer is stopped and a notification is not sent.

For the temperatures, an “event:state” node is monitoring the temps of the freezer/fridge, which is then sent to a switch node. The switch node determines if the temps are equal-to-or-higher than a certain value (20 degrees for the freezer, 50 for the fridge), and if they are, to pass it on to the stoptimer which starts a 10 minute timer. I’m using 10 minutes, because the temps can temporarily rise past those values when the door is opened, and the timer gives it enough time to stabilize. If it wasn’t there, a notification would get sent almost every time the door was opened. So if the temps rise over the set value for more than 10 minutes, it’s safe to assume something is wrong.

Once the temp drops back down below the set value, the message is sent from the bottom output which triggers another change node, that will stop the timer, which again, cancels any notifications that were going to be sent.

When to use a stoptimer, instead of a delay node?

A delay node is very simple, it literally delays any messages for the duration of time that you set. There’s a few more things it can do, but as far as stopping it like a stoptimer, there is no function for this. So, when should you use a delay node instead of a stoptimer? Well, technically, you can use a stoptimer as a standard delay node if you wanted to, but I like to try to use them for their specific purpose, as it makes looking at a flow easier for me.

Lets look at another of my lighting automations.

Above is an automation used with our dining room light. In our house, the dining room light is one of those lights that just gets left on all the time, for no particular reason. I put this flow together to turn it off if there is no motion in the dining room room for 20 minutes. I have an “events:state” node checking for motion, and passing it on to a “current:state” node when motion is detected. The current state node checks to see if the Dining room light is on, and if it is, it passes the message on to the stoptimer node, which triggers the 20 minute timer. Whenever motion is detected, it sends another message, which restarts the timer, keeping the light on. When no motion is detected for 20 minutes, the light turns off. If a delay node was used here, the light would come on for 20 minutes, turn off, and then immediately come back on if motion is constantly being detected. This means the light will flash every 20 minutes, as long as someone is triggering the motion detector. So it makes sense to use a stoptimer here in the flow.

When you look further down the flow, after the stoptimer node, you see a call service node which turns off the dining room light. This then starts a 1 second delay node, which then sends to a current state node that checks the state of the dining room light. If the light is off, everything stops here. If the light is on, it loops back to the call service node to turn the light off. I started using these turn off loops when I noticed on rare occasions lights wouldn’t turn off or on correctly. Since there is no reason to stop the timer, a delay node can be used here. The delay node is stopped whenever the current state node says the light is off, and it doesn’t loop the message back around to the call service node to turn off the light. I stoptimer node could be used here, and it would work correctly and the flow would operate correctly, but it’s not “needed”. It’s sort of a “best practices” thing; its best practice to use the correct node in a specific situation.

Below are the codes for the flows if you want to mess around with them.

The code for the Kitchen motion lighting flow

The code for the outside refrigerator example. – Please note that I removed the Telegram notification node as it has all of the info to send to my bot, so you’ll need to connect this to your own notification nodes.

The code for the dining room motion automation.

Better notifications with Telegram and Node-RED.

Justin

Previously, I made a post about setting up a Telegram bot with Node-RED and sending notifications using a call service node. This works great for basic notifications, although it doesn’t handle any of the custom formatting that Telegram supports, or the logging that can be kept. To get better notifications, we’ll want to have everything contained within Redbot. This will setup notifications to be completely handled in node-RED, instead of using the call service node to call the “telegram_bot.send_message” service. Doing it this way, removes the need to have anything setup in YAML and allows Redbot to keep logs of everything that happens.

If you set up Redbot as was previously discussed in the first post, you’ll want to go back into the configuration of either the the Telegram sender, or receiver nodes and add a logging location. I created a folder log location in my local config location, path looks like /config/www/logs. You want to add this to the bot configuration inside Redbot and append whatever you want to call the log file.

So now, anything that travels through the Sender and Receiver nodes of the bot, will be logged in that location.

Example of the Redbot logs.

To make an example, we’ll need to grab an inject node, a conversation node, a text node and a link node. You’ll need to configure the conversation node with the bot you configured for the send/receiver nodes, and also a chat or group ID. This ID is for whomever you want to receive the notification. My family is all in one Telegram group with the house bot, so I send to that group ID. If you are only going to receive these notifications, use your chat ID. You’ll also need to configure the text node. With this node you can enter different variations of the message you want to send, and it will randomly send the different versions, giving the bot a sense of personality. Place the inject node in front of the conversation node, and the text node behind the conversation node.

Conversation node example
Text node example.

Now go to whatever tab you have your telegram bot set up in, and grab a link in node

In the configuration call is something descriptive so you know what it is when you link to it. Connect it to the Telegram bot receiver node:

Go back to wherever it was you were setting up the conversation and text nodes, and grab a link out node. Go into the config, and put a check mark next to the name of the link in node you just created.

Now, connect everything. Once connected, if you hover over the link out node, it will show you the tab that it’s connected to.

Now if you press the inject node button, it passes through the conversation and text nodes, and the link node connects it to the telegram bot. Click it a bunch of times and it will send all the different variations randomly.

So, if you want to use this method of notification, you just need to replace the call service nodes, with the conversation and text nodes, as well as a link out node.

Here’s one of my flows where I replaced a call service node after the stoptimer with the conversation and text nodes.

Zooz ZSE40 Z-Wave Plus sensor with Home Assistant and Node-RED

Justin

(Amazon links are affiliate links, where I get a small commission of purchased item)

The Zooz Z-Wave Plus 4-in-1 Sensor ZSE40 has become my go-to and I’ve replaced all of the other motion sensors in my home with them. They are fast, super cheap and can be mounted on the ceiling (which is my preference), corner mounted or mounted on the wall. These things are great. The Smartest House sells them for $20 refurbed on eBay , or you can buy them new at the Smartest House. They are genuinely good, and I highly recommend them.

With all of that said, there is one thing that may throw you for a loop if you’ve never come across it before. The binary sensor for the motion sensor does not register in Home Assistant. For whatever reason, it is not compatible. I almost sent the first one back because of this, until I start doing research and figured it out.

This thing has a lot of sensors. The “binary_sensor.zooz_zse41_4_in_1_sensor_sensor” is the binary motion sensor that does not register with Home Assistant.

It will forever read “off”, so it’s useless to us. I usually rename it “binary_sensor.motion_<room name>_motion_sensor_broken” and then disable it within the Home Assistant device manager.

Will only register “off”.

Make sure to rename and disable.


So, the one we want to use is the “sensor.zooz_zse41_4_in_1_burglar”. Rename to whatever is appropriate for your application of course. With this sensor, “0” is off (no motion), and “8” is on (detected motion).

No motion
Motion

Now that we know this, it’s an easy jump to use it in an automation. I bought this one to use with my backyard flood light and Lanai lights. So let’s put one together, as an example.

Here is my current flow for the backyard. If the slider is opened after dark, the flood light and the Lanai lights come on at 100% for 10 minutes, then the flood lights are turned off and the lanai light are dimmed back to 10%, which they do automatically at sunset.

We’ll build off of this, and have the motion sensor trigger the flood light and set the lanai lights to 100%, to act as security lights when motion is detected.

Grab an events:state node and configure it similarly to this:

If you only want this to trigger at a certain time, grab a time range node and set it up similar to this:

We’ll use two call service nodes, one for the lanai lights, and one for the flood light.

Lanai lights to 100%
Flood light on at 100%

Stick all these nodes together and you have something that looks like this:

This flow will turn the flood light and lanai lights on at 100% while motion is detected. Let’s set it up to turn them off after a set period of time. Grab a stop time and configure it however you want. I’m configuring mine for 30 seconds. I’m going to connect both the on and off output nodes from the motion sensor to the stop timer. Doing it this way, the timer will be immediately triggered when it detects motion, and will restart the the timer anytime motion is detected. When it no longer detects motion, the timer will be reset and the light will go off after the set amount of time.

**Small update at the end of this post regarding this part of the flow**

At this point, I’m going to link the stop timer with the call service nodes I already have configured to turn off these lights, but you may have to create your own if this is a new flow for you, and you’re not building off of an existing flow.

Here’s how the flow looks now:

The reason I created new call service nodes to turn on the lights, is because I want different behavior when motion is detected, on for 30 seconds instead of 10 minutes. Doing it this way is the easiest way of bypassing that 10 minute stop timer. The call service nodes to turn off can be reused because that’s all they do.

I hope this is helpful to anyone who picks up these Zooz 4-in-1 sensors and is having a time figuring them out. It took me a fair bit of research to get them squared away.

Small update. After I wrote this post and spent some time tweaking the flow, I noticed that the 30 second stop timer would override my 10 minute timer, breaking the original flow and making everything operate at 30 seconds. To resolve this, I added a time frame node and set it to 10:30p to 5a. My alarm arms at 10:30p and disarms at 5a, so we wouldn’t be using the slider anyways. Then I thought further, what if it’s the weekend and we’ve turned off the alarm and we’re hanging out in the backyard? So I added a current state node. Now, if it is after 10:30p and the alarm is off, it triggers the top part of the flow, turning everything on for 10 minutes, which should continually refresh the timer and keep the lights on as long as there is motion. Here’s how it looks now.

Controlling a Google Home, with a zigbee button and Node-RED

Justin

(Amazon links are affiliate links, where I get a small commission of purchased item)

Our son has a SmartThings button, and a Google Home in his bedroom. He plays with the GHome and we use it for sleep sounds at night. Anytime after 9pm, the button turns on his lamp at 10% red, and then we yell “Hey Google, play the sound of rain at 70% volume!” The whole point of all this automation stuff is to make our lives easier. So I set off to make his GHome come on with the nightlight.

I had no idea how to do this. I spent many days searching and turning up nothing. So I had to figure it out, and this is how I dood it.

I started by connecting an “events: state node” to a “debug” node. Remember to set the debug node to “complete msg object”

I go into my son’s room and say “Hey Google, play the sound of rain”, and then checking out the output of the debug node. You’ll see something like this:

When the Google Home started playing, it was “idle”, and then the state changed to “playing”. The “topic” shows you the device id, and the “payload” shows you the state. The “msgid” is unique to every message and is what keeps track of an individual message as it travels through nodes. We’re not worried about that in this example, but I wanted to give an explanation on it.

Let’s break down the “playing” message. Hit the arrow next to topic to drill down. This will show the topic, which is the original information, just a little easier to read.

We now need to drill down into data, so hit the arrow next to “data: object“. This shows you the data of the object.

You’ll see old_state, and new state. We’ll review both of these, but lets start with old_state.

Here you see the entity_id “media_player.wyatts_speaker” and that its old_state was “idle” at 2:13pm on 10-15-19. Silly Brits and how they do time 😉 Ignore attributes and context for the time being.

Let’s go ahead and close old_state by clicking the arrow, and drill down “new_state“.

This shows pretty much the same info as old_state, but now shows that it is “playing”. Let’s drill down into attributes.

There’s a lot of info here. Let’s take a break from this for a minute, so we can see exactly what information we need to play the rain sounds on Wyatt’s GHome. To find this out, grab a call service node. Under domain, type “media_player” and in service, type “play_media”, then click out of the field.

Once you type in the Domain and Service, a list of commands will populate below, which are very helpful in figuring this out. In this example we see “entity_id“, “media_content_id” and “media_content_type“. In this case, we need to use all three of these commands, which I figured out from trial and error. A lot of times, and probably most of the time, you will not need all of the commands listed, just a few of them.

So with this information, lets go back to the attributes of the new_state.

I have no idea what app_id is, so I blurred it.. It seems to be the only thing that is unique between devices so I blurred it just in case.

Here we can see the media_content_id that we’re going to need to find and play the media, in this case it’s the sound of rain. We’re going to take this and plug it into the call service node. Go ahead and enter the entity_id that you want this to play on, as well as the content id. The format should be “media_content_id”:”https://xxxxxxxx.com&#8221; . Pay attention to the quotes and semi colon placement, and make sure to type in the open and closed brackets. Click the JSON editor to see if the code is properly formatted.

Here’s how the code looks in the JSON editor:

At this point, we’ve satisfied two of the requirements that are needed to make this happen.

The last part “media_content_type” is an easy one, as it tells us what our options are in the description. For this one, we need to use “music“, so it will look like this; “media_content_type”:”music”. Here’s how it looks in the node config:

Here’s how it looks in the JSON editor:

So now we have a properly configured call service node to play the rain sounds on the GHome. To test it, we’ll connect an inject node.

When the inject tab is clicked, it plays the rain sounds from the GHome. Now, when it starts playing, it’s going to play at what ever volume the Google Home was last used at. Let’s fix that…grab another call service node.

The domain needs to be “media_player“, the service needs to be “volume_set“, the entity_id is whatever device you’re adjusting the volume on and the data needs to be {“volume_level”:0.x}. The volume level is in .1 increments. So 0.7 is 70% volume. 0.2 would be 20%, 1.0 would be 100%, etc.

Now we’ll take this service node and place it after the inject node, but before the other service node.

Now when the tab is pressed, the volume of the GHome is set to 70% and then the rain sounds start to play.

So now we have a working flow, although it is manually triggered. There are many ways to automate this. One way is to use an inject node set to trigger at specific times.

The way that I’m doing it is by button press. Let’s get into it.

We will first need an “events: all” node , and configure it to grab all zigbee events

We will need to know what the hardware address of the switch is, this is called the device_ieee. To figure that out, you need to connect a debug node to the zha_event node and look for the messages when you press the button. Inside the payload will be the device_ieee. Copy that, and paste it into a switch node. Make sure to change the msg property to “msg.payload.event.device_ieee”.

So now we have the zha_event node monitoring all zha_events. Anytime a zigbee device is triggered, it sends a zha_event, with all of it’s information. The switch node then reads the zha_events and filters the specific device_ieee to the output node.

This is what we have now

Now we need to differentiate the different button presses ie; single press, double press, long press, etc. Well, how do we figure that out? We need another debug node, attached to the switch node.

Now when you press the button in different ways, look for the “msg.payload.event.command”. Usually it will be close to the description of the action you performed. In the case of the SmartThings button, the event command for a single press is button_single, a double press is button_double and a hold is button_hold. For your button, just keep pressing it and digging through the debug node output to find out what yours is. Once you figure that out, paste them into a switch node. Make sure to change the msg property to “payload.event.command.” so the switch can grab the individual button presses.

A single button press will come from the top output, a double press will come from the middle and a button hold will come from the bottom output. Place this switch node, behind the last switch node we worked with.

So, if we want the Google Home to play rain sounds with a single button press, we need to connect the two service nodes we worked with earlier, to the top node.

So now we have a working flow. a single button press will turn on the GHome and play rain sounds at 70% volume. Let’s make a double press turn it off. All we need is a call service node configured to turn off the GHome.

Then connect it to the middle output on the switch node.

So now we have a complete, working flow. A single button press will play the rain sounds at 70% volume, and a double press will turn them off.

Sending picture notifications, with Node-RED and Telegram

Justin

(Amazon links are affiliate links, where I get a small commission of purchased item)

I have a SkyBell HD doorbell, and it sends notifications to my wife and I with the SkyBell app when it detects motion or the doorbell button is pressed. It works well enough, but it’s another separate app sending separate notifications. The entire point of automation is to make life easier, so let’s see about getting those notification in Telegram, with the rest of our smart home notifications. Here’s how the native app looks:

Here’s how the notification looks within Telegram:

There’s a few different parts to this flow. We’re going to send a notification for both motion, and button press. Once motion or button press is detected, a call service node takes a snapshot of the camera, stores it locally on your Home Assistant hub, waits one second to allow it to save properly, and then another call service node sends it as a notification.

Let’s do eet.

First part is easy, it’s two state nodes monitoring the Skybell, one for the button press, one for the motion.

Here’s how the configurations looks for the doorbell motion:

Here’s how the doorbell button looks:

Next is the call service node taking a snapshot:

Here’s how it looks on the inside:

A few things we need to go over with this. The “snapshot” service does what it’s called, it takes a snapshot of the camera you specify in entity ID. In this case, “camera.front_door_last_activity” is the camera we’ll be taking a snapshot from. In the Data field, you’ll notice “filename” and the location of where the snapshot will be stored. So a snapshot is taken of the camera, and stored where you specify in the data field. We then use a delay node set to 1 second to give the snapshot time to copy to the file location. We then use a call service node to send the snapshot from the save location to whatever notify service you are using. I’m using Telegram, so I send it with the send_photo service. Below is the configuration.

With this flow configuration, you will receive a photo of your doorbell when motion is detected, or the button is pressed. Here’s the code.

Location based automations, with Node-RED.

Justin

Location based automations are a great way for your house to respond to your presence. Set your thermostat, alarm, and lights depending on whether you are home or not.

I do this using trigger state nodes.

This nodes considers an entity’s current and previous state and passes on the message. We’re going to use it in it’s most basic form, which is very easy.

This can work with any entity that has more than one state, but we’re using it with my life360 device tracker right now. In this instance, if my device tracker goes from “not_home” to “home” pass the message from the top output. Anything else goes from the bottom output.

Let’s put together a basic location based flow.

We’re going to grab a trigger state node and two call service nodes. Remember that if everything is true, it routes the top output, if not, bottom output. So if I go from not_home to home, top output.

The two call service nodes I’m using in this example are to control my Ecobee thermostat, but you can use yours to do whatever you like. Lights, security system, garage door…any service that can be called. Here’s how one of those look:

And here’s how the entire flow looks:

Pretty simple, but very powerful if used properly. Here’s the code

Node-RED and Telegram

Justin

If you already have a Telegram bot setup in Node-RED, see my post, Better notifications with Telegram and Node-RED to send notifications with Telegram formatting and logging.

In my humble opinion, Telegram is probably the best way to send and receive notifications from Home Assistant. You can create groups for everyone in your house, you can respond to notifications, receive pictures, videos or even gifs. It’s a great service…and doesn’t cost a thing. The setup isn’t too bad, but it does require some programming in YAML.

Here is the official documentation on creating a chatbot within Home Assistant. Although you’ll have to create a Telegram Bot first. Make sure do both of these things. Also, here’s all the cool things a Telegram Bot can do once it’s setup.

Alright so now that I’ve gotten all my swooning out of the way, you’ll need to first add the bot to your configuration file, as per the official documentation. If you’re not, you should definitely be using the secrets.yaml

**One thing to remember, for how we’re setting up our Telegram bot in this particular instance, you’ll want to set the platform to “broadcast” and not “polling”. If you set it up as polling, your Home Assistant log will get flooded with Telegram bot multiple instances errors, after you setup the Node-RED side of things.**

Once this is done, you can use a call service node to test the Telegram bot. Here’s how it should look to test:

Connect an inject node, and press the tab to test.

You should receive a “Test” message from your telegram bot. You can also see the notifications with a picture from my doorbell. We’ll get to that in another post.

Now you have working Telegram bot notifications within Home Assistant. Not to bad right? Here’s an example of a notification with a button to respond. I use these in my “Alarm has been armed” notifications, as well as the “Alarm has been triggered” notification. We can disarm the alarm when it’s armed for whatever reason, or disarm it when it is triggered. Here’s what the call service node configuration looks like:

This is how it looks when the notification is received.

Telegram bots respond to commands, that are sent with a forward slash. /arm and /disarm are examples, but your Telegram bot doesn’t know what to do with them yet.

So how do we get Telegram to respond to the /disarm command that is sent when the Disarm button is pressed? This requires installing some new nodes so we can run the bot in Node-RED. To start, click the top right hamburger menu and go to “Manage palette”.

Once there, in the search bar, search for “node-red-contrib-chatbot“. You’ll see one result. This is Redbot, an incredibly good Node-RED chatbot. Install it and wait a few seconds. You’ll get a notification when it’s done. This installs a bunch of new nodes, 74 to be exact, as of this writing. This initially will look very daunting at first, but it’s really not, and we’ll go through the basic setup.

Before we continue, if you don’t recall or can’t find the API token that was given to you during your bots creation, go talk to the BotFather and send him the /token command, and he’ll give you the API token for your bot. On we go…

There are two nodes that you need to pull out, Telegram In, and Telegram Out.

Put those guys in a new tab in Node-RED. Open up one of them, doesn’t matter which, and click the edit button to the right of Bot configuration (development).

Fill it out with all this info:

Click Add, which will take you back to the main node configuration. Use the drop down under Bot configuration (development) and select the bot you just created.

Go to the other Telegram node, and use the pull down to select the bot you created. Both of these nodes are now configured.

The Telegram Receiver, or Telegram In, node is what listens for commands when you send them to your bot, which it grabs and sends out through it’s output. The Telegram Sender, or Telegram Out, node receives any commands or messages and sends them to the chat. We need to put some logic in between them so the bot knows what do when we tell it. We’ll start super simple so you can see exactly what is happening.

First, grab a Command node; and place it after the Receiver node. Open up the node and type /hello in the command field.

The command node will listen to everything coming from the Receiver Node and will grab all of the /hello commands. Next, grab a text node and place it after the command node. Type Hello, {{firstName}}! in the message box. This will respond with your first name (or whatever you used when creating you Telegram account). If you want a smiley, add :smile:.

Here’s what you have now:

You have simple logic that will respond with “Hello, Justin!” when it receives the /hello command. Let’s test it out. Open up your Telegram app and send /hello to your bot.

Now you have a working Telegram bot.

So, lets take what we know now, and make the /arm and /disarm commands (or whatever commands you want) work. We’re going to need another command node, and set it to grab /arm commands. Connect a new text node to the command node and set the message to “The House has been Armed”, and finally add a call service node to the end of it. Below is how the service node is configured in my example, but you can use it to anything you like. You can use it to send you a picture of one of your cameras, tell you what temperature the house is, etc.

Now, connect everything up to the Send and Receiver nodes and you’ll have this:

To review, the receiver node receives any messages you send to the bot. The command node filters out the command you program it with. The text node sends whatever message you program it with as a response from the bot. The calls service node is not part of the bot, it’s just wired in so that the bots messages will trigger the service. Here’s what the completed bot looks like with arm and disarm both setup

Working with motion flows in Node-RED

Justin

Motion automations are some of my favorites. I’ve noticed a lot of questions across the internet about how to set them up, so I’ll do a few simple ones to help others get started.

Motion activated light.
Super simple. Grab an “events: state” node undefined, and a “call service” node undefined. Configure the events state node with your motion sensor. Here’s an example of mine:

If you put a value in the “If State” field, you will have two outputs. Top is “true”, bottom is “false”. In this node, the If State is “on”, so if motion is “on” (true), output from the top, when motion is “off”(false) output from the bottom. Think of it like “If state is true – top”, and “if state is false – bottom”. Doing it this way, the flow will start when motion is detected, or true, if connected to the top. If connected to the bottom, the flow will start once there is no motion. If you leave this field blank, there will only be a single output node that will trigger every time the state goes from on to off, and off to on.

The “Output only on state change” setting is important to how your flow will behave. Lets say that the motion sensor you are using is in the living room and you’re having a party. There’s a ton of people in your house and there’s constant movement. The motion sensor will trigger when it first senses motion, and it will stay triggered until it no longer senses motion. With “Output only on state change” checked, it will only send out a message from the output once, when it was initially triggered by motion. This is because the state has not changed from “on”. If you uncheck “Output only on state change“, it will send a new message every time the motion sensor is triggered. different motion sensors check for motion at different intervals. All of the motion sensors that I use (I highly recommend the Zooz ZSE40) trigger about every 15 seconds. So a new trigger message would be sent every 15 seconds with non stop motion.

If you’re brand new to this, I realize that’s a lot of info, but it will make sense soon enough.

On to the call service node. It will need to be configured like this:

“Domain” is the first part of an entity in Home Assistant. “climate.xxxx” would be the domain of a thermostat, “lock.xxxx” would be the domain for a smart lock, etc. In this case, we’re using the “light” domain.

“service” is the action you want to perform, in this case, “turn_on” which will turn on the light that we specify when triggered. After you’ve selected your domain, you can use the drop down menu to see what services are available. Below you’ll see that the options are “toggle”, “turn_off” and “turn_on”.

“Entity Id” is where you specify what device to control. if you type in “light”, it will auto complete every entity that is in the light domain, and you can just select the entity you want.

With both of these done, the most basic configurations are done. You now need to just connect the nodes. Now what we have is a complete working flow. When the Entryway Motion node state is “on”, it will turn on the Entryway Lights, and that’s it.

Easy flow, but essentially useless in the automation sense of things. Lets have the light turn off after a set period of time.

Motion activated light with timer.
We want the light to turn off at some point, so we’re going to work off the flow that we just created and make that happen. First grab a “stoptimer” node, undefined and wire it after the other two nodes.

The way the stoptimer node works; Once it receives a message, in this example from the Entryway Lights node, which was passed on from the Entryway Motion node, it starts a 5 second timer. Once the 5 seconds are over, it sends the message. If the stoptimer node receives another message within the five second timer, it restarts the timer.

Grab another call service node and attach it to the top output of the stoptimer node. Configure it exactly as you did the first call service node, except use the “turn_off” service. So this is what you’ll have:

So now, motion in the entryway, turns on the entryway lights, waits 5 seconds and turns off the entryway lights. Are you still with me? Don’t worry about it if you’re not, it’ll all work out in the end.

So at this point we have a complete but inefficient flow. We can fix this solely with configuring the nodes in a different way.

How do we make this a usable flow?
It’s easy. As we’ve said a few times already, our example motion sensor refreshes every 15 seconds and sends a new message depending on the state of the node. If there is constant motion, it will send a message of “on” every fifteen seconds. No motion will send “off” every fifteen seconds. If there was was motion and it sent “on, and then no motion, the next message will be “off”, etc etc, you probably get the point by now. Also remember, that the stoptimer resets if it receives another message before the timer is over. So if it’s a 5 second timer, and it receives another message at 4 seconds, it starts back over at 5 seconds.
So, knowing this, we can set the stoptimer to anytime longer than the refresh time of it’s input. The example motion sensor sends an update every 15 seconds, so we can set the stoptimer to 16 seconds. The motion sensor sends a message the first time it detects motion, which turns on the lights and then starts the stoptimer. If there is no more motion, the light will turn off in 16 seconds. If there is still motion, within the 16 seconds, it restarts the timer. The timer will be restarted as long as there is motion, which will leave the light on while the room is occupied.

Or will it? Remember that check box, “Output only on state change” ? With this checked, even though the motion sensor sends an update every 15 seconds, the Entryway Motion node would not send an update because the state stays “on” with constant motion. State doesn’t change, it doesn’t send a new message. With it checked, it would only send a new update to the top output when the motion went from on, to off and then back to on.

So, we uncheck it. This will allow the Entryway Motion node to send a new update every time it receives one from the motion sensor, even if the state never changes. Even if the state stays to on for an hour because there’s constant motion, it still sends an update every 15 seconds from the motion sensor, and since the timer is set to 16 seconds, the light always stays on with motion.

If your motion sensor sends a new update every 8 seconds, you’d want to set the stoptimer to 9 seconds to keep the light on with motion. Twenty second motion sensor, 21 seconds stop timer, etc etc.

Here’s the code of the above flow for import.

Here’s another motion flow as an example. If the dining room light is left on, and there is motion, the light will stay on. If there is no motion for 20 minutes, the light turns off. Le’ Code.

Node-RED + Home Assistant Security System

Justin

In this post, I will show how I setup my home security system. Setup this way, it is a manual system, and will need to be manually armed and disarmed. I will share how I’ve automated the system in later posts, that will be linked here.

My last two houses were smart homes. SmartThings was my hub of choice at the beginning, and it was good. One of the things I liked so much about SmartThings was the Smart Home Monitor that is built in. This does a few things, one of which is act as a security system, which is what we used it for. There is nothing like this built into Home Assistant out of the box, so one of my first goals when learning Node-RED was to create a home security system.

Home Assistant has a built in Manual Alarm Control Panel that can be used to build a security system, which all has to happen in the config files. Since I’m doing all of my automations in Node-RED, I wanted to try building a security system from a combination of the built in panel and Node-RED. I wanted to be able to set the alarm mode from the panel and have Node-RED handle the rest.

To start off, I created an “alarm.yaml” in the config directory of Home Assistant, and made sure to add “alarm_control_panel: !include alarm.yaml” in the config file. This is the code that I used, which will allow the away alarm to trigger after 120 seconds, and give you 30 seconds to leave the house once it’s armed. All other modes arm instantly.

This will create a “alarm_control_panel.home_alarm” entity, which when used in Lovelace, looks like this:

So now that the front-end is done, time to move on to the back-end of the machine. I built all of the logic within Node-Red. This is how the finished result looks.

The “events: state” node undefined grabs the status of the Manual Alarm Control Panel, and passes it on to the switch node undefined which then filters the alarm status to the appropriate output.

Below that, is the trigger automation. The “Alarm Triggers” sub-flow contains all of the doors and windows in the house, which is connected to another sub-flow that checks if the alarm is armed either home, or away, and then passes it on to a call service node that triggers the alarm, and finally sends a Telegram notification letting us know the alarm has been triggered, along with a button to Disarm the alarm. Example of the “Armed Home” sub-flow.

Sub-flow for the Armed Home mode for reference,

Since there’s so much going on with this flow, I won’t go through it in detail, but I will post the code which you should be able to work off. It’s pretty straight forward.

Here’s the Node-RED code: Security System
Here’s the yaml code for the panel: alarm.yaml

Currently, there is zero automation involved. This has to be manually set, but I have location and timed based automations which I will share in future postings.

Updates:

8/24/2020 – Updated the alarm.yaml code to reflect recent updates Home Assistant has had regarding the manual alarm panel.

Using smart switches and smart bulbs together, with Home Assistant and Node-RED.

Justin

(Amazon links are affiliate links, where I get a small commission of purchased item)

I have 6 Hue A19 Color bulbs in the ceiling of my kitchen. We were using them with standard dummy switches, which was a pain as I had to constantly remind people to leave the switches on. Not to mention that it is bad for smart bulbs to be constantly powered on and off. I was about to pull out the smart bulbs and install standard LED lights and go with smart switches, but I really did not want to do this, as the individual bulbs are used for certain automations. For example, a nightlight where bulbs 1 and 3 are motion controlled to come on at 5% if everything else is turned off, and it’s dark outside.

How to get around this to keep my smart bulbs AND keep them powered at all times? At first, I tried using a Sylvania Dimming switch and control the lights with a scene. This switch is placed over the existing dummy switch, which you leave flipped on. Since this was a 3-way setup, I put a switch cover over the second switch (you could also get a second Sylvania switch). This worked….I now had always powered and physically controllable smart bulbs, and although it was a practical solution, it was kind of ugly. The wife definitely didn’t like the look in her new home, so I was back to trying to figure this out.

All of the smart switches in my house are of the Go Control / Linear / Nu Tone variety. These are all made by the same manufacturer, but sold under different names. They are not Z-Wave Plus, but I got the first one years ago and have been matching them together ever since. I haven’t noticed any downfalls of them not being Z-Wave Plus, but they’ll eventually be upgraded. For a three way setup, there is the NuTone NWT00Z which are not standard add-on switches. These are “virtual 3-way” switches. The low ratings on Amazon are somewhat understandable as the documentation (PDF of the manual here and here) is cryptic at best, and does not say explicitly how to use these. I will say that we’ve had these installed for a few months now with zero issues.

The way these are intended to work, are as “remotes” to other switches. In my entryway, I have one installed in a 3-way setup with a NWD500Z dimmer switch. You wire it up and and it controls the master switch in a zwave group association, but we’re going to do something different with them.

I used two of these in my kitchen. The way to wire them and have the lights always on is an odd way. Take the load, line and traveler wires from the wall, as well as the load line from the first switch and connect them all together. The ground and neutral are wired up as normal. The second switch needs to be wired a little differently as well. Take the line and load wires from the wall, cap them together and stuff them into the wall. Take the traveler wire, which is now a constant 120v line, and connect it to the load line of the NWT00Z. Wire the ground and neutral up as normal.

Now what we have are two smart switches that are wired up and connected to the mains, but they do not control the power to the lights. The power is now constant to the smart bulbs. At this point, the lights will stay powered on, unless you control them from Lovelace or using voice if you have Google Home/Alexa setup, but theres no way to mechanically control them yet. The hard part is done and we now have to head over to Node-RED and start working on the automation to turn these on or off.

We can’t add the switches to a Zwave group association, as the Hue lights are zigbee. So we need to grab the zwave event type commands coming from the switch. To do this, use a “events: all” node and filter “zwave.node_event” commands. Example below.

“events: all” node

So now we’re grabbing all node_events from the “zwave.” domain, now we need to filter them. To do this, we need a switch node to filter the “payload.entity_id” from the specific switches we setup. You’ll need to use the name that you gave these switches when including them in your network. One thing to remember, you need to use the “zwave” domain name, NOT the “switch” domain name.

At this point, we’re filtering the two switches with “payload.entity_id”. Now we need to filter it down again to get the actual commands from the switches. With these switches, “0” is off and “255” is on. We need another switch node and filter “payload.event.basic_level“. This will grab all “.basic_level” events that come over the two switches. You’ll want to connect both output nodes from the previous switch node to the input on this switch node. This will filter all commands from both switches to this node. In this node, the top output will be “on” and the bottom output will be “off”.

We’re almost done at this point. Now we need to use a call service node to turn on, and off the lights. I forgot to mention earlier that the easiest way to control multiple lights, is with a light group. This will create a “group.kitchen_lights” entity in Home Assistant. You’ll need to do this in your config.yaml or groups.yaml in Home Assistant.

Now we take a call service node, and configure it to control the kitchen_lights group. We need one for on, and one for off. The “on” node will be connected to the top output, and the “off” node will be connected to the bottom output.

Call service node to turn on the kitchen_light group.
Call service node to turn off the kitchen_light group.

Here is how the entire flow looks:

With this setup, we have Hue smart bulbs that are always powered and can be manually controlled by a switch. This allows individual bulbs to be used in automations and you don’t have to worry about the switches, like in me previous example of using lights 1 and 3 for a nightlight.

One more thing to keep in mind; When smart bulbs lose power, they will come on at full brightness when power is restored. The Hue bridge however has a setting for “power on behavior” where you can tell the bulbs what to do when power is restored.

Here is the formatted code if you’d like to import it and work off of it.