… a marriage of $10 components, IoT and Enterprise Software
A few years ago i’d been given a handful of BBC Micro:bit boards and they’d been sat around in my parts box not doing much. I had put them away due to the lack of any form of WiFi connectivity onboard meant they where soon overlooked for any IoT projects.
I’d completely forgotten about these BBC Micro:bit boards until I stumbled across them searching for a spare ESP8266 for another tinkering project.
Cool I thought, let’s see how quickly I can get this Micro:bit hooked up and sending data over MQTT.
Physically hooking up the BBC Micro:bit and ESP8266 is very easy, both devices are 3.3v with the BBC Micro:bit supplying enough current to drive the ESP8266 via breakout power pins.
The plan was to drive data through the Micro:bit serial IO port and have the ESP8266 bridge the serial transmitted data from the Micro:bit over WiFi to a MQTT broker.
The ESP8266 in question is an Adafruit Huzzah ESP8266. With the ESP8266 it’s possible to use software serial that allows me to configure a GPIO line to support serial data transmission. An annoying feature of this particular board is the hardware UART onboard is wired directly to the micro usb connector meaning switching to using software serial mode.
Serial communication on the Micro:bit is very simple to achieve; you set your RX, TX and Baud Rate and then you’re free to squirt any string down the wire.
For the demo, i’d read the onboard temperature and emit it as a simple JSON formatted string over serial. Having to use the software serial mode on the ESP8266 meant keeping the baud rate down to manageable levels so 1200 was chosen.
The micro:bit IDE lets you develop using either ‘Scratch’-like no-code GUI blocks or Javascript. Microsoft did a very good job with this tool considering their target audience are school children.
The code is simple, first we setup serial to redirect Pin 0 for TX and Pin 1 for RX with a baud rate of 1200; then in our main processing loop read the temperature from the onboard sensor and squirt it down the serial connection. Not quite “production quality” but it will do…
let json = “”
let temp = 0
serial.redirect(
SerialPin.P0,
SerialPin.P1,
BaudRate.BaudRate1200
)
basic.forever(function () {
basic.pause(5000)
temp = input.temperature()
json = “{“ + “\”temp\”” + “:” + temp + “}”
serial.writeString(json)
})
Now, the next part is writing the bridge code for the ESP8266 device. I use the excellent Arduino tooling for all of my IoT tinkering. It has great community support from both device manufacturers and software developers so before I started I knew this piece of logic would be off-the-shelf software components that just needed configuring up with a bit of ‘glue’ code.
Setup logic on the ESP8266 is basically establishing a WiFi connection and configuring the SoftwareSerial component. Hardware wise i’d be using GPIO pin 12 for RX and 13 for TX lines.
As we’re only receiving data from the Micro:bit you only need to connect:
Micro:bit Pin 0 for TX → ESP8266 GPIO Pin 12 for RX
In my ESP8266 code, that’s a case of setting:
SoftwareSerial mySerial(12, 13); // RX, TX
The main processing logic is simple too: connect to MQTT, check for serial data and if you have it then read it and publish it over MQTT.
MQTT_connect();
if (mySerial.available()) {
String temp = mySerial.readString();
tempPublisher.publish(temp.c_str());
Serial.print(“.”);
}
All checks out. Build and upload and “Hey Presto” we have something coming over MQTT
./mosquitto -v
1594813190: mosquitto version 1.6.5 starting
1594813190: Using default config.
1594813190: Opening ipv6 listen socket on port 1883.
1594813190: Opening ipv4 listen socket on port 1883.
1594813191: New connection from 10.0.0.19 on port 1883.
1594813191: New client connected from 10.0.0.19 as auto-75C0F339–0956–3D60–6BD9-E64ED3D1CFEA (p2, c1, k30).
1594813191: No will message specified.
1594813191: Sending CONNACK to auto-75C0F339–0956–3D60–6BD9-E64ED3D1CFEA (0, 0)
1594813194: New connection from 10.0.0.126 on port 1883.
1594813194: New client connected from 10.0.0.126 as auto-7FD0A000–4389–2D02-B7C7–1682D0DA444F (p2, c1, k300).
1594813194: No will message specified.
1594813194: Sending CONNACK to auto-7FD0A000–4389–2D02-B7C7–1682D0DA444F (0, 0)
1594813195: Received PUBLISH from auto-7FD0A000–4389–2D02-B7C7–1682D0DA444F (d0, q0, r0, m0, ‘/feeds/temp’, … (11 bytes))
To verify I use a MQTTool on my iPhone to subscribe to the topic i’m publishing on:
Looks good!
I’m now an hour in to my little tinker time and making good progress.
So, next challenge is to bridge the MQTT message to TIBCO Cloud Messaging. Again another very easy ask. This time I opted to using TIBCO Enterprise Flogo due to its ability to consume and publish messages from all manner of messaging platforms.
Configuring the MQTT Connection and setting up the Flogo Trigger to subscribe to MQTT topic is very easy.
I define the Trigger output using an example JSON message I expect to receive. Flogo takes care of everything else for me:
Mapping the Flow Inputs (a flow is the main processing logic within Flogo and will be executed for each message we received from MQTT) from the Trigger:
The Flow logic is super-simple too, a single activity dropped on the flow allows me to publish the message to TIBCO Cloud Messaging. This could have been Apache Kafka or Pulsar we’re sending to and just as quick… no coding!
Building the target image is all done for me, no complex build tooling with Flogo. I just use choose the target platform and out pops a binary image…
Running the Flogo application, i now see messages being subscribed by my Flogo application and published to TIBCO Cloud Messaging…
Start to finish this little project took me just under 2 hours to do. A few years ago and I’d have estimated closer to 2 weeks. Such is the simplicity of no-coding environments like Flogo!
All the source files for this little tinker project can be found in my Github repo here:
