Intro to MQTT

In the previous post, I talked about how MQTT came about. In this post I will talk a little about what it is but mostly how to use it.

As a publish/subscribe (pub/sub) architecture, the nodes collect data or do actions, using a network connection. In the middle is a server or agent that will allow the nodes to only have a single connection. All the nodes connect to the server, and send or receive data with that one server. The server contains the smarts about who will receive any messages sent to it. Nodes are clients in the TCP/IP nomenclature. The MQTT agent is the server.

There is a normal TCP/IP connection protocol, where a server is listening for clients to connect. The Server will accept connections, and handle multiple clients communication. The details I won't go into, but you can read about it.

As a node connects, it may register certain topics that it will listen to. When the node connects, it must inform the server what message topics it will subscribe to. The server will make a list of these devices that are subscribed to the various topics.

Nodes may send messages on any topic, but only to the server. The server will repeat the message to each node subscribed to the topic. An example would be if a node was to send a message on the topic "outside/temperature" with a payload of 52 to the server, and there were 3 nodes subscribed to this topic, then the server would send a unique message with the topic "outside/temperature" and a payload of 52 to each of the three nodes subscribed.

A single node may subscribe to any number of topics, and send to multiple other topics. The payload of the messages sent is 65535 bytes. MQTT payloads are mostly free format, and can be single values or json formatted. Messages can be commands to set, or status of a node.

 The free format nature of the MQTT Nodes, message and topics can be a challenge for interoperability. All my nodes work the way they do for me, but your nodes may work differently. If you have a node that says it is a temperature sensor, how do I know what it is measuring the temperature of? There is a proposed standard called "Homie" to address most of the confusion.

Typically an MQTT setup will have a machine dedicated to be the MQTT agent. This machine must be running all the time, and ready to act on MQTT messages. There is no connection necessary to the cloud or any outside systems. Connecting to the cloud may be something you want to do for a particular application, or to relay some information out to a remote monitoring and control system.

Dedicating a whole Windows system is probably overkill, unless there is a great deal of processing needed on the received messages. Normally the MQTT server will just pass the messages along to the required recipients. For my home control system I am using a RaspberryPi 3B running Raspian, and I am using the mosquito MQTT server. Using apt-get, from the normal Raspian repository, MQTT can be installed.

For most of the nodes, I am using ESP8266 or ESP32 boards. These boards can be purchased locally for about $15 or mail order for $3-10. I typically need to add sensors and output to these boards so I do a little customization before deploying them. The MQTT libraries are in the normal Arduino library UI. I do all the programming in the Arduino IDE, I am not pushing the limits of anything, and just trying to make a simple reliable system.

The ESP32 and ESP8266 come in various formats. The various formats make adding peripherals convenient and mounting the devices as easy or complex as the box I put it in. I have a 3D printer, so I am able to package up the nodes in pleasant looking boxes.

In future posts, I start building nodes.

Getting Back at It

I've finished my other Android app. It is non- aviation related, and it doesn't use an Arduino, but it proves my skill as an Android developer (or not). It may be in the Playstore real soon now. The weather is warming, and I can get at the plane in the hangar, so I am going at least make an effort to move forward with the engine monitor project.

I've been playing with the Android PFD that I really like. The  A-EFIS is really nice, and I can see this as the primary display I use going forward. Long term, before I would fly any tablet in IFR conditions, I would like a AHRS system bolted to the aircraft, and connected to the tablet. This app is good enough for daily use otherwise using only the tablet gyros. I tested this while flying on a commercial flight (I wouldn't want to test and document while flying solo in GA). 

It is time to replace the engine instruments with an Android app. I have the skills, and proved that I can get the data, I just need to put it all together. So I will document my design with this post, and move on to actually finishing it, showing my test results. I look forward to your feedback, and want to know your thoughts.

I am trying to use best practices, so I will try to use modern technology, and communications. It will still use the Arduino, since that platform is reliable and well documented.

Using the 3 layer design Model, View Controller (MVC) pattern, I will use the Arduino output as the Model, the Android display as the View and the logic to monitor and log the data as the controller. There may be redundant logging on both the Arduino and the Android. The Arduino will be attached to the aircraft, and have the aircraft data. The Android will be removable, and allow interpretation and modeling at remote locations.

The Arduino will read all the raw values from the sensors, and convert those values to actual real numbers. The actual message will contain units, so the numbers have a context.

The output from the Arduino will be in JSON format, allowing different platforms to use the information.  Someday someone may want to replace the Android display with another platform, and that will be possible using this design. The message will be sent from the Arduino about once a second, but can come more often.  A sample message will be similar to:

{"engineParams":
     ["CHTS":[
        "Cyl1": "340F", "Cyl2": "341F", "Cyl3":"348F", "Cyl4":"333F" ],
      "EGTS":[
        "Cyl1":"1530F", "Cyl2":"1520F", "Cyl3":"1550F", "Cyl4":"1545F" ],
      "RPM": 2330,
      "OilPress": "50lb",
      "OilTemp": "220F",
      "FuelPress":"25lb",
      "Volts" : 14.2,
      "Amps" : +12.3,
      "ManifoldPress", "32.29InHg",
      "Timestamp", "2142325533.5sec"]}


The Android will use this information to display graphically the current engine situation. The Android will be able to interpret these values and display the data in other units, set monitoring points with alarms, and other alerting mechanisms. Logging will try to be as similar to the Insight engine monitoring data formats (CSV), allowing existing analysis tools to utilize this data, and make common sense results.

Some of the alerts will include:

• Low oil pressure
• High CHT
• High oil temprature
• Low voltage
• Low charge (amps)

As well as others can be programmed in.  Blinking displays and audible alerts are possible, and a combination will be used. The audio output from the Android device can be routed to most audio panels. The Android device may allow playing music, podcasts  and other entertainment functions along with the alerting functions.

Using the JSON input format can allow debugging and testing on a desktop computer. Creating or using recorded data can allow playback to the Android device. The Android emulator included with the ADK is very good, and allows devices of all types to be used, to insure the display will work. I can start working on the Android code without having a functioning Arduino device working.

I welcome your input