Is it too cold and damp? Part 2: Design
In our previous article, we presented the problem we are trying to solve and some high-level requirements. We also mentioned that we are using our Open Source Wireless Environmental Sensor.
A reminder of the Problem statement
Some expensive musical instruments made of wood such as the viola da gamba hate being too wet, too dry or too hot. As a musician, you want to store your instrument in the best possible environment but monitoring the environment is a bit tedious, especially if you have an analogue meter like a hygrometer.
Next step (Design)
If you have followed our Medium publication you know that we already have quite a lot of the software pieces that we can put together to do a first PoC (proof-of-concept).
These are the different components we will discuss in this article:
HiMinds Env
Compared to the current code the key difference is that the WiFi provisioning needs to be much more convenient. As discussed in one of our previous articles; a wifi-captive portal is a convenient way for an end-user to provide the WiFi settings. It is pretty generic, it does not matter if you are using an iOS, Android, Windows, Linux etc client to connect to the HiMinds Env device.
What do we mean by WiFi settings?
The HiMinds Env device needs internet connectivity in order to push data to an MQTT-broker. It gets its internet connection via WiFi (just like most laptops today).
Do you mean the SSID and WiFi-password?
Exactly!
MQTT protocol/Mosquitto Broker
MQTT is one of the most commonly used protocols in IoT-projects. We have used it extensively in our projects and also tried flavours of it. Installing an MQTT broker is pretty straight forward but there are a few things you need to be aware of when working with the ESP32. Have a look at the following article, it describes the potential pitfalls. Part of the design is to specify an MQTT protocol that will be used by the HiMinds Env. device. We want to send the values from the sensors but also send some monitoring/management information. We use the unique serial number of the device (ESP32) to identify a specific HiMinds Env. device.
If we split the information into several different topics; a proposal could be that the following MQTT topics could be used by the HiMinds Env. device:
- /v1/env/system/
- /v1/env/measurement/
- /v1/env/battery/
v1 indicated that it is version 1 of the protocol; if we make any breaking changes we would increment the version to v2. If we use these topics the actual data could look something like this:
Grafana
Grafana is an open-source analytics and visualization software. It provides charts, graphs, and alerts for the web when connected to supported data sources. It has an extensive eco-system that provides many additional features. It works mainly with time-series data and application metrics. You can easily create alerts, notifications, and filters for your data.
Sounds like a pretty good fit for us!
😃
Influx
When working with Grafana there is extensive support for many databases such as MySQL, PostgreSQL etc. but two of the most popular databases are:
- InfluxDB
- Prometheus
There are several differences between these two, but the differences that we are interested in are that:
- Prometheus is a pull-based system
- Influx is a push-based system
With Prometheus, you typically have an endpoint that is polled at a defined interval, the most common use case is that Prometheus will timestamp the data when it is polled.
InfluxDB is a push-based system, your application needs to put the data into InfluxDB and the timestamping is done by your application.
There are workarounds if you want to use Prometheus and do the timestamping on your own but that is a topic for a future article…
For our use-case, Influx feels like a natural choice.
NodeJS Application
In the back-end, we need a service that is able to listen to MQTT messages (subscribe to various MQTT topics) and store the data in a database.
Library support for storing data in Influx is available i.e. node-influx. In the past, we have written code that listens to MQTT messages so we know that works.
For our use-case, NodeJS feels like a natural choice.
Summary
In this article, we did a high-level design of our solution. In our next article, we will start to implement the software and show you a proof-of-concept.
Thank you for reading! Take care and hope to see you soon. 🙏🏽
This article is a living document please reach out to me if you want to contribute or see anything inaccurate here. This article is part of our “Boosting Innovation” project.
