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?

Eggbot; filling in some missing information

I guess it is that time of year, people are building Eggbots. I built one, and needed to learn a bunch. Some of the information was vague, or not connected to the original design, or anyone elses design.

I started with a Russian frame that I liked on Thingiverse. This was mostly lacking any real documentation. Elliot from Hackaday has a page with lots of information, including how to make a CNC shield move a servo, and how to get G code out of inkscape.

The Russian frame had a bunch of options for the pen holder. I chose the simple one, and am having success using that with a sharpie fine point. Being an American, it was easier to get 1/4-20 5/16-18 threaded rod than 6mm, so that is what I used. I cut 3 1ft pieces. For the rest of the bolts and screws, I used metric (m4 and m3 mostly), since the motors assume metric.

One tool that I will call essential is the taper cutter. Cutting threaded rod is easy, but the threads are suddenly all mucked up. Either the taper goes away, and threading on a nut has to be aligned perfectly, or the threads are bunged up so badly nothing will thread on anymore. This tool will make the trouble disappear, in about 2 seconds!. Sure you could file a taper in using a file, or grinder, but for less than $5, why?

The Russian  frame also assumed some 16mm bearings, that I didn't order. Another similar frame used skateboard bearings in a holder with the same bolt pattern as the stepper motors. I just reprinted the left frame from the Russian frame and two of these bearing holders for the end.

I couldn't find O rings that would hang onto the egg good. One end or the other would slip, and the drawing wasn't real good. I found some #17 bath diverter washers that seemed to be a better shape, and fit the end caps well. They still slipped.

I've started playing with some table foot rubber pieces, like on the bottom of a crutch. They are more grippy. I'll update when I know more.

Some page, maybe another one on Thingiverse suggested I use a CNC V4 Shield. A great design, with the Arduino Nano right on the board with the stepper drivers. The trouble is, the common Chinese clone makers messed up the board. A couple others have figured out the changes needed, and published the wiring changes to make this board work.

What I have seen though, the inkscape G code output doesn't quite make the pen up/down command that the GRBL expects. The delays are about 100 times longer than they say (seconds instead of milliseconds) as well  (Update, in the save dialog, it lets you set delay to 0, that seems to work). Long delays with the pen over at an angle almost always messes up the continuation of the lines. I end up hand editing the G code output. I should probably build a python or perl script to fix the output, or just figure out what unicorn changes are needed.

Changing the GRBL source code, it is important to remember you moved the code to the Arduino directory, so change it there, not where you expanded the code. If the motors are going backwards, reverse the plugs on the CNC V4 board.

For test eggs, I have been using the 18 for a dollar plastic eggs that I can get at the Dollar Tree. I like hard boiled eggs, but I didn't think I'd eat 24-36 in the next couple of weeks. I should look into dry erase markers to see if I can erase the test eggs.

A New Standard for Home Automation

Big news this week, Apple, Google, Zigbee Alliance, Amazon, Samsung, Ikea, and every other company in the world are getting together and building a new standard for home automation! Sounds wonderful doesn't it?

Today it is hard to get homelkit stuff to work with Phillips Hue. Google doesn't work with Amazon, and so on. This new alliance will be the answer to the worlds problem. Peace in the middle east, no more starving children, climate change has ended.

Yea right!

Before this standard will be mainstream, it'll take at lease a year before the standard is hammered out, assuming everyone cooperates. Hardware built to meet this standard will come shortly after that, maybe. Will it all interoperate? no one knows.

It'll likely take 5 years or more for the most of these manufacturers switch their devices exclusivly to this standard. Between the time it takes to flesh out the standard, getting the functions needed on these standard, and the manufacturing pipeline, it is just the way things are. No one needs to stall to make this take so long, it just will take that long.  

Standards are written to be slightly ambiguous, for many reasons. Google will interpret one part different than Apple interpreted it, as well as Amazon, so they will work similar, but not totally compatible. It is the way life it. Certainly a zigbee device won't be able to talk to a BLE device, who can't talk to a WiFi device.

This new standard will work in the hubs, and almost no where else. The hubs will talk to the devices that manufacturer built them to work with, and nothing else. That sounds like the way things are today, only there is likely to be more things that work with the Amazon or Google hubs.

What should you do?

• Wait? that is fine, if you have been waiting and have limited need for home automation. Maybe pick a hub after one is released in a couple years, and a couple minor devices at the same time. After 3-7 years, it will be ok to stick with products that promise to work with the hub you picked.
• Keep using what you have? If you have something and it is working for you, keep going. No need to change now. Maybe in the future, your protocol will migrate to the new protocol, or the new hub will support legacy protocols. 
• Pick something and start now? If you want home automation now, then pick something and get started. It should keep working for then next few years, unless the manufacturer changes their mind or goes out of business (and plenty have, including Best Buy, Lowes, and others). 

The home automation landscape hasn't changed a bit with this new standard. Over the last 20 years companies have come and gone in this space. Having a bunch of companies get together and promise a new protocol changes nothing.

Home automation is a little easier than maybe 20 years ago, but it is still someone mostly for tech savvy individuals. Nothing wrong with that. If you are handy with the soldering iron and some coding, the NodeMCU/Node-Red solution will work. If you want plug and play, pick a manufacturer and stay in that eco-system.

Time on MQTT

I've been promising for a while to write about the time keeping on the network. Well, now is a good time.

Time can be important for many applications. Automatically enabling an alarm system is one use, setback thermostats are another use. One thing that everyone wants to know is what time is it now. The answer to what time is it now, ought to be the same for all systems on the network.

The Raspberry PI has an on-board clock that keeps pretty good time. It adjusts local time for daylight savings and other similar events.

Node red can query the server time, and use that for various things. For my setup, I have a global context to hold the current hours and minutes, and I have an mqtt message sent out every second with the full local time details in a JSON payload.

CDTstring: "2019-05-13T18:58:46"

hour: 18

minute: 58

second: 46

year: 2019

month: 5

day: 13

I mostly only worry about local time, so that the nodes don't have to convert to local time. The individual elements allow the various nodes to act when the hour is 3 or when the minute is 33. They can use any combinations of the current time.

The flow is very simple:

The convert time function converts the system time to local (central) time. Toward the top, where the "new Date()" call is made, there is a language format (en-US, english United States), ant the timezone is "America/Chicago" which is US central time.

// Create a new JavaScript Date object based on the timestamp
// multiplied by 1000 so that the argument is in milliseconds, not seconds.

var currentUtcTime = new Date(); // This is in UTC
var date = new Date(currentUtcTime.toLocaleString('en-US', { timeZone: 'America/Chicago' }));

// Hours part from the timestamp
var hours = "0" + date.getHours();
// Minutes part from the timestamp
var minutes = "0" + date.getMinutes();
// Seconds part from the timestamp
var seconds = "0" + date.getSeconds();

var year = date.getYear()+1900;
var month = "0"+(date.getMonth()+1);
var day = "0"+date.getDate();
// Will display time in 21:30:23 format

var timeStr = year+"-"+month.substr(-2)+"-"+day.substr(-2)+"T"+
              hours.substr(-2) + ':' + minutes.substr(-2) + ':' + seconds.substr(-2);

context.global.hour = date.getHours();
context.global.minute = date.getMinutes();

msg.payload = {"CDTstring" : timeStr,
               "hour": date.getHours(),
               "minute": date.getMinutes(),
               "second": date.getSeconds(),
               "year": date.getYear()+1900,
               "month": date.getMonth()+1,
               "day" : date.getDate()};


return msg;

The timestamp is the inject node firing once a second.

I use the topic "time/ISO-8601" because I was outputting that only for the time. The UTC conversion was done on the nodes, but I quickly found that to be tedious to do for each node that needed the time. Now I do the conversion in node-red and send out the converted time.

Now maybe the other nodes that use time will be more complete.

Should I write about GPIO next time, or USB connected Arduino's? Both are supported by node-red, and can have use in an automated system. Let me know.

Autonomouns Cars; Edge Computing or Cloud?

If you want to demonstrate cloud computing vs edge computing, why not build something to demonstrate the ideas. I have an MQTT controlled robot!

The robot has the usual suspects, with the ESP8266 for the SOC, an HC-SR04 sonar on the front, two continuous revolution servos attached to the wheel on a hobby robot chassis. The schematic is actually from this page: https://www.instructables.com/id/HackerBoxes-0013-Autosport/ that is where I got the kit.

This is my own code, that is running on the 8266. It looks the same as most of the other MQTT nodes in the house:

// 
// 2WD NodeMCU controlled over MQTT (node-red)
//   Sonar distance measured at regular intervals sent over MQTT as well.
// 

#include <ESP8266WiFi.h>
#include <PubSubClient.h>
#include <PubSubClientTools.h>

#include <Thread.h>             // https://github.com/ivanseidel/ArduinoThread
#include <ThreadController.h>

// Update these with values suitable for your network.


const char* ssid = "raspi-webgui";
const char* password = "********";
const char* MQTT_SERVER = "10.3.141.1";

#define echoPin 12 // Echo Pin
#define trigPin 13 // Trigger Pin
#define LEDPin  16 // Onboard LED

#define RightMotorSpeed 5
#define RightMotorDir   0
#define LeftMotorSpeed  4
#define LeftMotorDir    2

WiFiClient espClient;
PubSubClient client(MQTT_SERVER, 1883, espClient);
PubSubClientTools mqtt(client);

ThreadController threadControl = ThreadController();
Thread thread = Thread();

long lastMsg = 0;
char msg[50];
int value = 0;
String s = "";

int maximumRange = 200; // Maximum range needed
int minimumRange = 0; // Minimum range needed
long duration, distance; // Duration used to calculate distance

void setup() 
{
  // put your setup code here, to run once:
  pinMode(BUILTIN_LED, OUTPUT);     // Initialize the BUILTIN_LED pin as an output
  Serial.begin(115200);
  setup_wifi();


  // Connect to MQTT
  Serial.print(s+"Connecting to MQTT: "+MQTT_SERVER+" ... ");
  if (client.connect("ESP8266Client")) {
    Serial.println("connected");

    mqtt.subscribe("wheel/Left", topic1_subscriber);
    mqtt.subscribe("wheel/Right", topic2_subscriber);
  } else {
    Serial.println(s+"failed, rc="+client.state());
  }
  
  pinMode(trigPin, OUTPUT);
  pinMode(echoPin, INPUT);

  pinMode(RightMotorSpeed, OUTPUT);
  pinMode(RightMotorDir, OUTPUT);
  pinMode(LeftMotorSpeed, OUTPUT);
  pinMode(LeftMotorDir, OUTPUT);
}

void setup_wifi() 
{
  delay(10);
  // We start by connecting to a WiFi network
  Serial.println();
  Serial.print("Connecting to ");
  Serial.println(ssid);

  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");
  }

  Serial.println("");
  Serial.println("WiFi connected");
  Serial.println("IP address: ");
  Serial.println(WiFi.localIP());
}


///////////////////////////////////////////////////////////////////////
////////////  Motor Controls //////////////////////////////////////////
void rightStop()
{
  digitalWrite(RightMotorSpeed, LOW);
}

void leftStop()
{
  digitalWrite(LeftMotorSpeed, LOW);
}

void rightForward()
{
  digitalWrite(RightMotorDir, HIGH);
  digitalWrite(RightMotorSpeed, HIGH);
}

void leftForward()
{
  digitalWrite(LeftMotorDir, HIGH);
  digitalWrite(LeftMotorSpeed, HIGH);
}

void rightReverse()
{
  digitalWrite(RightMotorDir, LOW);
  digitalWrite(RightMotorSpeed, HIGH);
}
void leftReverse()
{
  digitalWrite(LeftMotorDir, LOW);
  digitalWrite(LeftMotorSpeed, HIGH);
}

//////////////////////////////////////////////////////////////////////////
////////// Sonar Sample //////////////////////////////////////////////////
long sample() 
{
/* The following trigPin/echoPin cycle is used to determine the
 distance of the nearest object by bouncing soundwaves off of it. */ 
 digitalWrite(trigPin, LOW); 
 delayMicroseconds(2); 

 digitalWrite(trigPin, HIGH);
 delayMicroseconds(10); 
 
 digitalWrite(trigPin, LOW);
 duration = pulseIn(echoPin, HIGH);
 
 //Calculate the distance (in cm) based on the speed of sound.
 distance = duration/58.2;
 
 if (distance >= maximumRange || distance <= minimumRange)
 {
   /* Send a negative number to computer and Turn LED ON 
   to indicate "out of range" */
   Serial.println("-1");
   //digitalWrite(BUILTIN_LED, LOW);   // Turn the LED on (Note that LOW is the voltage level
 }
 else
 {
   /* Send the distance to the computer using Serial protocol, and
   turn LED OFF to indicate successful reading. */
   Serial.println(distance);
   //digitalWrite(BUILTIN_LED, HIGH);  // Turn the LED off by making the voltage HIGH
 }
 return distance;
}

//////////////////////////////////////////////////////////////////////////
//////////  MQTT Stuff ///////////////////////////////////////////////////

void reconnect()
{
  // Loop until we're reconnected
  while (!client.connected()) {
    Serial.print("Attempting MQTT connection...");
    // Attempt to connect
    if (client.connect("ESP8266Client")) {
      Serial.println("connected");
      // Once connected, publish an announcement...
      client.publish("outTopic", "car connected");
      // ... and resubscribe
      //client.subscribe("inTopic");
    } else {
      Serial.print("failed, rc=");
      Serial.print(client.state());
      Serial.println(" try again in 5 seconds");
      // Wait 5 seconds before retrying
      delay(5000);
    }
  }
}

void publisher() {
  long now = millis();
  if (now - lastMsg > 500) {
    lastMsg = now;
    long distance=sample();
    ++value;
    //String payload = "{\"dist\" : ";
    // payload += distance;
    //payload += "}";
    snprintf (msg, 75, "%ld", distance);
    Serial.print("Publish message: ");
    Serial.println(msg);
    mqtt.publish("sonar/distance", msg);
  }
}


void topic1_subscriber(String topic, String payload) {
  Serial.println(s+"Message arrived in function 1 ["+topic+"] "+payload);
  if ((char)payload[0] == 'F') 
  {
    leftForward();
  } 
  else if ((char)payload[0] == 'S') 
  {
    leftStop();
  } 
  else
  {
    leftReverse();
  }
}
void topic2_subscriber(String topic, String payload) {
  Serial.println(s+"Message arrived in function 2 ["+topic+"] "+payload);
  if ((char)payload[0] == 'F') 
  {
    rightForward();
  } 
  else if ((char)payload[0] == 'S') 
  {
    rightStop();
  } 
  else  
  {
    rightReverse();
  }
}

void loop() 
{
  client.loop();
  threadControl.run();
  publisher();
}

The publisher reads the sonar distance, send send on the topic "sonar/distance". The inputs are "wheel/Left" and "wheel/Right", values are "F", "S" and "R" for Forward, Stop and Reverse. The robot has no smarts, it just listens for commands, and sends out distance to nearest object in front.

All this information is processed in Node-red. The flow looks like:

Lots of manual controls, mostly individual control of the direction of the wheels. The middle left/right will get both wheels spinning in the same direction or stop. Then the "Bounce Around" function will get the left wheel to turn the car when it gets too close to something. The function looks like:

var d1 = parseInt(msg.payload);var dx = msg.payload;
if (dx < 17) {    msg.payload = "R";} else {    msg.payload = "F";}//msg.payload.dist = msg.payload.dist;
return msg;

If the distance is less than 17 CM, the left wheel goes in reverse. When the distance is greater than 17CM then the wheel will continue going forward. 

It demonstrates when a reliable communications mechanism is there, cloud calculations can be used to do motion controlled systems. 

Obviously for a real autonomous car more sensors would be needed to ensure safe travel. 

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

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.