Sign in Sign up
Minol ZENNER Connect Logo
Minol ZENNER Connect Logo
  • Sign in
  • Sign up
  • English
    • German

Tag: indoor climate

Raumklima-Dashboard auf Basis der B.One Middleware Teil 2: Technische Umsetzung

Room climate dashboard based on B.One Middleware Part 2: Technical Implementation

In the first part of this small series, we showed you an implementation example for a room climate dashboard based on the B.One Middleware. Now let's …
Community Admin 16. January 2023
Raumklima-Dashboard auf Basis der IoT-Plattform B.One Middleware - Ein Umsetzungsbeispiel

Room Climate Dashboard based on B.One Middleware Part 1: A Sample Implementation

[Update des ursprünglichen Artikels vom 22.07.2022] The use of LoRaWAN® sensors in combination with a dashboard is ideal for monitoring the indoor c…
Community Admin 25. August 2022

Field Report: Healthy Room Climate in the Homeoffice with LoRaWAN® Part 2 – Humidity, Amount of Light & Conclusion

Most recently, it was shown here how you can ensure a healthy indoor climate with IoT sensors and the B.One Gallery, for example in the home office or…
Michi 28. April 2022
1 Comment

Field Report: Healthy Room Climate in the Homeoffice with LoRaWAN® Part 1 – Setup, CO2 Level & Temperature

Most recently, it was shown here how you can ensure a healthy indoor climate with IoT sensors and the B.One Gallery, for example in the home office or…
Michi 22. April 2022
0 Comments
ZENNER CO2-Indikator und Sensative Strips +Comfort neben einem Schreibtisch im Homeoffice

IoT in Homeoffice & Office: Healthy Room Climate with LoRaWAN® Part 2 – Connection of an IoT Platform

In part 1 of this small series, we laid the foundations for monitoring the working/room climate in the home office and office with some theory and the…
Community Admin 20. December 2021
ZENNER CO2-Indikator und Sensative Strips +Comfort neben einem Schreibtisch im Homeoffice

IoT in Homeoffice & Office: Healthy Room Climate with LoRaWAN® Part 1 – Basics & Sensors

A healthy working/room climate is an important factor for high productivity in the home office and office. Find out how you can ensure this using LoRa…
Community Admin 16. December 2021

Application room climate, temperature, CO2, humidity, movement, light,…

– 📖🕓 ≈  < 1 min – Ideal for monitoring rooms, meeting rooms, offices, classrooms, warehouses, rooms, production areas, cold rooms, greenhouses, technical rooms. But also, for example, in boats and caravans…

Boris 25. February 2021
0 Comments

Who’s Online

Online 0
There are no users currently online

Search

Categories

Tags

Air quality Alarming B.One Community CO2 level CO2 measurement Competition Connectivity door sensor GatewayPLUS GatewayPLUS Indoor GatewayPLUS Smart Howto indoor climate indoor climate monitoring Instructions IoTandMe IoT platform Leakage monitoring Level LoRaWAN LoRaWAN network Minol ZENNER Monitoring Monitoring Network Network access Notifications Opening state Open source Payload configuration PLUG&PLAY room temperature sensitive Sensitive strips Sensor technology Strips multi-sensor Temperature Temperature monitoring Tool Trainee contest Visualization tool ZENNER ZENNER CO2 indicator ZENNER IoT GatewayPLUS ZENNERShop

Recent Posts

  • LoRaWAN® on the Construction Site: Use Cases, Advantages & Practical Example
  • B.One Community Howto: Staying Up to Date
  • Room climate dashboard based on B.One Middleware Part 2: Technical Implementation
  • B.One Gallery Howto: Set Up & Manage Notifications
  • B.One Community Howto: Use forums for knowledge exchange
© 2023 - B.One Community
  • Privacy Policy
  • Imprint
  • Help
  • Terms of Use

Forum Description

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:

1. B.One Middleware as a Database

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:

  • Quick Guide – B.One Middleware
  • B.One Middlware Howto: Setting up forwardings

2. Interaction B.One Middleware, Virtual Machine & Dashboard Web Application

Interaction B.One Middleware, Virtual Machine and Dashboard Application
Interaction B.One Middleware, Virtual Machine and Dashboard Application

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.

Intermediate Virtual Machine (VM) instead of direct data query via API Call
Intermediate Virtual Machine (VM) instead of direct data query via API Call

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.

3. Structure of the Dashboard Application

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:

Raumübersicht in einem Beispiel-Dashboard zur Raumklima-Überwachung in Besprechungsräumen
Grid system for a complete overview of all meeting rooms in the room climate dashboard

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

The 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:

In order to provide you with the best possible user experience and offer, we use cookies on our website that are not only technically necessary but also serve to analyse access. By clicking on 'Accept all' you agree to this. You can find more detailed information and how to revoke your consent at any time in our Privacy Policy. (Decline)
Cookie settingsAccept all
Einwilligung erneut aufrufen

Your Cookie Consent

Our website uses cookies to help us improve our website and provide you with the best possible service. These cookies are necessary and cannot be disabled. We also use cookies to analyse the traffic on our website. By clicking on 'Accept', you agree to our cookie policy:
Essential
Always Enabled
Essential cookies enable basic functions and are necessary for the proper functionality of the website.
Statistics
Statistics cookies collect information anonymously. This information helps us understand how our visitors use our website.
SAVE & ACCEPT