MQTT and NodeRed on an airplane?

I've had several posts about using NodeRed for home automation, communicating with various nodes over MQTT. Could I do the same in the airplane? I think I could, and there would be some benefits to it. Certainly less wiring, and maybe more reliable and customizable.

The whole point of this blog originally was to use an Arduino and be able to monitor the engine status. Originally, I was going to use a Mega, and a bunch of shields. The old eco-system caused me to lean that way. Mega on the bottom, a custom shield next, and a Bluetooth shield on top. The world has moved on, and now I can use ESP-32 and 8266's with built in Wifi and Bluetooth. The boards only cost about $10, instead of the $20+ for the Mega and Bluetooth shield.

The sensors can mostly be wired to the ESP-8266 board with SPI (3 wire) communications, through adapter boards. If I need an analog or digital input, it is available on the board as well. There are very inexpensive thermocouple modules available, that would take care of the CHT and EGT measurements. The oil pressure and temperature would be analog inputs if I stick with the stock probes, but there is the Dallas18b20 probe that could be used to measure temperature, but there only one temperature measuring point on the engine. The Dallas 18B20 can be used for OAT measuring.

The oil pressure transducer is off on a flex pipe, with a manifold for to hold the hobbs switch. (theoretically, the oil pressure measurement could be combined in the computer somewhere to enable the hobbs timing measurements). There are nice solid state pressure sensors that may be appropriate for fuel and oil pressure, I need to do additional research.

Volt and Amp measurements can be done using the analog inputs, using the existing shunt for current measurements, or adding another shunt. There are also hall effect sensors that could be used to measure current. Using various current sensors would allow measuring all the important values at once, charge rate, drain rate, etc.

The tach measurement can come off the mag or EI unit. A transistor or optoisolator should work when connected to a pin that accepts interrupts.

Other sensors could be added or deleted anytime using additional nodes. If I want to measure the airflow through the baffles, I could add a node with multiple pitot tubes to see where the air might be leaking.

Then the question becomes, how many nodes should I use? It would be tempting to build one for each sensor, I want to limit the nodes to one function (I've said that before). How gray to I want that idea, one function could be all the thermocouples. Another node for all the oil information (pressure, temperature). Another for the fuel pressure, levels. Convenience may dictate some other arrangement, like thermocouples left side, thermocouples right side, that way the wires don't have to be so long.

Each node will still need 5V or 3V connected. It would be tempting to use the micro-USB connectors on the boards to feed the power. I think, the constant vibration would make the connectors fatigue very quickly, and the power would be falling out. It would probably be best to solder the power to the boards.

A $10 raspberry PI zero could be the NodeRed/MQTT hub. The raspberryPI should be mounted inside the cockpit. I am sure the WiFi signal can get around the firewall on a plastic airplane. Even a metal aircraft should have WiFi from the engine compartment to the cockpit. I'd have to try it out though.

In the cockpit, PLA printed enclosures should work fine. In the engine compartment, there may be problems with PLA or printed enclosures (constant vibration, heat, and rain). 3D printing my own enclosures may be compromised quickly. It may take some experimenting, certainly to make appropriate mounting choices, considering the sensor wiring stresses and heat.

NodeRed should allow nice cockpit displays of the instruments, and allow logging in various formats including CSV. Using the same CSV layout as the COTS instruments (like J.P Instruments) would allow people to analyze engine performance using off the shelf tools (excel, etc). The file could be scp'd from the Arduino, right to a tablet or phone, taken home and analyzed.

I don't know. I see a few worrying things, but nothing that is really scary about doing it. Can you talk me out of it?

Knowing The Garage Status

I've finally got it working the way I want. If you have been following my garage work, for the last 10 years, I have wanted a way to know if I closed the garage door after I left. I tried several ways, using email and other schemes to know. I finally have a way to know, and it seems quite reliable.

I have Google assistant acting as the middle agent, and with the rest of the infrastructure it seems to be very reliable. Node red knows the state, and has all winter. The voice assistant that I brought up last post is connected to node red, and I have MQTT messages going to the Google assistant. I can ask Google assistant on my phone or tabled to know the current state.

The two categories for doors in gBridge are:

gBridge/uNNN/d4149/openclose is for querying the current state. gBridge/uNNN/d4149/openclose/set is for setting the current state. If I can get the garage device to talk to node red (I am trying, stay tuned), then I will have the node-red control the garage. For now, I am still using the garage android app.

I've broken up the garage flow, and added two new functions. I created a combiner, that will mix the state of the two doors into one message. I have the combiner return a payload of open if either door is open, otherwise will retrun a payload of closed. That function looks like:

// if either door is open, return open, otherwise if both // doors are closed return closed.
context.bigDoor = context.bigDoor || 'closed';context.littleDoor = context.littleDoor || 'closed';
if (msg.topic === 'garage/bigDoor') {  context.bigDoor = msg.payload;} else if (msg.topic === 'garage/littleDoor') {  context.littleDoor = msg.payload;} 
if ((context.littleDoor === 'open') || (context.bigDoor === 'open')) {        msg.payload = 'open';} else {    msg.payload = 'closed';}msg.topic = 'garage/door';
return msg;

The alarm function node was simplified, to only check the state of the combined nodes and the time.

// if either door is open, after 11pm and before 6am // sound an alarm.
context.hour = context.global.hour || 12;context.door = context.door || 'closed';
if (msg.topic === 'garage/door') {  context.door = msg.payload;} else if (msg.topic === 'time/ISO-8601') {    context.hour = msg.payload.hour;}
// check the status, to know if alarm should be onif ((context.door === 'open')  &&    (context.hour > 22) || (context.hour < 6)) {    // msg.payload = "on " + context.therm + " " + context.temp;    msg.payload = 'on';} else {    msg.payload = 'off';}return msg;

This should make the alarm more reliable as well.

The new function node converts the payload "open" or "closed" to "100" or "0" that the gBridge door nodes expect. The value can be something between 0 and 100 to indicate partially open or closed. I haven't played with it, so I don't know if there is a threshold, but the voice will say "open" if the value is set to 100.

// Convert a msg payload that says "open" or "closed"// to a msg.payload "100" for open, and "0" flr closed
context.flow.value = context.flow.value || "0";context.flow.newVal = context.flow.newVal || "0";
if (msg.payload === 'open'){    context.flow.newVal = "100";} else {    context.flow.newVal = "0"}
if (context.flow.newVal === context.flow.value) {    //msg.payload = {newVal: context.flow.newVal,    //               value: context.flow.value};    //return msg;} else {    msg.payload = context.flow.newVal;    context.flow.value = context.flow.newVal;    return msg;}

I have the ConvOpenCloseTo100or0 function will only send a message on a change. If the door is closed, the MQTT message will only be sent once if either door is opened. Again, if a door is open, it will only send the MQTT message when both doors are closed.

This is something that may allow Google to invade my privacy a little. It should still keep all the logic inside my house (on the edge).

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.