The basics of IoT, and why Prometheus works so well with it
It’s-a me, MarIoT!
Before we start, please take a moment to appreciate what day it is.
IoT, or Internet of Things, has been a buzzword for longer than usual. Buzzwords usually have two common properties, and then their paths fork:
- There is a useful kernel of truth; that’s the useful part.
- Everyone in a particular space is claiming that their old stuff is fitting the new stuff; that’s the PR part.
- Some buzzwords revert to their useful use after the hype, and some simply disappear.
I like thinking about buzzwords and about the useful aspects of what they mean. The most recent public example focuses on another buzzword currently in its hype phase: observability.
(Micro)kernel of truth
So what are the useful aspects of this buzzword? Mainly, it’s the concept of putting cheap, Internet-connected sensors with some computing power into more and different places than you could before.
Cheap
High-powered microcontrollers like ESP32 or Raspberry RP2040 cost a couple of dollars per piece, even on boards that offer WiFi. Even after buying a clone of the BME280, you end up at roughly $10 in total.
Contrast this with market prices for the old-style sensor packages which can run into the hundreds of dollars, even today.
Internet-connected
The more traditional sensor packages mentioned above still need more infrastructure, though. Usually, they require proprietary cabling and proprietary network connection boxes, both of which cost money.
Wireless
WiFi is the most versatile option. As long as you get power somehow, your devices can be placed freely in your home, the data center, or your outdoor marble storage. And yes, I have done all three of those in my past.
Wireless does not stop there, though. Zigbee is very interesting and commonly used for near-field communication, while LoRaWAN holds a huge potential for remote sensing. There’s a myriad of other standards, but if you’re new to the field, you should find a good one among those three.
Some computing power
One of the reasons why the traditional sensors need network breakout boxes is because they communicate over protocols made for low-power microcontrollers like 1-Wire, Modbus, or CAN Bus. This engineering trade-off makes less sense today, when you can run MQTT or even a HTTP server directly on a microcontroller.
In a time before PromQL supported subqueries, I tried, and failed, to implement the dew point in PromQL. But doing it in C was reasonably straightforward.
More and different places
The pricing structure makes the “more” somewhat obvious: If the same budget can buy 10x the amount of sensors, you can put them into more places.
The “different” is way more interesting: Once your sensor packages use LoRaWAN, they can be kilometers away from any infrastructure. If they use almost no power, they can live off of a single 18700 battery. As an aside, the 18700 is the protected version of the 18650. If you’re using a 18650 directly, going into under or overvoltage can make the battery go boom; so please don’t do that. If they are smaller and lighter, it’s a lot easier to put them into a weather balloon’s payload. While I couldn’t find examples to link to just now, I have seen payloads with live telemetry built by school students. Another upcoming channel is via cheap satellite connections; those connections used to be prohibitively expensive even for large organizations and will soon be cheaper than some landlines.
Connected
A usually non-obvious property is that none of what we talked about needs a central instance anymore. Interconnected sensor networks can make their own call. If one wind turbine in a wind park needs to shut down due to wind gusts, it can already send signal to all the others to go into safe mode, reducing long-term overall maintenance costs.
That’s it(?)
In summary, at its core, IoT is about putting more sensors and more logic into existing places, putting them into places they could not be before, and distributing decision-making towards the edge of the network — all while still being able to ingest the data for large-scale analysis.
Prometheus & time series
So now that you have more data from more places, where do you put it? You may call me biased, but I would say Prometheus. ;)
Sensors register a value over time. That’s the very definition of a time series. No matter if it’s temperature, relative humidity, absolute humidity, physical distance, or the combination of it all to observe your avocado plant — it’s all data that Prometheus was made for. Years ago, Goutham Veeramachaneni played with public weather data and achieved several orders of magnitude in compression through the Prometheus TSDB design. Plus, PromQL allows vector math on your data, something everyone dealing with weather data will appreciate.
A lot of the math and science Prometheus is based upon was initially created to deal with weather data. Which, to me, closes the circle in a particularly pleasant way.
Future work
Goutham will write a follow-up blog post. If you can guess what it will be about, and if that area is interesting to you, you can claim your prize here.
