As announced in the first part, in this second part we will go into the technical implementation of our room climate dashboard based on the B.One Middleware and the interaction of the respective devices, applications and technologies.
Here is an overview of the exact content:
All LoRaWAN® devices (ZENNER CO 2 indicator & ELSYS ERS Sound) used in connection with the indoor climate dashboard must first be registered in the B.One Middleware so that the data telegrams received from the gateway are decrypted and processed into human-readable measured values by the parser integrated in the platform. In addition, a forwarding rule must be assigned to the devices, in which the URI, the port and the access data of our HTTP endpoint are entered.
Do you want to know how sensors are created in the B.One Middleware or how forwarding is set up? Then we recommend the following articles at this point:
A virtual machine (VM) with a Flask-based HTTP endpoint is interposed between the B.One Middleware and our dashboard application. The endpoint receives the measured values derived from the B.One Middleware and stores them temporarily in its own MongoDB. A successfully received value is confirmed to the B.One Middleware by the HTTP endpoint with the status code 200. This status code is checked by the B.One Middleware. In the event of an error, for example if the endpoint cannot be reached for a short time, the B.One Middleware recognizes this and, after a delay, makes another attempt to transfer it. The maximum number of repetitions can be configured.
The database to which the VM writes the received measured values contains two collections: one collection contains all measured values and the other collection contains the most recent measured value for each sensor, including the timestamp. Incoming packets are written directly to the collection with all measured values. In addition, it is checked whether the timestamp of the telegram is newer than the most recent time stamp of the respective sensor in the second collection. If so, the measured value and timestamp are updated. If the sensor is not yet included in the collection, a new entry is generated.
In addition to the data input, the VM also provides two data output API calls for the web application. One API call outputs a list of all known sensors with the last measured value including a timestamp, the other API call outputs all sensor values for a specific sensor in a given time interval.
Theoretically, it would also have been possible for the web application to query the data directly from the B.One Middleware via API call - but we opted for the intermediate VM, which makes the data available on the intranet without entering access data. This results in the convenience for users that no login information has to be entered for use as long as they are in the company network.
The first API call outputs a list of all known sensors with the last measured value including a timestamp. This is used to display the overall overview of all rooms and their indoor climate.
The second API call in turn outputs all sensor values for a specific sensor in a given time interval. This is only started when you click on a single room view.
The requested sensor data timestamp, CO2 value and temperature, are now processed and prepared in the dashboard we developed.
For reasons of clarity and so that the site can adapt to different display sizes, we have used a grid system to display the individual rooms. Depending on the display resolution and size, this arranges the individual tiles on top of or next to each other. Here is the complete overview in the desktop view:
As you can see, the gauges are programmed to change color depending on the CO2 threshold. An input field can also be used to search for or filter for the respective room. As already mentioned above, the gauges are updated every 5 minutes with the latest available values. If there is no current sensor value available, the tile for the respective room is grayed out. When you click on this, a tooltip opens with the information that there is currently no current value available.
If you want to take a closer look at the desired room with its climate and its course (provided a daily updated value is available), you can click on this room to get to the single view page.
There is also a grid system within the single room view, which integrates a total of four diagrams. These each represent a different data visualization. Here you can see a gauge that shows the temperature, the CO2 level and the timestamp of the transmitted value. These values are also displayed over time again in the "Room climate time course diagram". As soon as another value is transmitted, the time course diagram is dynamically expanded to include the new points/data.
The lower gauge and time history plots contain the values of the noise level and its timestamp.
In the gauge as well as in the time course diagram, the various threshold values were defined via a condition and the color is changed when they fall below or exceed.
In addition, a small burger menu was created in order to get to the overall room overview page and to hide the diagram views that are not required if necessary. Here's an example:https://community.mz-connect.com/wp-content/uploads/2023/01/2023-01-24_raumklima-dashboard-einzelraumansicht-burger-menue-compr-1.mp4
As already mentioned in the first part, there are basically no limits to your own creativity when expanding and designing the dashboard, depending on how much time and effort you want and can put into it. And finally a little hint, in case you wonder why the screenshots are all in German only: The example dashboard shown here has so far only been developed for offices at a German location.
That should have been it for this article. Do you have any further questions or suggestions? Then feel free to put them in the comments! :-) And if you want to see more of the room climate dashboard and how it's made available in the meeting rooms, just take a look at the first part of this little post series.