on
Cloudcoap - Because It Works
Efficiency & Reliability
Even in our days some are still not that happy with their cellular connectivity solution. It is too common to be not that low power as assumed by reading the datasheets. Causing to send only once a day rather than once a hour. The reliability is also frequently behind the believes. Especially on weak radio signals it stops working. In spite of all the promises in the prospects.
As frequently written and agreed by me, there is hardly “one solution” for all the different applications needs. For monitoring and metering application you may have a look at using a protocol, optimized for constrained devices, but still powerful enough, to be used by common cloud applications without a larger gap.
CoAP & DTLS 1.2 CID
 |
 |
|---|
It’s CoAP for the application logic and DTLS 1.2 CID for power efficient encryption.
That uses UDP instead of TCP, which adds flexibility and opens so the door to benefit from the technical progress in cellular communication.
Three years ago I started with the very first end-to-end open source demonstration, using a Thingy:91 (“ouf-of-the-box” cellular modem, Nordic Semiconductor) and Californium (open source, java library, Eclipse foundation). The first messages have been exchanged pretty fast, after two or three days development. All the rest of the time since then has been spent in improving that.
The two charts above shows the result of that work. The data was reported by a Thingy:91, last charged December 2023. Now, November 2024 it has almost 50% energy left. That is better as usual, at that location outside the radio signals are very good. Though it uses UDP, so some may ask, what about message loss? In the past 270 days since that last restart the device sent about 6700 messages. About 30 messages need to be retransmitted, and 4 times the device gives up to retransmit a message.
Let me skip the part, which explains technically, why and how that works together with modern cellular technologies to achieve the goals of reliability and low power consumption. Lets just go forward to how you can make your own experience.
What you will get by that demonstration:
Device
- a open source client for the Thingy:91, sending its data every hour for a year from the internal battery (1350mAh). If that year is reached varies with the radio signal strength. In building basements my experience is half a year or less. Outside it may reach more than a year. For first tests to see, how much reality compared to advertisement this demo will really deliver, you may use this client as it is. It reports the radio conditions and the environment conditions (temperature, pressure, humidity), see the charts at the top. Running it at your intended location for a couple of days and you will get a forecast for the runtime there. For more advanced ideas you may adapt the client. A small couple of boards with a nRF9160/61/51 cellular modem are also supported. That makes it not too hard to add own sensors. It’s possible to port the client also to other platforms, but that’s not the current scope of this open source activity.
Server
- a open source powerful cloud communication endpoint. It depends a lot on the cloud virtual machine you run it, but to start with, usually a small one starting with 2 GB RAM will do it. Please remember, if a device sends a message per hour, even 10.000 device will then send 3 messages per second overall, that’s not that much. The default operation is to store the data from the device in S3 (Simple Storage Service) for further processing and to be displayed by a web application. It’s also possible, to forward the device data via http for further processing to your application backend. Sending configuration data to the device as response, when that reports its data, and FOTA completes the functions. The communication endpoint is configured by a file based API, either on the local file-system of the cloud virtual machine, or using a separate S3 management bucket. These files covers the device credentials and web application user credentials. While to processing power will usually quite enough also for 10.000 devices, managing the credentials in a file using and editor will limit that to more or less 100 devices. For the scope of this open source activity, that’s well. For a usage closer to production, this APIs may be moved into your backend.
Web Application
- a simple open source web application. That enables to visualize the device data in a web-browser. Only pretty simple charts, but to begin it’s easier to use that, than to configure or implement a data forwarding to an other, more functional, service. The web application will also not be suitable to run more than 100 devices, that’s mainly the limitation to keep it very slim and simple. The web application only covers the device data. There is no web API for device management (other then configure and start FOTA) nor web user management.
In general, keep in mind, this is an open source offer, which targets to demonstrate the usage of CoAP with DTLS 1.2 CID and cellular clients. It’s not a commercial product covering multiple different devices, masses of device, nor a rich functional backend.
To Start With
If you are interesting to gain the experience with it, you will need:
- time (2 afternoons, depends on you knowledge and skills it may be more)
- a Thingy:91 and means to flash it (“install the program”)
- an account at a cloud provider (e.g. AWS or ExoScale or ???) to run a virtual machine there
- a DNS domain for the web application
If you don’t want to start with an own cloud virtual machine, you may send me a PM. I will see, if it’s possible to add one or some of your Thingies to a shared cloud instance.