LoRaWAN® on the Construction Site: Technical Implementation of Presence Monitoring

- 📖🕓 ≈ 6 min -

In the article “LoRaWAN on the Construction Site: Advantages, Use Cases & Practical Example” we gave some suggestions as to which useful use cases can be implemented there with LoRaWAN®, which advantages this transmission standard plays out here in particular, and using the example of presence monitoring , a possible basic setup for implementation in presented to practice. Now let’s take a closer look at its technical implementation. You will learn how the systems/tools used interact with each other and how an alarm notification can be set up via the messenger Telegram.

Interplay B.One Middleware, Node-RED, Telegram & Grafana

Before we go into the individual systems/tools, we first want to get an overview of the overall construct using the following graphic:

The B.One Middleware forwards the data recorded by the sensors via http POST to the http endpoint provided via Node-RED.

The complete logic of the use case is mapped within Node-RED. In this way, the http endpoint confirms receipt of the data to the B.One Middleware.

Besides the acknowledgment, there are two other logic paths: The first one takes all received data telegrams and stores them in a Postgres database. The second path checks whether the current telegram contains the information that the sensor has detected movement on the construction site. If so, it reads the time of the last motion report from the database and checks whether the time difference is above a defined threshold. If the check is positive, a Telegram message will be sent informing you about the motion detection. You can find out how to set this up below.

At the same time, you always have the option of viewing the current data in a tool like Grafana. The visualization platform graphically displays the data stored in the Postgres database.

The basis for the processes described further below is, of course, a device created in the B.One Middleware that is provided with an http forwarding rule.

Mapping Application Logic in Node-RED

In order to be able to implement the use case as described, a virtual machine (VM) that can be reached from the Internet via a fixed IP address/URI is required. The open-source tool Node-RED is installed on this and made accessible, for example, under the subpath “/nodered”. The screenshot below shows the “flow” created in Node-RED:

Start is the http input, which receives the data from the B.One Middleware. Only a subpath and the http method (in our example POST) have to be defined in this, via which the http endpoint can be addressed from the outside. The forwarding URL to be entered in the B.One Middleware consists of the URL under which Node-RED can be reached (red) and the defined subpath (blue). For example “myiotproject.com/nodered /httpinput“.

The data is delivered in the form of a JSON object with all relevant information such as DevEUI, timestamp of receipt, parsed values and much more. From the input, the data first goes into a function that takes the relevant information from the JSON document and splits the further process into three paths:

Acknowledgement of the B.One Middleware http post to our endpoint. If there is no acknowledgement , the B.One Middleware makes two further attempts to transfer the message after a delay. This path is always followed.
Writing the data to a Postgres database. The JSON object is checked using if statements: Is all the required data available? If so, they are forwarded, converted into an INSERT SQL statement by the subsequent node and finally written to the database. Otherwise the path will not be executed.
The third path is only executed if the sensor returns the parsed value “motion” == “on”, i.e. a movement was detected. In this case, the timestamp of the last detected movement is read out via a SELECT SQL statement. In addition to the reading result from the database, the information on the currently detected movement is also retained in the path, so that the two timestamps can be compared with each other in the “compare ts old and new motion” function. In order not to be overwhelmed by too many notifications when there is continuous movement on the construction site, a threshold value is stored here: Only if more than three hours have passed since the last movement is the path continued and a Telegram message sent. Of course, you can choose this threshold flexibly and adjust it at any time, depending on what best suits your needs. Here you may have to play around a little at the beginning to get closer to your ideal value.

Set up Telegram Notification

In order to be able to send automated Telegram messages, it is necessary to set up a Telegram bot, as we have already shown you in the blog post “Grafana Howto: Setting up Alerts using Telegram as an Example“. This is done in a user-friendly way via the “BotFather” wizard within the application. After entering some information, such as the username of the bot, the assistant gives you a token that you can use to authenticate yourself when sending messages, for example. Now you can invite the bot to a group – this has the advantage that you can later add other users/recipients who are also interested in the movement status. Each group is uniquely identified by a so-called chat ID. With the help of the API token and the Chat ID, messages can be sent to the group automatically. To do this, Telegram offers an http endpoint to which API token, Chat ID and the desired message are sent, whereupon the bot posts the content to the group. In the Node-RED flow shown above, the information that movement has been detected on the construction site is sent by a node of the “http request” type.

Here is another example of a Telegram notification received on the smartphone:

Set up Grafana for Data Visualization

In addition to ad-hoc notifications about current movements on the construction site, it is always interesting to be able to track their history – for example, when craftsman A was on the construction site a week ago or how long colleague B was busy with leveling work on Monday. In order to be able to answer these and similar questions, it makes sense to set up a visualization tool that graphically displays the values stored in the database. As already mentioned, the open source tool Grafana is used in this case study. This is installed on the same VM as Node-RED and made accessible via the subpath “/grafana” mentioned above. In Grafana, a “Time Series” panel is created in a dashboard. The Postgres database, into which the data is written by Node-RED, is created as a data source in Grafana. An SQL statement can now be stored, which retrieves the desired data and displays the result over time. The visualization can now be adjusted according to your own wishes.

Here is the example time course diagram from the previous post again:

And here is an example of a complete dashboard with multiple sensors:

You have now seen how you can use the B.One Middleware and open source tools to technically implement the presence monitoring use case on your construction site, as one of our Community members did. Do you have any questions about this or have you already had your own experiences with it? Then talk about it and just share it in the comments 🙂