My new Smart Home Automation System with OpenHab2 - Work in progress -> Migrating to OpenHAB3 -> Migrating to OpenHAB 4

#openhab3
Finally I’m beginning my #openhab 2.5 to openhab 3 #migration, with a #raspberrypi 4 4GB Ram, leaving a raspberrypi 3. Here is my activities planning…Obviously I will have forgotten something …

#openhab3
Finally my migration is beginning.
First operative step for my migration procedure from #openhab 2.5 to the fresh new openhab 3. I will perform a new installation from scratch, skipping the direct #upgrade path. I will upgrade also my #hardware, passing from a #raspberrypi 3 to a raspberrypi 4 with 4gb ram. Let’s begin with the download and initial #setup of #openhabian, a #linux based #os, optimized for Openhab 3. I will also perform a data #backup of my #influxdb instance.

#openhab3
After installing #OpenHabian on the #Raspberrypi 4, we continue with the system setup by installing #docker engine, #portainer (web interface for docker container management) and #influxdb as docker container, creating the users and databases to re-import data and be ready for the #persistence of #OpenHAB 3

#OPENHAB3
After installing #InfluxDB on the #Raspberrypi 4 via #docker, we continue with the system setup by restoring influxdb data and using it as the persistence service for #openhab 2, still running

#OPENHAB3
Let’s install the most famous #MQTT #broker, #Mosquitto, via #Docker on #raspberrypi 4 and configure it to accept connection with username and password.

#OPENHAB3
Let’s go ahead with the system configuration, setting the #retention policies on the #influxdb database, to manage the historical depth of the stored data. Beyond this we make the first access to the #OpenHAB 3 dashboard, fresh from installation on #raspberrypi 4.

#OPENHAB3
Here we are at the first step of design: the #semantic #model, one of the main innovations of #OpenHAB 3.

Let’s start with the “virtual” construction of our #house, starting from the definition of the main areas, floor and rooms…all running on #raspberrypi 4

#OPENHAB3
Before proceeding with the migration of the single items from #openhab 2 to openhab 3, I install #tasmoadmin on the #raspberrypi 4 with #docker, using the usual #portainer. Tasmoadmin is an excellent web tool that allows simple management of devices updated with #tasmota firmware; from configuration to massive firmware update.

#OPENHAB3
Finally the first migrated item of #OpenHAB 3. It’s up to a simple #SONOFF Basic, updated with #TASMOTA firmware, which controls the bathroom light and detects the temperature via a #DHT11 sensor connected to its #gpio. In this first part I move the item from openhab 2 to openhab 3 then configure #channel, #equipment and #point and change the #broker connection of the sonoff to the new #mosquitto running on #raspberrypi 4

I don’t know Italian but seems you use Docker to install Mosquitto (InfluxDB, too?) on an openHABian RPi. But why? openHABian has menu options to install both of them natively. I’d consider that a fail.

Hi Markus,
yes you are right. I installed InfluxDB and Mosquitto via docker on an OpenHABian RPI4.

The main reason for this is because I like docker and use it for my job as software engineer.

I don’t think this is a “fail” but another option to do the same thing (maybe better or maybe worse).

For me Home Automation System is an hobby and I like to make experiment with it. OpenHABian is a fantastic OS and give the possibility to non tech-user to be helped a lot in setup and configurations.

Just to go back to topic, why you consider a fail to use docker and not the standard apt package for services? performance? Simplicity? or something else?

Thanks.

Marco

Simplicity, resource usage and the most important reason is because it is the mainstream and default for any openHABian user.
The more people use a specific way of installing stuff the better because they can share their knowledge with each other in case of problems (well or success :)) That is the most important factor to make people use a system in the first place.
That doesn’t work when installers decide to deviate from the mainstream and select their own method (note it doesn’t matter if that’s a better one or not at this stage !) and recommend (or at least show like you did) doing it likewise to a wider audience.
More beginners listen and follow up, mainstream becomes cluttered, synergies get lost.

rgds
Markus

Thanks for your explanation. I understand your thoughts

#OPENHAB3
Let’s continue the #migration of the first item on #OpenHAB 3 installed on #raspberrypi 4.
Using a #SONOFF Basic, updated with #TASMOTA firmware, let’s take the temperature and humidity values, detected by the #DHT11 sensor connected to its #GPIOs.
In this video we continue the configuration of the #semantic-model by creating the #channel / #equipment / #point for temperature and humidity, read via #MQTT using the #JSONPATH transformation

#OPENHAB3
After configuring the various #Channel / #Equipment / #Points of our #Sonoff Basic, updated with #Tasmota firmware, as a light button and humidity and temperature sensor, we create a new test #sitemap in which we will add our items.
In the video we’ll see how sitemap and Main UI can easily be integrated into the native smartphone app.
To conclude we will verify that the values of our items are written to the new #INFLUXDB database, running on #raspberrypi 4

#OPENHAB3

#TASMOTA update for our #Sonoff Basic using #TasmoAdmin software via #docker on #raspberrypi 4.

We also configure #OpenHAB to have the persistence data of multiple #items written on #Influxdb in the same table, marking the inserted records using suitable search #tags. In this way we will no longer have a table for each item, but tables that will aggregate the values of several items.

#OPENHAB3
Temporary installation of #Grafana with #Docker on #Raspberrypi 4 to test and view the data stored on #InfluxDB.
We create a chart on a #dashboard to view the temperature and humidity data of the #sonoff basic updated with #tasmota firmware.

#OPENHAB3
Setting historical data strategy on #influxdb for the items of our migrated #sonoff basic, using #retention policies and continuous #queries.
Also let’s take a look at the graphics integrated into the #OpenHAB 3 main ui using the #rdd4j #persistence engine, native to Openhab, as default.
All running on a #raspberrypi 4.

#OPENHAB3
After setting the data storage strategy of our migrated #sonoff basic, using the #retention policies and continuous queries on #influxdb, let’s check its effectiveness by viewing the data directly in the influxdb table and by creating a small #dashboard on #grafana.
In order to solve the limitation of #openhab not being able to specify a different retention policy for each item, in addition to the classic continuous #query that aggregates data on a higher timeframe, we write a particular query to manage the copy of data from a retention policy to another without making aggregations.
Obviously running on a #raspberrypi 4.

#OPENHAB3
In this first part we apply the concept of #OpenHAB #profiles to store the last update #timestamp of the items based on a #sonoff basic, using the “timestamp on update” profile.
Furthermore we see how it is possible on OpenHAB to #format a data value in a readable string, using the formatting #pattern of the #Java #Formatter class, both on #sitemap and on Main #UI. All running on a #raspberrypi 4