Last year our friend Richard Ibbotson designed a LoRaWAN shield for the BBC micro:bit and they have been used in several experiments and projects since then, including a great project at the Museum of English Rural Life (the MERL) monitoring the impact of environmental conditions on the growth of sugar beet!
Richard’s shield is a popular conversation piece at various meetups and demonstrations. His write-up on hackaday has been read well over 11,000 times and has attracted interest from several organisations.
Quick recap – In the absence of a UK-wide LoRaWAN network I am looking into the feasibility of developing a LoRaWAN based IoT solution that can work across a patchwork of LoRaWAN networks.
The previous article focused on making the Long Range VAN device – a burglar alarm for white van drivers everywhere – able to roam between different LoRaWAN networks. I am testing with The Things Network in Reading and Things Connected in London.
This article looks at the application end. My application, which receives alerts and GPS position from the van alarm will need to collect messages from different networks and relay then to the van owner.
The Things Network publishes data using MQTT. Things Connected used a different technique – it sends json data to your web server. Either way you need to have a message collector running on your server to listen out for new messages, and then process them appropriately.
On my device I control the structure of the payload (GPS co-ords), but I have little control over the structure of the LoRaWAN message I receive at the app end. There are differences between the two networks in message structure, although they are both essentially JSON format. It would be interesting to try this with Stream Technologies’ implementation of LoRaWAN, or LorIoT to see how much variety exists in message structure between networks.
At the device end I configured the device to use the same device EUI, but I don’t know if this would be permissible on all LoRaWAN networks. It feels prudent to allow for the possibility that different networks may have different device EUIs for the same physical device. An alternative approach would be to include an ID in the payload that we use instead of the device EUI. The significant downside to this alternative is that it increases the message size, which will increase the airtime usage per message, and therefore gobble up the 1% duty cycle more quickly. In my judgement it is better to keep the payload small and do the extra work within the collector.
For the purposes of proving the roaming capability I have written 2 collectors in Node.js, one listening to each network. Each collector converts the received data into a common format JSON document which is inserted into my Mongo database. My app is thereby oblivious to the fact that the data arrived over more than one network. It works with multiple devices on these 2 specific networks for one application. I could write a third collector for say Stream Technologies, and a fourth…
It strikes me that I (or you) could design and write a more general collector that could work for multiple devices and multiple networks for multiple applications and multiple databases. This feels to me like it could be a useful service to offer. I wonder whether there would be sufficient benefit and interest in such a middleware service for IoT application providers who don’t really want to worry about whose LoRaWAN network their clients have installed?
But wouldn’t it be better if the LoRaWAN specification supported roaming so we didn’t need to worry about this stuff? Hmm, maybe it’s in the post…
I am a roaming journeyman, I roam from town to town,
And when I get a job of work I’m willing to sit down.
With my bundle on my shoulder, with my stick all in my hand,
And it’s round the country I will go, like a roaming journeyman.
Tom Willett – The Roving Journeyman
Spring is here, Morris Men are celebrating May Day and folk music is in the air, so you’ll forgive me if my mind turns to roaming…
Earlier this year Thingitude bid for some funding from Reading Council to develop an Internet of Things project with students throughout the summer holidays as part of Reading 2016 Year of Culture. A couple of months later I was told the bid was successful!