Home Automation System - Openhab persistence service with InfluxDB

In the last few days I studied the "persistence" service in OpenHAB v.2, just to store acquired data and be ready to create dashboards.

As usual, official docs are the best choice:

http://docs.openhab.org/configuration/persistence.html

I chose InfluxDB as persistence service, a time series database, easy to integrate in Grafana, a web platform for dashboards creation.

The first thing to do is to install InfluxDB on the RPI3 (the same where OpenHAB is already running) following the official documentation https://docs.influxdata.com/influxdb/v1.3/introduction/installation/

Next, I have to enable the persistence service on OpenHAB v.2, using PaperUI, Add-ons section, Persistence tab

Then, OpenHAB must be configured with the InfluxDB connection info, editing services/influxdb.cfg file in the usual OpenHAB configuration folder. In my case, I used all the default options, so I just entered the password.

This is my configuration file:

# The database URL, e.g. http://127.0.0.1:8086 or https://127.0.0.1:8084 .
# Defaults to: http://127.0.0.1:8086
# url=http(s)://<host>:<port>

# The name of the database user, e.g. openhab.
# Defaults to: openhab
# user=<user>

# The password of the database user.
password=XXXXXXX

# The name of the database, e.g. openhab.
# Defaults to: openhab
# db=<database>

On the official guide you can find all the options: http://docs.openhab.org/addons/persistence/influxdb/readme.html

Now it's time to build the persistence strategy to let OpenHAB knows how store data on InfluxDB; in a few words I have to decided, item for item, when datas will be stored on db. I can choose between many options: on every change, on every update or by time schedule, using Quartz syntax. To do so, I created a new configuration file in the /etc/openhab2/persistence folder, called influxdb.persist. In this file I defined which kind of persistence strategy I will use (Strategies section...) and assigned them to items and groups (Items section).

Official docs:

http://docs.openhab.org/configuration/persistence.html#configuration

My Strategies section is as follow:

Strategies {
everyMinute: "0 * * * * ?"
everyHour: "0 0 * * * ?"
everyDay: "0 0 0 * * ?"
default = everyUpdate, restoreOnStartup
}

I used groups to assign the persistence strategies to items; so I defined new groups in /etc/items/groups.items file

Group gPersistence (gAll)
Group gPersistence1m (gAll)
Group gPersistence1h (gAll)
Group gPersistence1d (gAll)
Group gPersistenceChange (gAll)

then I'll assign them the persistence strategy just defined in the Items section of the influxdb.persist file

Items {
gPersistence* :
gPersistence1d* : strategy = everyDay, restoreOnStartup
gPersistence1h* : strategy = everyHour, restoreOnStartup
gPersistence1m* : strategy = everyMinute, restoreOnStartup
gPersistenceChange* : strategy = everyChange, restoreOnStartup
.........
}

I will easily assign these groups to items to assign a particular persistence strategy

In the next post I will speak about Grafana, a powerful tool to build dashboard.

Home Automation System - OpenHAB v.2, a better network monitoring with groups

Introducing the openhab groups in my setup, I improved my network monitoring.

I created a new group called gNetworkCheck, which will be assigned to all the network devices I would like to monitor. This group will be ON when all items will be ON, otherwise OFF.

Then I changed the monitoring rule, defining it only for the group and not for every device; in this way, I could add a new device to monitor simply assigning it to the gNetworkCheck group; no new rules to write.

So, I edited my /etc/openhab2/rules/checks.rules file, replacing all the specific device rules with a single rule for the group:

rule "network check"
when
Item gNetworkCheck changed
then
val lastItem = gNetworkCheck.members.sortBy[lastUpdate].last
logInfo("rules", "NETWORK CHECK -> " + lastItem.name + " changed to " + lastItem.state)
sendNotification([user_to_be_notified], "NETWORK CHECK -> " + lastItem.name + " changed to " + lastItem.state)
end

Following a tip found in the OpenHAB forum (https://community.openhab.org/t/determining-the-triggering-item-in-the-body-of-a-rule/2654/4?u=alex73) I'm able to identify the item changed, which I added to the notification message.

Here is the sitemap with the new group on it

Home Automation System - Using groups in OpenHAB v.2

Another step forward with OpenHAB v.2...let's speak about "groups"; reading the official documentation (http://docs.openhab.org/configuration/items.html#groups) and studying them I discovered that they aren't simple labels to categorize items but they can be used also as particular objects to be added in the sitemaps, they can be used inside "rules" and may get a real value, derived from the linked items. They may also receive commands which will be forwarded to the items inside them.

A "group" is a special item with some differences. It is defined in a .items file in the folder /etc/openhab/items. So I create a new file called groups.items with some groups which I will use later, going forward with the openhab configuration.

Groups may be nested and so it is possible to create a real hierarchical design.

The syntax is very simple and you can find it in the official documentation.

The first groups I created are related to the floor and the room (main floor, first floor, kitchen, garden...), the item type (sensor, switch, network, etc etc...), the purpose (lights, temperature etc etc...) and so on...

Some of these groups will have a real value, depending on the value of the items / groups inside them. Examples:

- the gTemperatureFirstFloor group will be used for temperature sensors on the first floor and its value will be the average of all values of these sensors;

- the gEnergyConsumer group will be used for the energy consumer sensors and its value will be the sum of all values of the sensors;

- the gLightSwitchGarden group will be used for all the light switches in the garden and its value will be ON if at least one switch will be ON, otherwise OFF;

These groups can be put into the sitempas, so their values will be shown (if applicable...) and, click on them, you can see all the items / groups inside them, making a real hierarchical presentation.

For example, referring to the gLightSwitchGarden, we could add other groups for all the light switches in the house: gLightSwitchFirstFloor, gLightSwitchMainFloor, gLightSwitchGroundFloor (inside them we will put the light switch item...). Then, we create a new group called gLightSwitch linked to all of them.

Adding the gLightSwitch group in a sitemap we could browse all the light switches with a couple of click; sending command to gLightSwitch we will drive all the light switchs together.

Here is a video about groups and light switches: