Starting Home Automation

What does this have to do with an engine monitor?

Sensors!

Somewhere along about Nick O’Leary and Dave Conway-Jones of IBM’s Emerging Technology Services group had a side project where they came up with what we now call Node-Red. Before that (1999) there were two other engineers Andy Stanford-Clark (IBM) and Arlen Nipper (Eurotech) who wanted a way to monitor oil pipelines and came up with MQTT.

MQTT is a lightweight protocol for delivering messages from sensors to a server. The protocol is direction agnostic, allowing the server to send messages to the sensors as well. The messages provide multiple levels of Quality of Service (QoS) such that the messages can be reliable or unreliable depending on the application.

You've heard of IOT, and that is pretty boring, or not, and seems that people are excited about it or not. I was for a long time too, but then I started playing with things. I've been using ESP8266 systems for a couple years now. They are all that an Arduino can be, plus they support WiFi and other protocols. The ESP8266's can be programmed using the Arduino IDE, so that makes the very friendly to hobbiests and others. It is easy to come up with a quick project, and knock something out very quickly.

I'd been working on a bunch of sensors and control panels around the house just standalone, when I had a job where I was introduced to Node-Red, and saw the potential. I moved one of my projects from standalone to Node-Red and demonstrated that standalone was not the best way. Using Node-Red I can integrate sensors and control panels in varying ways, allowing easier updates, and more capabilities.

MQTT basics

The heart of the system is MQTT. Generally MQTT has "clients" around the edges, and a central "agent" or server. For open source projects, the easiest agent to work with is Mosquito since it runs on Windows or Linux systems equally easy. There are utilities included with Mosquito allowing monitoring and control without any other GUIs or anything.

MQTT is a publish/subscribe (pub/sub) protocol. Anyone can publish a message on any topic, but only the subscribers to that topic will receive the message. Mosquito is the arbiter of the messages. Mosquito will receive all the messages, but only send them on the the appropriate receivers.

A simple sensor can send a message, and the MQTT agent receive the message and make the message available to anyone registered on that topic. If a temperature sensor broadcasts a new reading, the door monitoring devices don't need to know about it. Likewise if the door open message is sent, the water sensing system doesn't need to know about it. Or maybe they do need some additional information, it all can be programmed later.

Node-Red teaser

Node-Red allows programming flows. A flow connects several inputs on various topics to any outputs based on a need to know.

The green "connected" boxes on the left are input MQTT nodes connected to an MQTT agent. The output of those boxes go into various other boxes. The green "msg.payload" boxes are there for debugging. The blue boxes are outputs to a User Interface (UI) and the The green "connected" boxes below are MQTT outputs nodes connected to an MQTT agent. 

This flow is looking at the sensors on the garage doors to know the current state (open/closed). They both feed the message into a door open alarm node. This node has some programming associated with it (something for a future post). If the doors are open during the night, an MQTT output node that has an ESP8266 and a sounder is in my bedroom that should wake me up. It isn't physically connected, it only is a WiFi device. 

I did something, else on the input ESP8266, not just the magnetic reed sensors. I also added a DS18b20 sensor that was to let me keep track of the outside temperature. The 18B20 works in Celsius, but I only think in Fahrenheit so I have a node here that converts the temperature from C to F. 

This code is fairly straight forward, and as you see, uses JavaScript as the language. The message came with a payload that contained a number. That number was multiplied by 9 divided by 5 and added to 32. The results was made to be the payload of the resultant message. The result message goes both to the debug output (msg.payload) and a new MQTT message on a new topic. 

I'll detail more of this in future blog posts. Come back soon. 

Data Comm Tools We Need

I spent the last week on a business trip, and managed to go most of the week without WiFi. The airplane I flew on didn't have WiFi, and while in the car I didn't have it either. I was staying at a 5 star hotel for 4 nights, and had only marginal coverage, at $13 a night. I ended up using my mobile hot spot on my phone and burned through over half my monthly allotment LTE internet in 4 days. I learned how much I rely on data connections.

Several years ago, probably 1998 or so, my wife and I were at Oshkosh, and walked by the Iridium booth. The Iridium sales person offered us a free phone call to see how great their products are, and maybe we could use them in our airplane. This was before my wife or I had a cell phone, and we wanted to check in on the kids. After three or 4 failures, we never got to talk to the kids, and we walked away unimpressed.

About a week ago, the Airplane Geeks had the president of Iridium on the show and allowed him to hawk his products.He presented a new product that sounds like something pilots can use in the plane, and maybe other times as well. The Iridium Go looks to be the perfect implementation of the Iridium network for us.

The Iridium Go is a WiFi hotspot that will work anywhere in the world, at almost any altitude. This is the opportunity to make a tablet and phone work anywhere all the time. When in the air, the tablet can get all the data updates desired, along with making VOIP phone calls on the phone. The Go also has tracking and other useful features built in.

I know FIS-B and TIS-B should have much of the datalink covered, there are some things it won't have covered. Items like downloading whole graphical charts while in the air, or additional weather information will not be available over FIS-B.  TIS-B and FIS-B aren't available outside the CONUS either, operations there will benefit from additional datalinks.

Airlines have the ability to use Iridium datalink today, and the ICAO flight plan has a capability letter reserved for CPDLC using Iridium (J7 CPDLC FANS 1/A SATCOM (Iridium)) in Item 10. To put Iridium radios in commercial aircraft is a very expensive aftermarket event. Using the Iridium Go for non-safety of flight purposes is a much smaller cost (More than an order of magnitude!).

The price is around $600 for the GO, and while that sounds high, consider the cost of a typical smart phone is in a similar ballpark (off contract). One might guess if these devices become quite popular, the price may come down.

For tooling around in your Taylorcraft, this might be overkill, but I could see it becoming almost an expected item on a Citation, or King Air. People rely on data communications a bit more in the 21st century.

(Iridium hasn't talked to me at all, I saw this and thought this is  great product!)