OpenHAB on Beaglebone Black (with SensorTag 2.0)

In some previous posts, I first set up Bluetooth on the Beaglebone Black and then set up Node-Red to convert the Bluetooth data to MQTT messages. In this third post, I’ll be using OpenHAB to receive the MQTT messages, process them and use them for notifications, trending, etc …

OpenHAB

Installation

The installation of Java and OpenHAB is already covered in detail in one of my posts here on element14. The post can be found here: [AirCare] InTheAir – Week 5: openHAB and MQTT
In order to use OpenHAB with the SensorTag, different items, sitemap, rules, etc … will be created though. You’ll find them in the next paragraphs.

Configuration

Items

From Node-RED, all data is being published to the same topic, so in OpenHAB a master item has been defined to subscribe to the appropriate topic.
Other items have been defined in addition to the master item. They will be assigned with values parsed from the master item, categorising the data in different types such as temperature, humidity, buttons, etc …

The items file contains the following:

The screenshot below demonstrates the initial tests, comparing Node-RED’s output to OpenHAB’s input. A limiter was set in place to prevent flooding of data, limiting to 6 messages per minute per sensor used.

21

Sitemaps

The sitemaps file is used to arrange the different items visually, in certain (sub)categories, even including charts. In this example, a chart has been defined for the ambient temperature item, with three possible display periods: hour, day, week.

The result is the following:

22

Rules

Rules can be used to trigger actions based on certain events. In this particular case, two rules have been defined:
Categorise data
Temperature alarm

The first rule is triggered when the master item defined in the items file is updated to a new value. The rule then parses the content in order to categorise it and assign the contents to the item representing the correct sensor. Using some simple string operations, the useful content is extracted from the incoming data.

The second rule demonstrates the use of notifications using Prowl. For testing purposes, I have a notification triggered when the temperature is lower than 50°C. Obviously, this would need to be set to more realistic values, but it is a quick way of verifying the notification mechanism works.

To know more about notifications in OpenHAB using Prowl, be sure to check out the following post: iOS Notifications in OpenHAB using Prowl

Here’s a screenshot demonstrating the data being categorised properly:

23

And some screenshot of the notifications being received on my phone:

24 25

Transform

It is also possible to transform the data in the visualisation layer of OpenHAB. For example, the buttons return a true/false state. More meaningful would be to have the state reported as pressed or released.
By creating a bool.map file in the transform folder and reference it in the items file, this can be done quickly. The file contains one translation per line. In the GUI, “true” will be replaced by “pressed” and “false” by “released”. The “-=-” is there to avoid OpenHAB reporting translation errors when no data has been received yet.

Persistence

Finally, persistence is what defines which data to store and with which type of storage (MySQL, RRD4J, …). Persistence is required when using charts.

Conclusion

This concludes this short series of post on how to retrieve data from a SensorTag via Bluetooth, convert it to MQTT using Node-RED and persist/monitor/trend it using OpenHAB.

Leave a Reply

Your email address will not be published. Required fields are marked *