The application end
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…
