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.

Starting Node-Red

This will be the start of the Node-Red posts. There will be several, and as far as the MQTT/IoT posts go, it will be on going. Node-Red is such a capable and flexible tool it will be very complex to talk about all of it, and provide examples.

The Node-Red page talks about installing the tool. There are ways to install it on the various systems, and the installation page covers all of them. I shouldn't need to expand on that too much more. For any of the extensions, I will cover any of the nuances needed for a specific example, as I cover that. I am open to answering questions, if the instructions aren't clear enough.

Node-Red introduces the concept of "flows" to the IoT landscape. A flow will involve one or more inputs to cause one or more things to happen or output. Flows are not typically written, but rather drawn.

When Node-Red is opened the first time, there are no flows, only nodes. On the left side of the screen are all the available nodes. On the right are tabs allowing the developer to know details about the node selected, and to debug all the flows. To build a flow, simply drag a node from the list to the flow. Then the nodes can be connected by drawing lines between them. To set the properties of a node (name, action, etc), double click on it and a dialog will pop up.

Simple First Flow

To build a simple flow, start with a source node. The first node "inject" when dragged changes names to "timestamp" (this is unusual, but don't worry about it). The first output node "debug" also changes to "msg.payload" when dragged. Drag one of each to the flow, and draw a line from the output of the "timestamp" node to the input of the "msg.payload" node. The screen will look like:

The first thing to notice is the blue dots by both nodes. This indicates that the nodes haven't been "deployed" or saved. Until the nodes are deployed, they will not change actions. The Deploy button is also bright red ready to be pressed. To have this flow do something noticable, double click on the "timestamp node". The edit dialog will appear. For the "Payload" enter "HelloWorld" (or what ever you want to see output). Then press "Done":

The edit dialog will go away. Press the "Deploy" button at the top, and select the Bug icon just below the "Deploy" button. Pressing the "Deploy" button caused a pop up saying the flow has been deployed, the name changed on the "msg.payload" node and the blue dots on the nodes clear as well. On the left side of the "HelloWorld" node there is a nub, that is really a button that can be pressed. 

Press this button, and the "HelloWorld" text will display in the right side debug tab, similar to:

Changing the payload in the original input node will cause the msg.payload node to output whatever is in the payload to output in the debug tab. The debug node can be used to test the payload sent from any node in any flow. 

Adding External Nodes

There are lots of outputs that are available, including mqtt, qweb socket, tcp, udp, etc. There are special ones for email and twitter. To build on the last couple of posts, we will add the MQTT tone node. We can build extra things in the current flow. Add the MQTT output node to the current "Flow 1" that we have been working with, or start a new flow by pressing the "+" tab at the top of the tab pane window. 

Double click on the MQTT node, to bring up the edit dialog. Select "enter new mqtt-broker" and press the pencil button. 

I'll assume Mosquito is running on the same machine as Node-Red. If not enter the IP address or host name of the MQTT broker in the server field. Leave the port as 1883, unless your mosquito server is running on another port. If Mosquito is running on the same machine as Node-Red, then enter "localhost" or 127.0.0.1 for the server name. Leave the other fields and tabs blank for now. Then press "Update". The dialog will switch back to the "Edit mqtt out node".

For this test, we will just test the light of the node. For the topic, enter "alarm/light" and change the name to "light". Then press done. The edit dialog will go away.

Drag two "inject" nodes on the screen. Change the string to sent to "on" for one, and "off" for the other. Drag the output from each to the input to the MQTT input. The screen will look something like:

Press deploy, and the the blue dots will go away and the light node should have a "Connected" square under it. If you can see the Alarm output node, pressing the "on" button will turn the light on, pressing the "off" button will turn the light off. The debug tab will not show what is happening, because all output of the inject nodes goes to the MQTT "light" node. Adding a debug above the MQTT light node will allow you to draw from the "on" and "off" nodes and then the output will be visible in the debug tab.

To input something from MQTT will be similar. Since there is already an MQTT broker defined, select the one created from before. Mqtt being pub/sub, will allow Node Red to be the publisher and the subscriber. It is possible to hear the published message in the same flow. Set the subject as "alarm/light and create a debug node:

It ends up as a loop back, but you can see the MQTT in is subscribed to the topic. Any MQTT node that outputs can be subscribed in node-red that easily.

I've made you dangerous, now go try some more. Maybe have a flow email you a message or something. Next time, we will build an input physical node and start to use it in node-red.