Environmental controls in the office are very important, as the loss of HVAC can result in significant loss to servers, network gear, employee productivity, etc. A few days ago, we decided to prototype a facilities monitoring system that will be able to cover following use cases:
Monitoring temperature and humidity in different zones of the office building.
Processing collected telemetry with various alert rules based on zone type: workspace, meeting, and server rooms.
Distribution of collected alarms to assigned facility managers.
Visualization of real-time and historical values on the configurable web dashboards.
This article describes the development and configuration steps we took in order to build the PoC. The prototype is open-source and is also based on open-source technologies, so you are able to use it for building commercial products.
Data flow diagram
Devices and Connectivity
We decided to use cheap hardware based on the ESP8266 and DHT22 sensor.
The total cost of each device that includes sensor and connectivity module is approximately $5. Because this is a prototype, we decided to use MQTT over Wi-Fi and have not discussed other connectivity options.
Server-Side Infrastructure
The server-side part of the solution will be based on the Thingsboard IoT platform, which is 100% open-source and can be deployed both in the cloud, on-premises, or even on the Raspberry Pi 3. The collected data is stored in a Cassandra database due to the built-in fault-tolerance and scalability. We have recently launched a Live Demo instance to simplify the getting-started process, so we will use this instance in the tutorial.
Development and Configuration Steps
Step 1. Device provisioning
The initial step of the PoC was to provision several devices and their attributes. We’ve decided to support three types of zones: work area, meeting, and server rooms. We have registered three buildings with four rooms each. During registration, we have populated the Zone Id, Zone Type, and server-side attributes. Note that the server-side device attributes may be used by the processing rules but are not visible to the device itself.
Step 2. Flushing the Devices
During this step, we flushed the firmware update with individual device credentials built into the firmware. The firmware code and corresponding instructions are available in the links at the end of the article. We have used code from our
previous article without modification, since all the logic is on the server side.
Please note that steps 1 and 2 may be automated — we’ve developed a simple Java-based application that performs provisioning of the devices and other entities using a REST API and also emulates this device for live demo purposes.
Step 3. Processing Rules
During this step, we have provisioned rules that analyze temperature and humidity against configurable thresholds based on zone type. For example, the acceptable humidity range in the server room is between 40% and 60%, but the humidity range for a work zone is from 30% to 70%.
The rules are basically set of logical expressions written using a JavaScript syntax. For example, the rule for a server room consists of two parts: attribute and telemetry filter. These filters may be combined, but we decided to separate them to simplify the PoC.
Attributes filter body example:
Telemetry filter body example:
You may notice “null” checks in the filter body. This is basically a good practice because you may use the same server for multiple device applications. Some of them report humidity and temperature, whereas some of them upload other sensor readings, and this should not affect rules processing.
Step 4. Alarms Distribution
Now we configure an email plugin to distribute data using the SendGrid mail service and a provisioned rule action to send data to the configured mail address. The rule action consists of several templates that allow flexible configuration of the email topic, body, and address list based on substitution of device attributes and telemetry values. For example, following email body template:
Will be evaluated to the following email body:
The evaluation and template syntax is based on the
Velocity engine.
Step 5. Data visualization
Now we provisioned several dashboards to visualize the data. We will describe them below.
Map Dashboard
This dashboard shows multiple buildings on the map with their short status available in the tooltip. You can use links in the tooltips to navigate to the Floor Plan and Historical Data dashboards.
Floor Plan Dashboard
This dashboard uses a static background image with the floor plan. We have placed widgets that show temperature and humidity in each room being monitored.
Historical Dashboard
This dashboard shows last minute of sensor readings that are reported each second.
Live Demo
In order to demonstrate this PoC in action, you need to follow two simple steps:
Sign-up or
login to the live demo instance and save your login and password.
Download and launch a device emulator using this
link.
Once started, the emulator will ask you for your live demo login and password. This information will be used to get the JWT token and execute REST API calls in order to:
Provision demo devices.
Create rules and dashboards.
Start emulation of the temperature and humidity sensor data for provisioned devices using MQTT.
Conclusion
This prototype was written by two engineers literally in one day. Most of the time was spent on the client-side code (Lua script for real device and emulator). The server-side part of the prototype has zero coding and was all about configuring the rules, plugins, and dashboards.
This demonstrates how easy is to prototype and build IoT solutions using
Thingsboard. Of course, there is certain learning curve that you need to pass, but we hope that this article and other
docs will help you to do just that.
If you found this article interesting, please leave your feedback, questions or feature requests in the comments section and “star” our project on the
GitHub in order to stay tuned for new releases and tutorials.
Links