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

(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”:”” . 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.

Working with motion flows in Node-RED

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.

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

(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.