Voice Control

Almost everything can be voice controlled these days. Ask your phone, and it'll tell you stuff you didn't know you needed to know. Apple, Google, Amazon and others all have voice assistants that can be used for control of appliances, buying stuff or just entertainment. Node Red has nodes that support most of these assistants.

I have been mostly using the Google infrastructure, since it is typically more open. It isn't perfect, but it does allow me to develop apps and write blogs. I have had some success using their tools for automating my home.

NOTE: gbridge is no longer a solution. The company no longer supports this application. 

I am using the gbridge node. The setup is very simple, using a standard MQTT interface to their service. It does take some registration on their web site, and in the google home app. They support multiple levels of usage, and allow self hosting. The self hosting can be done on the same RaspberryPi that Node-Red/Mosquitto is running on. The free service allows 4 devices, and more than that will require a subscription, and you choose how much to pay.

Setting up something simple

In the account on the gbridge site, you can set up various devices, what traits (open, close, on, off, etc) those devices will exhibit and what the topic and payload is allowed. This must be done before adding the node to node red.

I connected this to my most complex flow, and it worked right out of the box! After following the setup steps properly. The flow is very simple:

Just an MQTT input node, a debug node and a connector. The connector goes to the heater flow in the previous post. The single "google voice" node could go right in the heater flow without adding much complexity to that flow.

The MQTT node has some configuration:

The server is the gbridge server. This is another MQTT agent that the Node-Red will talk to . It should be set up as any other MQTT agent is added to node-red (like localhost for any of the connections to mosquitto running on the Raspberry Pi).

The URL will have your user number in it. This is your number, and shouldn't be shared with anyone, unless you want others to control your home. The uNNN is my number obfuscated, so I can prevent you from controlling my house.

Once all that is set, using a google assistant (voice or typing), I enter the command "set sunroom thermostat to 80" and the thermostat setting will change to 80 degrees. The payload from the MQTT node is the temperature.

The voice assistant understands other commands like "make it cooler", "make it warmer", but my flow doesn't know what to do with those commands. The payload from the Google Voice MQTT node will send "3" for make it warmer, and "-3" for make it cooler. This could be used in a function node to adjust the current temperature, but for now, I won't use them. What happens now, the thermostat will be set to 3 degrees if the "make it warmer" command is asked.

There are other topics that can be used by node-red to allow querying the status of the node as well. The "gBridge/uNNN/d1000/tempset-ambient/set topic allows me to ask the google assistant what the current temperature is in the room.

I'd like to ask the current state of the garage as well. I've driven off many times, and been unsure if I shut the garage. MAybe in the next post, I'll show how to do that. I also want to show the library that I have made to simplify the nodeMCU development, and other things. There is lots to come.

Ask any questions.

Heater Flow

As promised, I am going to present the flow used for the thermostat node. This flow has a nice dashboard, so it can be controlled from my phone, or from the thermostat, or any other flow input.

The flow:

We can start from the center, the "Check Thermostat" function node. This function take inputs from the heater/state, sunroom/thermostat and sunroom/temperature MQTT topics. The heater/state is published by the nodeMCU attached to the heater, and the payload is either "on" or "off" depending on the state of the heater. The sunroom/thermostat and sunroom/temperature topics are from the thermostat nodeMCU from the last post. The sunroom/temperature payload is a number indicating the temperature measured by the DHT-22 sensor converted to degrees Fahrenheit. The sunroom/thermostat payload is a number representing the setting the thermostat was last set to.

 // if temp is less than thermostat turn on heater.
flow.temp = flow.temp || 0.0;
flow.therm = flow.therm || 70.0;
 if (msg.topic === 'sunroom/thermostat') {
  flow.therm = parseFloat(msg.payload);
} else if (msg.topic === 'sunroom/temperature') {
  flow.temp = parseFloat(msg.payload);
} else if (msg.topic === 'heater/state') {
    flow.state = msg.payload;
}
// add a dead band, if on turn off 1 degree late
if (flow.temp < flow.therm) {
    // msg.payload = "on " + flow.therm + " " + flow.temp;
    msg.payload = "on"
} else if ((flow.temp > flow.therm) &&
           (flow.state === 'on')) {
    //msg.payload = "off " + flow.therm + " " + flow.temp;
    msg.payload = "off";
}
return msg;

There is only one thing output from this, and it indicates if this wants the heater "on" or "off". The output of this is determined if the temperature is less than the thermostat (flow.therm) the payload is sent as "on". If the temperature is greater than the the thermostat setting, and the heater is currently on (flow.state from the heater/state topic) then the payload is set to off. If the temperature matches, it does nothing.

Sometimes the sensor is right on the edge 72degrees/73degrees and it jumps back and forth, so the heater turns on and off frequently. Leaving the sensor to not do anything if the temperature matches the thermostat setting allows the heater to have some hysteresis, and take maybe a minute to change states.

The output of the check thermostat goes to the heater/gas topic, listened to by the nodeMCU connected to the heater itself. There is also a debug output and it is handy to have while debugging things. The function code allows additional information in the payload to see what the current temperature and thermometer settings are when changing state, but that will only work with the debug turned on.

The blue boxes are for the dashboard. The current temperature is a gauge_ui element, and is at the top.

The slider under the gauge is the current thermostat. This is a pass through UI element. It will adjust based on messages heard on the "sunroom/thermostat" MQTT topic, and will send values through to the heater thermostat topic.

The settings look like:

There is also a text output that will show the current thermostat setting. The UI is a relative bar, and no other indicators. I typically add the text items so I know what the slider is pointing at.

I have two switches, both pass through. The current heater state is indicated by values coming in on the heater/state MQTT topic. Clicking this button on or off will output the state to the heater/gas MQTT topic turning the heater on or off (manually). The light on/off is similar sending on the heater/light topic and indicating the debug on/off buttons.

There is a filler UI element. Without the filler the UI sometimes randomly wrapped funny.

That is something to play with to get the widgets. to align properly.



A keen eye might notice a connector widget in the middle of the flow that I didn't mention. This is for the voice input. Yes, from my phone, a Google assistant or other device I can control my house by voice. That is for a future post.