Building the Monitair Configuration Page

The new configuration web page for the Monitair sensor is taking shape. Above you can see the “home page” that the sensor displays during setup. Rather than having one enormous page of settings we now have links to sub-pages which contain different setting categories. The page is generated from a data structure so that it is very easy to add new settings.

These are the simple settings for the device. You can leave everything else at the default values and the sensor will just work on the Connected Humber MQTT broker. The only things you really need are WiFi connection details and the MQTT password. If you happen to know your location details you can put them into the form so that the sensor readings can be displayed on the map. When you click Update the settings are written into EEPROM on the device. You can use the advanced configuration pages to select things like the hardware pins that various peripheral devices are connected to. I’m rather enjoying writing this…

Cottingham Parish Council

After an awesome hardware meetup at c4di tonight Robin and I went on to a meeting of Cottingham Parish Council. We were there to talk about Air Quality, something we are quite passionate about - what with us having done quite a lot of breathing over the years.

As it happened they were discussing an air quality issue just before we were introduced, which gave us a lovely context in which to describe the work of the Connected Humber Group on designing, making and deploying sensors around the area.

Everyone was very interested and I it looks like we’ll be working together in the future on this, which is lovely.

Air Quality on the radio

The coloured fountains in Hull city centre look lovely.

Every now and then I get to do the newspaper review for the Radio Humberside breakfast show. It means getting up at stupid o’clock in the morning but it is rather fun. We talked about a bunch of things, including Air Quality, which was actually in the news today. Apparently the air in London Underground tunnels contains dangerously high levels of particulates (just the things we are measuring with the sensors that we are building at Connected Humber). According to the standards that we’ve been using, things get unhealthy when an indicator value we are measuring goes above 60 or so. The values they are seeing in the deepest stations are around 450….

The bit that took my breath away (really) was that someone actually said something like “Although the levels are high, it doesn’t matter because people don’t spend a lot of time on the tube”. Unless, of course you happen to drive a train or work in the station…..

Heltec Lora 32 on Fritzing

I spent a big chunk of yesterday trying to create a Heltec Lora 32 part for the Fritzing design program. In the process I learned quite a bit about SVG files, Inkscape and pcb design. So I don’t think it was a complete waste of time….

Tomorrow I’m going to try and figure out how to add my newly created part to the Fritzing parts library. Then I’m going to make Fritzing parts for the sensors that I’m using and then I can draw some lovely circuit diagrams.

Creating a WiFi Configuration Tool

One of the problems with any WiFi enabled device is the initial configuration. How do you tell your device the settings for your WiFi when you can’t talk to it via WiFi? It’s a “chicken and egg” situation, even though it doesn’t involve any chickens or eggs.

One answer is to make your device set up as a WiFi access point of its own, and then connect to this from a WiFi enabled phone or computer to configure all the settings. There are quite a few libraries of routines out there that will help you do this, but none of them did exactly what I wanted, so I’ve built my own.

You can see the configuration screen it generates in the screenshot above. You connect to it via your browser and then fill in the various options. It has support for five different access points and also lets you configure all the MQTT settings for a sensor as well.

I’ve got it working with my MQTT Mini Air Quality sensor. To configure the WiFi you simply turn the sensor upside down, plug it in and it starts up in “configure” mode. You then connect to the access point and perform the configuration. Then flip the sensor the right way up, restart it and away you go.

I’m very pleased with how well it works. I’ll have the code for the new, super configurable MQTT Mini device on GitHub before the end of the week. Then I’ll port the configuration mechanism over to larger, ESP32 based sensor.

Great fun.

Using the Second Serial Port on the Azure IoT Devkit

For some time I’ve been trying to create an Air Quality Sensor using the Azure IoT Developer Kit. It’s a nice little device that has a bunch of environmental sensors, a nice OLED screen and a couple of buttons. It is also properly secure, in that it contains secure storage and you can validate access using X500 certificates.

I like it a lot, but I’ve not been able to use it for air quality work as I couldn’t get the second serial port to work on it. This is important because the air quality sensors that we are using deliver their readings over a serial connection. I’ve tried doing what the documentation says to do but it just didn’t work.

I posted a question about this on the GitHub repository for the kit and got a response indicating that what I was doing should just work.

But it didn’t.

So I had a proper look in the code in the device SDK. After a bit of digging I discovered that two of the source files are missing statements that make the second serial port available to Arduino programs. The file Variant.cpp needs the statement:

UARTClass Serial1(UART_1);

..and the file Variant.h needs the statement:

extern UARTClass Serial1;

Then it does work. I’ve tested it and everything. The picture above shows my cunning test rig, using a USB to serial adaptor that I wired to the devkit. If you’re connecting the device using a MicroBit connector you will find that pin 1 is TXD and pin 2 is RXD.

I’ve put the changes into a fork of the devkit sdk that you can find here. I’ve also told the developer team about my fix, so that it should appear in the “proper” version soon. I’m very pleased to be able to contribute a tiny bit to the development of the device. I feel like a grown up programmer…..

The only problem I have left to solve is that my Air Quality sensor needs a 5 volt power supply. While the USB connector on the Developer Kit board receives this from the host device the power connection is not surfaced anywhere on the board. I can see why this is: you wouldn’t want people inadvertently sending 5 volt signals into the input pins, but it means that my wiring is going to have to be a bit more complicated than it might be.

Anyhoo, I can now start porting my Air Quality Sensor code into the Devkit, which is nice. I’m also going to make a little box for it too.

Air Quality Designs and Software now on GitHub

If you woke up with an urge to create an Air Quality sensor out of either a Heltec or a Wemo device then I’ve got good news for you. You can download all my software and hardware designs from here. You can make sensors that use LoRa in OTAA or APB (these will make sense if you know LoRa or go to my talk later this month). You can also use MQTT to talk to Azure IOT Hub or another MQTT broker including Mosquitto.

All configuration is performed using JSON messages that can be sent via the serial port or over the air. It is very easy to configure a device, no need to re-burn the software each time you want to deploy another sensor with a different name and network configuration.

I call this a “shirk in progress” release, in that I’ve been too lazy to release any new versions for a while. However, I'm now using this as my main development repository and so you can expect updates, including more detailed documentation, over time.

Using an Azure Function to receive MQTT Messages

The video shows me pressing a button on my Air Quality sensor to trigger the sensor to send a new reading via MQTT. The action then switches to the output of an Azure Function running on my PC which is responding to this. I’m very pleased with this.

MQTT (Message Queuing Telemetry Transport) is a neat way to connect embedded devices together. I’ve used it to talk to the Hull Pixelbot devices over the internet using Azure IOT Hub. Using MQTT in this way has meant that my server applications can send commands to the robots to tell them what to do, and also receive messages back.

Creating a server application is all very well, but it is a bit too much like hard work for me when I’m writing code for the Air Quality sensors. In that situation I don’t really want to have a server application sitting in the cloud twiddling its digital thumbs while it is waiting for incoming messages.

What I really want is a way of connecting a lump of code (ideally a C# method) to the event “Hey out there. I’ve got a new Air Quality Reading”. It turns out that Azure Functions just do this. You deploy the function into the cloud and bind it to the Azure IOT Hub and the endpoint that you want it to listen to. And then, whenever your remote node (which could be anywhere in the world) wants to send a message it posts an MQTT update and your function runs.

This is my function at the moment:

[FunctionName("SensorMQTTReceiver")]
public static void Run([IoTHubTrigger("devices/#",
Connection = "IoTHubConnectionString")]EventData message, ILogger log)
{
    log.LogInformation(
$"C# IoT Hub message: {Encoding.UTF8.GetString(message.Body.Array)}"
}

I stole most of how to do this from a very useful howto here. The next thing to do is add some code to the function that puts the data values from the post into a data store and perhaps add handling of alerts if we see air quality values which are out of range.

The next thing to do is build a similar mechanism to process LoRa updates sent via the things network.

PCB Design at the Connected Humber Hardware Group Meetup

Thanks to Robin for the picture

We had another great session at the Connected Humber Hardware Group tonight. Paul was telling us how to design our own printed circuit boards and get them made up. This is now so cheap that every electronics hobbyist should be getting their own custom boards made up. It turns out that it is all a matter of workflow, in that the sequence in which you put the design together is the important part. Unfortunately I was helping out with a recalcitrant LCD panel during this bit, so I’ll have to ask the other members to help me along when I start making my own circuits.

I want to make at least four, one for the fully featured Air Quality sensor, one for the “Mini MQTT” sensor, another for the Hull Pixelbot dual brain version and a final one as a badge which I think will look cool.

We’ll be continuing our exploration of PCB design at later meetups. They are free to attend, great fun, and take place on the first and third Thursday of each month at c4di in Hull. You can just turn up on the day (as a bunch of people did tonight) but you can also sign up for notification of upcoming events here.

Talking LoRa and Air Quality Sensors at Hull University on 28th November

Air Quality sensors inside and outside the box

I’m presenting a session at Hull University about low powered radio networks and air quality sensors in a couple of weeks. I’ve just written the description:

"LoRa is a low powered, long range radio networking technology with the potential to open up new embedded applications. It makes it easy and cheap to create connected devices. Rob Miles will explain how LoRa works, what makes it particularly interesting and why you should start working with it. He will show how the Connected Humber group are using LoRa to move Air Quality data from sensor to server, and how you can create your own LoRa devices very easily."

It sounds rather interesting. I’m definitely going to go along.

Mini Air Quality Sensor Now Working

I spent quite a bit of today getting my tiny air quality sensor working. I’ve ported the code for the full fat sensor over, so that it has full MQTT setting control and all the other trimmings. It seems to work OK. I’ve mounted the pixel ring up against the 3D printed case and the result is rather impressive, and really hard to photograph.

The biggest problem that I have is that my “artistic” back, which contains programatically generated vent holes, doesn’t seem to let in enough air (or the air inside just circulates). I’m going to have to re-design that part. I’m toying with adding a little fan to get some forced ventilation. I’ll put all the code and the hardware design files on Github when they’re finished.

Making a Mini Air Quality Sensor

I’ve got the large, “full fat” Air Quality sensor just about working. But the hardware cost of the device is a bit on the high side. So today I’ve spent the day grappling with FreeCAD to try a design a much smaller, WiFi only, device. This uses a cheap Wemos D1 Mini and a five pound air quality sensor and a pixel ring. The cost of this hardware is only around ten pounds, which makes it much cheaper to build.

I’m using a new construction technique where the components are mounted on a tray which is then fitted into the box. This removes the need to connect things together inside the box, which helps. To make this work I’ve created a design for a Wemos D1 mini “blank” which can be cut out of the tray. This seems to work quite well. I’ve made another blank for the pixel ring.

I’ve used random numbers to design the vent holes in the back panel. I love using software to create physical objects. Tomorrow I’ll print the components and start building up the circuit.

Using Three Serial Ports with the Heltec LoRa 32

Prototype and “floral” version

I’m making pretty good progress with the Air Quality sensor. I’ve now got a command protocol running between the devices and MQTT or LoRa. As you can see above, I now have the ability to customise the splash screen. Which is very useful if you like cheese.

Anyhoo, I’ve decided that the sensor really needs GPS so that each air quality reading can be tagged with location. I can configure fixed latitude and longitude values into the device, but for real portable usefulness we need it to be location aware.

Getting a GPS device wasn’t a problem, I had one lying around. But connecting it to the Heltec processor that I’m using was more tricky. I’ve got one serial port I want to use as a connection to the host computer and another that I’m using to connect to dust particle sensor. But now I need a third connection for the GPS receiver.

After some rather unsuccessful fiddling with different kinds of software serial connections I decided that it was best to go back to first principles and see if the hardware had anything to offer.

It turns out that it does. The ESP32 chip that the Heletc uses actually contains three serial ports. The problem is that they are not always connected to pins that you can access easily. But the good news is that the ESP32 chip is capable of mapping functions to pretty much any pin and the Heltec libraries take advantage of this. You can map the transmit and receive functions of a serial port when you open it:

HardwareSerial GPS_Serial(2);
GPS_Serial.begin(9600, SERIAL_8N1, 13, -1);

The first statement creates a hardware serial port. The second sets it to receive from pin 13. I don’t really want to transmit anything to my GPS device at the moment (I’m a bit short of spare pins to be honest) and so I’ve set the TX pin to number -1 which means “Don’t use this port for transmit”.

It works a treat. And thanks to this fantastic library I’m now tagging sensor readings with location. The next thing to do is re-design the case to take the GPS sensor and print another flower for the top.

Looong Day

Being up town at 7:00 am does have it’s compensations….

Today was a looong day. Headed out of the house at 6:30 am to review some newspapers for the BBC Radio Humberside Breakfast show and got back home at 8:45 pm after a Hardware Meetup at c4di. In between I did some software development on the Air Quality sensor which can now talk LoRa, MQTT and seems to work. I make that that a 14 hour working day, and it was wonderful. And to think I don’t have a “proper job”.

We had a splendid turnout at the hardware meetup, we’ve got people getting started with Arduino devices and learning how to code for them .Tonight we made an “accidental reaction timer game” and discovered how to store music in a C++ program. Who knows what we’ll come up with next time. We’ve got others entering into earnest discussions about sensors, Stephenson’s Screens and software services. And that’s just the things that begin with s.

If you want to come along and see what we’re up to next time, we’ll be at c4di at 6:00 pm on Thursday 1st of November. Find out more here.

Talking MQTT

Ha! Today has been a good day. I’ve got my Air Quality sensor talking MQTT to the Connected Humber server and sending messages. This has been a bit of an adventure, mainly because I had to mess around with the libraries for the Heltec device that I’m using.

Anyhoo, I’m now sending messages over both LoRa and MQTT at the same time. Go me. Now I just need to add some configuration options and I think we might actually have a product here.

Incidentally, I’m using a Windows app called MQTTBox to view the messages on the server and post test messages to my sensor. Works rather nicely. And free.

Air Quality Sensor Version 1.0

If you think that all I've done over the last week is work on my Air Quality sensor you'd be wrong. But I have been quite busy with it. I've now got a proper menu system with messages and numeric input. Plus a box. The box has been particularly fun to design, especially as the Heltec micro controller, in common with lots of similar devices, doesn't seem to provide any way that it can be fitted into a case. I've ended up making a little clamp that holds it in position. I'm not happy with this, but then again I'm not crazy about my looks either - but what are you going to do? 

To say that the case is printed version 1.0 it has gone together quite well. I'm using the "dead cockroach" assembly technique, where you regard the chip as a dead cockroach lying on its back and connect the wires to the upturned legs. There are no components other than the devices that I'm wiring together. The only tricky bit is that the clock and the temperature sensor share the same SDA and SCL lines and so I've had to make up some custom cables. But it's all working, and now I have a box with all my sensors and whatnot that I can start to to build software for. 

This is the ugly truth about what's in the box. We'll gloss over the way that the wires for the RTC are too short to allow it to be fitted onto its mounting post, and the wire for the sensor is far too long......

The next step is to add a "WiFi Setup" mode that can be used to get the device onto the internet and then we can start pushing readings into the cloud. You can track the project on GitHub here. Bear in mind that this is a work in progress, and so nothing is fixed. This is all part of the Connected Humber Monitaire project, you can find out more here