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.
Without this intermediate step via our VM, the users would have to authenticate themselves with their access data each time they were called up, or the access data would have to be stored within the JavaScript code visible in the browser, which is not an option for security reasons.
Our JavaScript application is based on an HTML file that is dynamically designed using JavaScript code.
In order to retrieve the required sensor data, we equipped our JavaScript application with two functions, each of which sends an API call to an endpoint with a static IP address/URL that can be reached from the intranet.
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.
In order to query the sensor data, an API call is sent to the sensor data API presented in the previous chapter in the overall overview. This has the most up-to-date sensor values at hand. In the single room view, the API call is also sent with the parameters DevEUIs of the sensors, the start timestamp and the end timestamp in Unix format so that only the two desired sensors are available in this single room view. Within the JavaScript code, the correct start and end timestamps are always automatically generated and passed to the API calls as parameters. The earliest possible start timestamp was set to 7 am, since no meetings are usually scheduled in the rooms before this time. The API call is carried out automatically via a function when the website is opened, each time the website is updated and every 5 minutes.
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.mp4The appearance of the HTML file and diagrams was styled using CSS and adapted to our design specifications. The JavaScript application allows us to present the requested data in a descriptive way, thus enabling a better analysis of the information. The grid system also gives us the ability to display multiple charts on one HTML page, giving us a comprehensive view of the data.
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.
COOKIES: