Sensing temperature using MQTT

I recently built a simple temperature sensor using a NodeMCU (ESP8266) and a DHT22. This reads the temperature and humidity roughly every 30 seconds and pushes the data to a MQTT server so I can handle the data elsewhere.

The NodeMCU wakes up every 30 seconds and connects to my local WiFi network. Once connected it takes a sensor reading and publishes it to my MQTT server. It then delays for a few seconds to ensure the message is sent, then goes into deep sleep.

The deep sleep is a function I wasn’t aware of on the ESP8266 before. It just a case of wiring up D0 to RST and calling ESP.deepsleep() in the code. When the device wakes up, it’s like its been turned on for the first time.

The code and wiring is available on my GitHub

Reading the data from MQTT

As the purpose of the sensor was to just send the data to a MQTT server in a simple format, I needed to write something to listen to the published messages the device was sending.

I was able to do this using a simple NodeRED program to listen to incoming MQTT messages, and send them to debug console, and to a CSV file for later processing.

I added a timestamp and built the CSV line using a mustache template. This is then appended to a CSV file I put in my /tmp directory.

The data looks like this


Using the CSV data

To test the data is being logged correctly, I wrote a simple R script parse the data and plot a diagram from it. As the CSV had no header columns, I had to rename the first column names as read_csv used the first line values by default.


temperatures <- read_csv("temperatures.csv", col_types = cols(`2020-05-07T13:09:17.635Z` = col_datetime()))
temperatures <- rename(temperatures, c("2020-05-07T13:09:17.635Z"="datetime", "29.70"="temperature"))
shedtemperatures <- temperatures %>% select(datetime, temperature) %>% filter(datetime >= as.Date("2020-05-09") & datetime < as.Date("2020-05-10"))
ggplot(data=shedtemperatures, aes(x=datetime, y=temperature, group=1)) geom_line() + ggtitle("Temperature in the Dev Shed")

This gave me the following plot…

The maximum temperature in the shed I placed the sensor in was 33.1C.

Changing an RGB LED from a Mendix app

The Nordic Thingy:52 is a compact multi-sensor prototyping platform. It exposes a variety of configurable sensors and actuators over Bluetooth.

Modern versions of the Google Chrome browser support the Web Bluetooth API. This means we can write JavaScript that runs in a web browser to talk to Bluetooth devices. We can use this to get Chrome to talk to a Nordic Thingy:52.

The guys at Timeseries created a quick primer on How to get started with IoT using Mendix. Willem Van Zantvoort also gave a webinar that included using a Nordic Thingy:52. This demo only showed how to read data, not write.

Timeseries have released the Bluetooth (BLE) Connector module to the Mendix App Store. This allows developers to connect and write to Bluetooth devices from a Mendix app. These are exposed as JavaScript actions.

If we want to change the colour of the Nordic Thingy:52’s LED, how do we do this from a Mendix app?

We can use the DeviceConnect JavaScript Action in a Nanoflow to connect to a Nordic Thingy:52. The Bluetooth (BLE) Connector module doesn’t allow data to be written to a device. We need this functionality to tell the Nordic Thingy:52 what colour we want to the LED to show. So we will need to write our own JavaScript Action to do this.

Create the SetLED JavaScript Action

JavaScript Actions in Mendix are very easy to write. We create a JavaScript Action called SetLED. This needs to take 3 String parameters. A “primaryServiceUUID”, a “characteristicUUID”, and “mycolour”. The “primaryServiceUUID” describes what type of service we want to talk to. The “characteristicUUID” is the specific characteristic, in this case the LED. Finally, “mycolour” is the colour we want to show described as a CSS style rgb string (e.g. “rgb(10, 255, 10)”).

A Mendix JavaScript Action works by using a JavaScript promise to return data to a Nanoflow. Mendix has created a small scaffolded bit of JavaScript for us to change.

The first thing we need to do is to see if Bluetooth is supported. We do this by trying to access the window.gattServer. If it’s not available, we need to reject the Promise.

var gattServer = window.gattServer;
    // Bluetooth available
  } else {
    return Promise.reject("No gatt server found");

Now we need to try to access the LED characteristic on the device. We do this by creating a new Promise within which we get the primary service, then the LED characteristic. At this point we should be able to talk to the device and issue an instruction for the LED.

return new Promise((resolve, reject) => {
    .then( (s) => {
        return s.getCharacteristic( characteristicUUID );
    .then( (c) => {
        characteristic = c;
        return c;
    .then(characteristic => {
        // do something with the LED

The data is sent as binary using the writeValue method of the characteristic. We need to convert our RGB string into binary values before we send this. We can extract the individual values for R, G, and B using a regular expression. We can then insert these into a JavaScript Uint8ClampedArray. The Uint8ClampedArray prevents values under 0 and over 255. This helps us avoid buffer overflows which could cause bugs.

const match = mycolour.match(/rgba?\((\d{1,3}), ?(\d{1,3}), ?(\d{1,3})\)?(?:, ?(\d(?:\.\d?))\))?/);
let buffer = new Uint8ClampedArray(4);
buffer.set([1, match[1], match[2], match[3]], 0);


Our final action should look like this…

 // This file was generated by Mendix Studio Pro.
// WARNING: Only the following code will be retained when actions are regenerated:
// - the code between BEGIN USER CODE and END USER CODE
// Other code you write will be lost the next time you deploy the project.

 * @param {string} primaryServiceUUID
 * @param {string} characteristicUUID
 * @param {string} mycolour
 * @returns {boolean}
function SetLED(primaryServiceUUID, characteristicUUID, mycolour) {
 var gattServer = window.gattServer;
 return new Promise((resolve, reject) => {
            .then( (s) => {
 return s.getCharacteristic( characteristicUUID );
            .then( (c) => {
                characteristic = c;
 return c;
            .then(characteristic => {
 const match = mycolour.match(/rgba?\((\d{1,3}), ?(\d{1,3}), ?(\d{1,3})\)?(?:, ?(\d(?:\.\d?))\))?/);
 let buffer = new Uint8ClampedArray(4);
                buffer.set([1, match[1], match[2], match[3]], 0);

    } else {
 return Promise.reject("No gatt server found");

Now we have our JavaScript action, we can wire it into a Mendix app.

Using the SetLED JavaScript Action

We need to add a non persistable entity to hold our RGB string. We’ll call this “LED”, and add one String attribute “RGBString”.

Add a Data view to the page, and set its data source to the a new Nanoflow called CreateLED. All the Nanoflow needs to do is create an instance of our LED entity.

Mendix have provided an excelled RGB colour picker in the App Store called Color Picker. We can drop this into our Data view setting the Color Attribute field to the RGB string in our new LED entity. Set the Color Format to RGB. In the Appearance Tab set the Picker type to Hue. Now when we use the colour picker, it will save the selected value to our LED entity. That’s great, but we want to actually change the colour on Nordic Thingy:52. To do this, we need to go to Events and On change call a new Nanoflow we’ll call ChangeLED.

ChangeLED needs to first connect to the Nordic Thingy:52. We do this using the DeviceConnect JavaScript action from the Bluetooth (BLE) Connector. This takes a Primary service UUID of ” ef680100-9b35-4933-9b10-52ffa9740042″. It also takes an Optional service UUID of ” ef680300-9b35-4933-9b10-52ffa9740042″. I found these values in the example JavaScript code on Nordic’s GitHub account. When this is called it will trigger a prompt to connect to a Bluetooth device.

Once we are connected, we call our SetLED JavaScript action. The Primary service UUID is ” ef680300-9b35-4933-9b10-52ffa9740042″. This was the value we used as the optional UUID when we connected. For the Characteristic UUID we use the value “ef680301-9b35-4933-9b10-52ffa9740042” for the LED. For Mycolour we use the value in the RGBString attribute in our LED entity.

We can now run the App.

Running the App

The first time the ChangeLED Nanoflow is run it will prompt to connect to a Bluetooth device. This is where we look for our Nordic Thingy:52. Future requests are not prompted for while in the same session.

If we’ve connected to our device the LED should now be changing colour to match the value in the colour picker.

Thingy LED change from a Mendix App


Hopefully this should be enough information to get you connecting to a Bluetooth device and sending data.

If you aren’t using Mendix at the moment it’s free to get started, you just need to signup for a Mendix account.

Using Bluetooth on Windows 10 running in Parallels on a Mac

I was trying to use a Bluetooth device on Windows 10 running in Parallels on a Macbook Pro, but without luck.

Parallels can share its Bluetooth connectivity, but it’s not very reliable.

The solution is to get a Bluetooth USB dongle, and being a Macbook Pro, I also had to get a USB C to USB A adaptor.

I found the Plugable USB-BT4LE USB Bluetooth 4.0 Low Energy Micro Adapter with a Ailun Type C Adapter worked.

Before you plug in the dongle, you need to go into Parallels and stop sharing built in Bluetooth device to your Windows 10 instance.

Now plug the dongle in. You will need to assign the USB device to Windows 10 in Parallels when prompted.

Windows 10 will complain that the device doesn’t work. To fix this download the Windows 10 drivers. Once installed you need to restart Windows 10, but after you do Windows 10 will have a working Bluetooth connection.

Parallels has a habit of sharing the built in Bluetooth service when you restart, so make sure this is disabled if you are having problems.

Using an HC-06 Bluetooth adapter with a ESP8266 NodeMCU.

I’ve been looking at getting a ESP8266 NodeMCU to talk over Bluetooth using an HC-06.

The example will provide a simple way of echoing data from Bluetooth to a serial port.

The HC-06 exposes a serial port that the NodeMCU can use. In this example, I’m going to echo data between a the HC-06 and the serial port connected up to my Mac. As the NodeMCU only supports one serial port in hardware, we need to use Software Serial as well. This provides us a second serial port.

Wiring between the HC-06 and the NodeMCU is as follows

VCC to 3V
TXD to D4
RXD to D3

The code is a variation on the example code provided by Software Serial. We need to set the baud rate to 9600, and specify pins D4 and D3 for RX and TX.

#include <SoftwareSerial.h>

#define BAUD_RATE 9600

SoftwareSerial swSer(D4, D3);

void setup() {

  Serial.println("\nSoftware serial test started");

  for (char ch = ' '; ch <= 'z'; ch++) {


void loop() {
  while (swSer.available() > 0) {
  while (Serial.available() > 0) {


To test this on a Mac, plug it into the serial port, and set the Arduino Serial Monitor to 9600 baud. The message “Software serial test started” should appear.

Go to Bluetooth and add the device. Mine showed up as HC-06. The default pairing code is 1234. Once paired, open a Terminal window and look for the device in /dev/. My device name is /dev/tty.HC-06-SPPDev . Connect to the device by typing

screen /dev/tty.HC-06-SPPDev

The message “ !"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz” should appear.

What you type in one window is now echoed to the other window.

An improved SDS011 connector cable for Airrohr devices

At the Clean Air Eastbourne project we build Airrohr Luftdaten devices.

These use the SDS011 sensor. The official instructions suggest plugging dupont cables directly into the sensor, however we have found these tend to become loose and can be unreliable.

Our solution is to build our own cables.

We buy 7pin 2.54m 6S1P JST-XH cables from AliExpress. These come with wires already attached. We take out the red, black, and yellow wire by pressing down on the connector and gently pulling the wire out the back. This leaves us with the 4 wires we need in the correct slots.

Next we attach female dupont connectors with double housing to the other ends of the wires. One double connector goes on the blue / green pair, and another on the white / orange pair of wires. I used a PA-09 crimping tool from (affiliate link) to make the attachments.

When plugging into the NodeMCU the connections are
White – VU
Orange – Ground
Green – D2
Blue – D1

Building a simple air quality indicator

I demonstrated Using a bicolour LED with an NodeMCU in an earlier blog.

We now extend that code and instead of having a single LED, we have two. One LED will indicate the current levels of PM2.5, and the other LED will indicate the current levels of PM10. To do this we need to connect to the internet and download these levels from the Clean Air Eastbourne API. The API returns a single float as a string with the current value in µg/m3.

The wiring is very similar to the previous blog post, except we include an extra LED connected to D3 and D4 on the NodeMCU.

The code

The NodeMCU has support for WiFi built in thanks to it’s ESP8266 chip, so it’s very easy to go online in our in setup()loop() function we poll for values every 30 seconds. We turn these values into floats and compare our snapshot against the WHO annual guidelines limits, and UK annual legal limits. If we’re below WHO and UK limits, we show green. If we’re above WHO limits, but below UK limits, we show amber. If we’re above both WHO and UK limits, we show red.

#include <ESP8266WiFi.h>
#include <ESP8266HTTPClient.h>

// Wifi connection details
const char* ssid = "Wifi Network";
const char* password = "Wifi Password";

// Poll URLs
const char* PM10_URL = "";
const char* PM25_URL = "";

// How often to poll the website for updates (in microseconds)
const int POLL_DELAY = 30000;

// Limits for particulates from the WHO and UK.
// These are annual limits.
const float WHO_PM10 = 20.0;
const float WHO_PM25 = 10.0;
const float UK_PM10 = 40.0;
const float UK_PM25 = 25.0;

// The TriColour LEDs are wired to the following pins
int redPinPM10 = D2, greenPinPM10 = D1;
int redPinPM25 = D3, greenPinPM25 = D4;

void setup () {
  pinMode(redPinPM10, OUTPUT);
  pinMode(redPinPM25, OUTPUT);
  pinMode(greenPinPM10, OUTPUT);
  pinMode(greenPinPM25, OUTPUT);

  WiFi.begin(ssid, password);

  while (WiFi.status() != WL_CONNECTED) {
    Serial.println("Connecting to Wifi...");


void loop() {

  if (WiFi.status() == WL_CONNECTED) { //Check WiFi connection status

    HTTPClient http;  //Declare an object of class HTTPClient

    Serial.println("Getting PM10 data...");
    http.begin(PM10_URL);  //Specify request destination
    int httpCode = http.GET();                                        //Send the request
    if (httpCode > 0) { //Check the returning code

      String payload = http.getString();   //Get the request response payload
      Serial.println(payload);             //Print the response payload

      int reading = payload.toFloat();

      digitalWrite(redPinPM10, LOW);
      digitalWrite(greenPinPM10, LOW);
      if (reading >= WHO_PM10 && reading < UK_PM10) {  // turn the LED if over WHO limits, but under UK
        Serial.println("Over WHO guidelines ");
        digitalWrite(redPinPM10, HIGH);
        digitalWrite(greenPinPM10, HIGH);
      } else if (reading >= UK_PM10) {                 // turn the LED on if over UK limits
        Serial.println("Over UK limits");
        digitalWrite(redPinPM10, HIGH);
      } else {
        Serial.println("under limit");
        digitalWrite(greenPinPM10, HIGH);
    } else {
      Serial.println("Unable to get data from API");
    http.end();   //Close connection

    Serial.println("Getting PM2.5 data...");
    http.begin(PM25_URL);  //Specify request destination
    httpCode = http.GET();                                            //Send the request
    if (httpCode > 0) { //Check the returning code

      String payload = http.getString();   //Get the request response payload
      Serial.println(payload);             //Print the response payload

      int reading = payload.toFloat();

      digitalWrite(redPinPM25, LOW);
      digitalWrite(greenPinPM25, LOW);
      if (reading >= WHO_PM25 && reading < UK_PM25) {  // turn the LED if over WHO limits, but under UK
        Serial.println("Over WHO guidelines ");
        digitalWrite(redPinPM25, HIGH);
        digitalWrite(greenPinPM25, HIGH);
      } else if (reading >= UK_PM25) {                 // turn the LED on if over UK limts
        Serial.println("Over UK limits");
        digitalWrite(redPinPM25, HIGH);
      } else {
        Serial.println("under limit");
        digitalWrite(greenPinPM25, HIGH);
    } else {
      Serial.println("Unable to get data from API");
    http.end();   //Close connection

  } else {
    Serial.println("Not connected to Wifi");

  delay(POLL_DELAY);    // wait before we poll again.

Using a bicolour LED with a NodeMCU

This is a quick example on how to use a bicolour LED with a NodeMCU.

The bicolour LED has both red and green LEDs in a single package. There is a common cathode for both the red and green anodes. Applying a current to the red anode turns the red LED on. A current to green anode turns the green LED on. A current to both anodes creates yellow.

The circuit is very simple. We wire the red anode to D1 on the NodeMCU, the green anode to D2, protecting them both with a 220ohm resistor. The cathode is wired to ground.

Linking a bicolour LED to a NodeMCU

We program the NodeMCU using an Arduino sketch.

int redPin = D1, greenPin = D2;

void setup() {
  // set the pins to output mode
  pinMode(redPin, OUTPUT); 
  pinMode(greenPin, OUTPUT);

void loop() {
  // red
  digitalWrite(redPin, HIGH); delay(500);
  // yellow
  digitalWrite(greenPin, HIGH); delay(500);
  // green
  digitalWrite(redPin, LOW); delay(500);
  // off
  digitalWrite(greenPin, LOW); delay(500);

In the setup, we set D1 and D2 to both be outputs. We then turn D1 and D2 on and off in sequence every half a second to achieve a sequence of red, yellow, green, and off.

Running a SDS011 particulate sensor on a Mac using PHP

The Novafit SDS011 particulate sensor is an a very affordable sensor for detecting particulate pollution. It is capable of detecting both PM2.5 and PM10 with a relative error margin of +/- 10µg/m3.

It can output data via it’s serial port. The one I bought came with a serial to USB adaptor, allowing it to be plugged into my Mac. It did need a driver, and I used ch340g-ch34g-ch34x-mac-os-x-driver.

Data is sent at 9600 baud, with 8 data bits, no parity bit, and 1 stop bit. 10 bytes are sent at a time.

Byte Name Content
0 Message Header AA
1 Commander No C0
2 DATA 1 PM2.5 Low byte
3 DATA 2 PM2.5 High byte
4 DATA 3 PM10 Low byte
5 DATA 4 PM10 High byte
6 DATA 5 ID byte 1
7 DATA 6 ID byte 2
8 Check-sum DATA 1+DATA 2+..+DATA 6
9 Message tail AB

PM2.5 (μg /m3) = ((PM2.5 High byte *256) + PM2.5 low byte)/10
PM10 (μg /m3) = ((PM10 high byte*256) + PM10 low byte)/10

We can read this using PHP. The following PHP script can be run on the command line and outputs the PM2.5 and PM10 levels every 2 seconds to a terminal window.

exec('stty -f /dev/cu.wchusbserial1420 9600 raw');
while (true) {
    $handle = @fopen( '/dev/cu.wchusbserial1420', 'r' ); # Open device for Read access
    if ($handle) {
        $binarydata = fread( $handle, 10 ); # Read data from device
        $data = unpack('H2header/H2commander/vpm25/vpm10/Sid/H2checksum/H2tail', $binarydata);
        echo sprintf("PM2.5: %dµg/m³\nPM10:  %dµg/m³\n", $data['pm25']/10, $data['pm10']/10);
        fclose ($handle); # Close device file
    } else {
        echo "Unable to connect to pollution sensor\n";

The device is used by reading the 10 bytes it returns each message from the USB device. We can use PHP’s unpack function to break the binary data returned into an associative array for ease of use. We do have to do divide the PM2.5 and PM10 results by 10 to get their real values though. This can then be echo’d to the terminal.

NodeMCU WiFi setup

NodeMCU devices have WiFi built in, and it’s easy to configure using Lua.

One of the easiest examples of setting this up was on Limpkin’s blog. I took this and tweaked it slightly so it works with the more recent Lua wifi module.

station_cfg.ssid="Rob's iPhone"
station_cfg.pwd="secret password"
tmr.alarm(1, 1000, 1, function()
    if wifi.sta.getip() == nil then
        print("IP unavailable, Waiting...")
        print("ESP8266 mode is: " .. wifi.getmode())
        print("The module MAC address is: " .. wifi.ap.getmac())
        print("Config done, IP is "..wifi.sta.getip())

Upload this using luatool or similar as the init.lua file that runs when the NodeMCU powers up.

In this example, the script tries to connect to my iPhone hotspot. We use tmr.alarm to check once a second if we have an IP address. If we don’t, we let the user know. If we do, we stop the timer from continually executing, and print out some of our wifi configuration details.

It’s at this point we could start using the connection to talk to the internet if we needed to.

Using an i2c 128×64 OLED display with Lua on a NodeMCU

Small 128×64 OLED i2c displays can picked up for just over £3 on Amazon, and they are great for interfacing with a NodeMCU IoT device.

Wiring is simple…

  • NodeMCU 3.3v – OLED VCC
  • NodeMCU D1 – OLED SDA
  • NodeMCU D2 – OLED SCL or SCK

Wiring an i2c OLED display to a NodeMCU

Your NodeMCU firmware must have been compiled with the i2c and u8g modules included. If you need to add these, see my previous post – NodeMCU Lua setup using a Mac. It also explains how to upload the example Lua code below.

The u8g module comes with some great examples. I’ve taken some of the relevant parts for a simple two page Lua script that prints out two alternating screens of text.

sda = 1 -- SDA Pin
scl = 2 -- SCL Pin

function init_display(sda,scl) --Set up the u8glib lib
     sla = 0x3C
     i2c.setup(0, sda, scl, i2c.SLOW)
     disp = u8g.ssd1306_128x64_i2c(sla)

function updateDisplay(func)
  -- Draws one page and schedules the next page, if there is one
  local function drawPages()
    if (disp:nextPage() == true) then
  -- Restart the draw loop and start drawing pages

function drawScreen1()
     disp:drawStr(5, 20, "")
     disp:drawStr(5, 35, "    @robertprice")

function drawScreen2()
     disp:drawStr(5, 20, "  NodeMCU OLED Test")
     disp:drawStr(5, 35, "   12th July 2017")

local drawDemo = { drawScreen1, drawScreen2 }

function demoLoop()
  -- Start the draw loop with one of the demo functions
  local f = table.remove(drawDemo,1)

tmr.alarm(4, 5000, 1, demoLoop)

This may look a bit complex for just displaying text, but it aims to be reusable. We use the tmr.alarm to avoid bogging the CPU down in a loop.

NodeMCU driving an i2c OLED display

I’ve tried this with two different i2c OLED displays, and they both work.