Disclaimer

Please, proceed carefully following the tips published in this blog, specially when Main Power is involved. I'm not responsible for any damages caused by what is written in this blog.
Thank you

Saturday, 25 November 2017

Home Automation System - My first sensors...




After all my experiments, now I'm able to use OpenHAB with familiarity; so now it's time to build my first sensors.

Let's start from the kitchen where I would like to monitor gas, temperature and humidity.

The MCU will be a ESP8266 NodeMcu board. I chose this board because it has wifi, several digital I/O and an analog one, you can write firmware in the same way you could with Arduino and above all...it's very cheap...On Banggood I bought two at only € 2,76 each, not bad...

If you are interested in it, this is the product link:

Geekcreit-Doit-NodeMcu-Lua-ESP8266 on Banggood.com


I will use these sensors:

- MQ-4 gas sensor: for detecting of methane mainly, (I'm interested on it...), propane and butane gas. I already used it months ago. Here is it:


MQ-4 gas sensor on Banggood.com

- Humidity / Temperature sensor DHT11: it'a a very cheap sensor (with about €5 i bought 5); its error is +/- 2°C and it's able to get only positive temperature. Its precision is 1°C, so no decimal number...For these limitations I decided to buy other sensors, the ds18b20 (for internal and external use)...I will use these DHT11 just for humidity


5 pack on Banggood.com

3 Pack on Banggood.com

Single sensor on Banggood.com

- Dallas ds18b20 temperature sensor: compared to the previous one it has a better precision (0,5°C) and it's able to get negative values, so it's ideal for external use


Single sensor on Banggood.com

5 Pack on Banggood.com

External probe on Banggood.com

I built some prototype using a breadboard...


...till I found the right configuration...and so I made a "definitive" board...



I added a led used for the indication of network activity and a connector used for external power. The device will be powered through a little 5V 450mA power adapter, connected to the blue terminal blocks. In this way I could power up the device and also the sensors.

The led, ds18b20 and DHT11 sensors are linked to digital I/O and the MQ-4 gas sensor to the analog one.

Now it's time to write the firmware...I use Visual Studio Code with platformio extension; I think it's better than the Arduino IDE (personal opinion). I chose this IDE because it also has an extension for openHAB that let me edit configuration files in a better way (just like Eclipse SmartHome Designer).

My device will connect to the MQTT broker of OpenHAB through wifi, fetch the data from the sensors and send them as json formatted string with nodemcu/mainfloor/esp8266mcu11/temphumiditygas/state topic.

The sample period is 5 seconds and each 60 seconds the average data will be sent to the MQTT broker. When the data will be sent, the green led will blink twice.

Here is an example of a message sent to the MQTT broker:

{"gas":{"error":"","sensorValue":46.33333,"ppm":0.431016,"percentage":0.000043,"realValue":829.0371},"tempHum":{"error":"","humidity":63.66667,"tempC":22,"tempF":71.59999,"heatIndexC":21.91774,"heatIndexF":71.45234},"temp":{"error":"","tempC":21.66667,"tempF":70.99999}}


The gas object is related to the MQ-4 sensor, the tempHum object is related to the DHT11 sensor and the temp object is related to the ds18b20 sensor.

For now I decided to use both sensors for temperature reading; so I can compare them.

Ok, it seems to work as expected...I put my device in the right place in the kitchen...


Now it's time to setup OpenHAB...and build a new dashboard on Grafana.

In OpenHAB I created a new file called esp8266mcu11.items (esp8266mcu11 is the unique id of the device) in the /etc/openhab2/items folder; in this file I appended the following lines:

Number MainFloor_KitchenTemperature "Kitchen Temperature [%.1f °C]" <temperature>
(gPersistence)
{mqtt="<[openhabianpi-mqtt:nodemcu/mainfloor/esp8266mcu11/temphumiditygas/state:state:JSONPATH($.tempHum.tempC)]" }

Number MainFloor_KitchenTemperatureNew "Kitchen Temperature NEW [%.1f °C]" <temperature>
(gPersistence)
{mqtt="<[openhabianpi-mqtt:nodemcu/mainfloor/esp8266mcu11/temphumiditygas/state:state:JSONPATH($.temp.tempC)]" }

Number MainFloor_KitchenHumidity "Kitchen Humidity [%.1f %%]" <humidity>
(gPersistence)
{mqtt="<[openhabianpi-mqtt:nodemcu/mainfloor/esp8266mcu11/temphumiditygas/state:state:JSONPATH($.tempHum.humidity)]" }

Number MainFloor_KitchenGasPpm "Kitchen Gas [%.2f ppm]" <carbondioxide>
(gPersistence)
{mqtt="<[openhabianpi-mqtt:nodemcu/mainfloor/esp8266mcu11/temphumiditygas/state:state:JSONPATH($.gas.ppm)]" }

Number MainFloor_KitchenGasValue "Kitchen Value [%.2f]" <carbondioxide>
(gPersistence)
{mqtt="<[openhabianpi-mqtt:nodemcu/mainfloor/esp8266mcu11/temphumiditygas/state:state:JSONPATH($.gas.realValue)]" }


Now the sitemap:

Frame label="Gas Detection" {
Text item=MainFloor_KitchenGasPpm valuecolor=[>800="red",>600="orange",<=600="green"]

}

Frame label="Kitchen" {
Text item=MainFloor_KitchenTemperatureNew
Text item=MainFloor_KitchenHumidity
}


And this is the result:


Good, I added a new brick...now I can create the new Grafana dashboard with the gas, humidity and temperature of the kitchen:


Last step: adding the device to the network monitoring...so OpenHAB will notify me when the device will be offline.
So, using PAPERUI I added the device using the Network Binding and create the items. Then I added the gNetworkCheck group to the "status" item, so its network presence will be monitored by OpenHAB.

Thursday, 16 November 2017

Home Automation System - Dashboards with Grafana




I chose InfluxDB as persistence engine in OpenHAB also because it is easy to integrate with Grafana, an open source visualization suite that let us build interactive web dashboards.

I installed Grafana on my Raspberry PI3, where already run OpenHAB and InfluxDB, using the Openhabian configuration tool (openhabian-config), choosing "optional components".


Then, I'm able to reach the suite through http on port 3000.

Here you can find a very good guide about Grafana and InfluxDB setup and configuration

https://community.openhab.org/t/influxdb-grafana-persistence-and-graphing/13761#grafana-setup

The process to build dashboards is very easy...as long as you define your InfluxDB data source.


Every dashboard is a set of rows and objects; to fetch your data you have to choose among all the measurements in InfluxDB...

Here is my example dashboard where I put:

- at top left, ping time of my local network devices;
- at top right, speedtest results;
- at bottom, weather data, fetched from the OpenWeatherMap service


Monday, 6 November 2017

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:


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 optionshttp://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:

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.

Sunday, 29 October 2017

Home Automation System - New mailbag...




Last Friday, a new mailbag arrived...full of new stuffs from China...


Among the others, we have:

- a SONOFF B1, wifi controlled RGB lamp;
- a SONOFF 4Ch, wifi controlled relays (4);
- some temperature and humidity sensors DHT11
- some RF433 wireless transmitter and receiver
- a couple of ESP8266 NodeMCU

Keep going on...

Tuesday, 24 October 2017

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


Wednesday, 18 October 2017

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:




Wednesday, 11 October 2017

Home Automation System - OpenHAB v.2 and local network monitoring




Just to go deeper in the learning of the OpenHAB v.2 world, I tried to design a little and simple local network monitor tool.

For this purpose OpenHAB v.2 give us a 2.0 Binding, which can be setup directly through Paper UI: the Network Binding, which can be easily enabled in the Add-Ons section

As usual, the official documentation is very detailed: http://docs.openhab.org/addons/bindings/network/readme.html

This binding gives us a tool to perform network scans, using system ping or port scanning technique, to detect any device joining my network; so I could be informed when a known device is ONLINE or OFFLINE

The new Things objects will be devices identified by address ip; for each of them there will be two channels:

- Online: could be linked to Switch Items to show the network status of the device;

- Time: could be linked to Number Items to store the reply time of the device

With this binding just installed, the things will be automatically discovered and OpenHAB will notify us with the menĂ¹ item INBOX, on the top left side of the UI (in case, you can force the discovering process using the "search" icon on top right)


Identified the network devices, with a couple of clicks I could create the Things and, through the Channels , also the Items

Here is my Thing -> Channels -> Item chain about my home router


And here is the configuration form for the "Home Router" Thing:


Beyond the configuration parameters described in the official docs (http://docs.openhab.org/addons/bindings/network/readme.html), I also used the one called "Location", just to identify the real location of the device.
I decided to use the floors and the garden as location choices. So my home router is at "first floor" location.

After all devices was added, the first test is to have a look at the "Control" menĂ¹, by selecting the "First Floor" location.
Here is the result:



Last step is adding this informations on my sitemap. So, using SmartHome Designer I edited the /etc/openhab2/sitemaps/test.sitemap. file

I added, just under the "General" section, a new frame called Network which contains the Items just created in Paper UI. Here are the lines:

Frame label="Network" {
Switch item=HomeRouter_Online  label="Home Router"      icon="switch"
Text   item=HomeRouter_Time   label="Home Router Time [%s ms]"       icon="network"
Switch item=LamanNAS_Online label="LamanNAS"        icon="switch"
Text   item=LamanNAS_Time label="LamanNAS Time [%s ms]"      icon="network"
}

(HomeRouter_Online/Time and  LamanNAS_Online/Time are the names of the items as we can see on Paper UI).

Here is the result:


Just to make all these things more useful, I could create a new rule for every device I would like to monitor...

So I added the following lines in the /etc/openhab2/rules/checks.rules file, where we can find the already known rule related to the TASMOTA firmware update:

rule "home router check"
when
Item HomeRouter_Online changed
then
logInfo("rules", "HomeRouter_Online online status changed")
sendNotification([user_to_be_notified], " HomeRouter_Online online status changed ")
end





Sunday, 8 October 2017

Home Automation System - Checking TASMOTA firmware updates with OpenHAB v.2





A little post about managing notifications about new TASMOTA firmware versions for SONOFF devices on OpenHAB v.2

As we already know reading the official TASMOTA documentation (https://github.com/arendst/Sonoff-Tasmota/wiki/Upgrade#firmware-binary-sources), @smadds user manages a public MQTT broker "sonoff.maddox.co.uk:1883", where he publishes the last version number of the TASMOTA firmware using topic sonoff-version.

So, in my setup, I just added an "item" linked to this value, through MQTT and then published it on my sitemap.

First thing to do was create a new MQTT connection (called sonoffmaddox-mqtt) to the @smadds broker, appending the following lines to the /etc/openhab2/services/mqtt.cfg file

sonoffmaddox-mqtt.url=tcp://sonoff.maddox.co.uk:1883
sonoffmaddox-mqtt.clientId=
sonoffmaddox-mqtt.user=
sonoffmaddox-mqtt.pwd=
sonoffmaddox-mqtt.qos=0
sonoffmaddox-mqtt.retain=true

Then I created a new file called general.itemsin the /etc/openhab2/items folder, in which I wrote down the following line:

String      SonoffTasmotaVersion      "SONOFF Tasmota Version [%s]"     <settings>
{mqtt="<[sonoffmaddox-mqtt:sonoff-version:state:default]"}


My item is called SonoffTasmotaVersion, its type is "String" and it is linked to the mqtt connection called sonoffmaddox-mqtt, topic sonoff-version. In this way, this item will be updated everytime someone will publish new messages on topic sonoff-version.


Last step: I added my new item to the sitemap, just to keep tracking of the last TASMOTA version.
So, I edited the /etc/openhab2/sitemaps/test.sitemap file, inserting, on the top, the item just created inside a frame called "general":

Frame label="General" {
    Text item=SonoffTasmotaVersion
}

Here is the result:



To be more useful, I created a new OpenHAB rule just to be notified every time the TASMOTA version will be updated.

So, I created the /etc/openhab2/rules/checks.rules file, and wrote down the following lines:

rule "tasmota version check"
when
Item SonoffTasmotaVersion changed
then

logInfo("rules", "New Tasmota Version " + SonoffTasmotaVersion.state)

sendNotification([user_to_be_notified], "New Tasmota Version " + SonoffTasmotaVersion.state)

end

The sendNotification function sends a notification to the specified user; this notification reaches the mobile devices where the OpenHAB App is installed and linked to the OpenHAB cloud (MyOpenHAB). Its configuration is very simple, just following the official guide: http://docs.openhab.org/addons/io/openhabcloud/readme.html

Now I have to wait for the next TASMOTA update just to check that all is working as expected.

Monday, 2 October 2017

Home Automation System - External buttons and switches on the SONOFF Basic with TASMOTA




I need to control SONOFF using either physical buttons and switches and not only through OpenHAB

The easiest way is to use a button directly connected to the physical button pins in the SONOFF. I already made a test with my first SONOFF Basic, as described in a previous post(http://domoticsduino.blogspot.com/2017/08/home-automation-system-sonoff-and-mqtt_19.html).

In this way we could activate and deactivate SONOFF as we do using the physical button. But I need to control the SONOFF through switches too. Reading the TASMOTA documentation, I discovered that I could connect a button / switch to the GPIO14 pin. Then I could tell TASMOTA what kind of object I connected...if a standard button or a switch.

To do so, I have to connect the button / switch to the GPIO14 pin and to the GND pin on the board; both of them are easily reachable. The GPIO14 pin is the one which is not utilized on the serial interface, and the GND is just beside it (already used for the serial communication).





When the hardware link are OK, I have to configure TASMOTA

In the configuration menĂ¹ of the web interface, I choose 09 Switch1 as the new value for GPIO14 drop down list.



Then, I have to set SwitchMode parameter accordly to my needs, through the Console: if I will work with a button, I set up the value 3, otherwise I will put 0


And finally here is a video with my test



Saturday, 30 September 2017

Home Automation System - MQTT, SONOFF and OpenHAB v. 2




It's time to integrate MQTT and OpenHAB v.2.

As already said in a previous post (http://domoticsduino.blogspot.com/2017/08/home-automation-system-sonoff-and-mqtt_19.html), actually I have a SONOFF Basic already installed which drives a garden lamp. As we already know, it's already setup with MQTT and so let's start the OpenHAB integration.

I followed step by step the Tasmota wiki, in the integration section (https://github.com/arendst/Sonoff-Tasmota/wiki/openHAB) and so, as first step, I installed some ADDONS in OpenHAB:









Now I have to setup the MQTT connection to the MQTT broker which runs on the same Raspberry PI 3 as OpenHAB 2; so I have to edit the configuration file /etc/openhab2/config/mqtt.cfg directly through the linux shell (nano or vi) or using Eclipse SmartHome Designer, an advanced text editor optimized for OpenHAB v.2 configuration files. I used it. Its setup is very simple and then it needs to know the OpenHAB configuration files path. In my case I setup a network drive (called Z) for a samba share automatically defined by the installation of openHABianPI.

In particular, the configuration parameters I edited are the following ones:

openhabianpi-mqtt.url=tcp://localhost:1883
serve and port of the MQTT broker

openhabianpi-mqtt.clientId=openhabianpi
openHAB client Id for the MQTT connection

openhabianpi-mqtt.user=openhabian
Username for the MQTT connection

openhabianpi-mqtt.pwd=XXXXXXX
Password for the MQTT connection

openhabianpi-mqtt.retain=true
Defines if the broker should retain the messages sent to it

openhabianpi-mqtt is the logical name of the MQTT connection; in OpenHAB we could have many MQTT connections and in the items configuration we use this name as reference.

If you don't make mistakes, during the OpenHAB boot you may find log messages as following:


Ok, now I will configure items and the sitemap .

So, I created a file called sonoffbasic01.items in the folder /etc/openhab2/items in which I setup my new items.

I defined a "Switch" object ("light" category) which was linked to the full topic mqtt of the SONOFF Basic 01 tasmota/garden/light/%topic%/%prefix%/. Here is the syntax:

Switch Garden_Light_1Lamp "Garden 1-Lamp"      <light>
            (gLightSwitchGarden)
            {mqtt="
                     <[openhabianpi-mqtt:tasmota/garden/light/sonoffbasic01/stat/POWER:state:default],
                     <[openhabianpi- mqtt:tasmota/garden/light/sonoffbasic01/tele/STATE:state:JSONPATH($.POWER)],
                     >[openhabianpi-mqtt:tasmota/garden/light/sonoffbasic01/cmnd/power:command:*:default]"
             }

For info about syntax of .items files please see official documentation http://docs.openhab.org/configuration/items.html

In this way I created an item called Garden_Light_1Lamp linked to MQTT messages of topic defined in the {...} block

Then, I added this new item in my sitemap . So, I edited sitemap definition file, appending the following rows:

Frame label="Lights" {

Switch     item=Garden_Light_1Lamp        label="Garden Light 1 Lamp"       icon="switch"


}

After saved this file, OpenHAB updated the sitemap and the "lights" section appears




Here is a short video about my test:







Monday, 25 September 2017

Home Automation System - New Item: SONOFF Dev




A new mailbag...a brand new SONOFF Dev...bought directly from the iTead ecommerce website...for just 7 euros, shipping included.



In a few words it's an electronic device based on the famous ESP8266 chip.

It includes WiFi connectivity, 5 GPIO, 1 ADC, a serial port and 3.3V or 5V output pin. It already included a micro USB connector to plug in the PC or to connect an external 5V power supply. It supports Arduino IDE programming.

It has no default firmware and so you need a little programming knowledge.

In the next days I will do some test and then I'll try to integrate it in my Home Automation System, linking some sensors.

Wednesday, 20 September 2017

Home Automation System - It's time for OpenHAB 2




Ok, I played a lot with hardware device :), now it's time to get involved in the "software" area of my Home Automation Project. Who read my previous posts already knows that I chose OpenHAB v.2 as my Home Automation System software; it's already installed on my new Raspberry PI3, as described in a previous post:


For me this is a new "world" and so I will follow the official documentation (http://docs.openhab.org/introduction.html) and the community too (https://community.openhab.org/) where you can find a lot of useful infos.

In simple words (and based on what I understood), OpenHAB v.2 makes a link between the devices (real or virtual...), called "things", and logical entity, called "items". The items will be used to manage the "Home Automation System".


From www.openhab.org

To integrate the real or virtual devices (things) in OpenHAB v.2 you can use Bindings, which are objects that make OpenHAB v.2 able to communicate with external device (real devices or simple Webservice or data providers...)

"Items" integration inside the user interfaces will be done using "Sitemaps", while "Rules" permit to manage events and automation logics

All data which will transit over the OpenHAB v.2 Communication Bus can be stored through persistence engine called "Persistence"

I will try to explain all of these concepts as I move forward with my configuration.

So, my system is ready to be configured and used. This is my software configuration on Raspberry PI3

OpenHAB v 2.1
Broker MQTT mosquitto, with auth
Grafana
InfluxDB, as persistence engine of OpenHAB
Reverse proxy SSL with auth, using NGINX , to securely expose on internet OpenHAB Grafana.


The standard configuration (choosing the "standard package" at the end of the setup) of openHAB v.2 modules is the following one:

- BASIC UI: responsive UI for the standard user; it is built using Sitemaps

- PAPER UI: UI for configuration purpose, not completed yet (mmany configurations part will be done directly using configuration files)

- HABPANEL: user UI, optimized for tablet


There are lots of others modules; see the ADDONS section of PAPER UI.

To complete the overview, two words about native mobile App




Windows OpenHAB App, also for Windows 10, but it seems a bit "young".


Ok, it's time to let OpenHAB v.2 doing its stuff

Just to become familiar, I will try something easy; later I will try to integrate SONOFF with MQTT.

First of all, I follow all the beginner tutorial, just to become familiar with the environment and having no real device like LIFX lamp or KNX device, I decide to integrate speedtest and weather data, provided by external services.

For speedtest integration, I followed this great tutorial https://community.openhab.org/t/speedtest-cli-internet-up-downlink-measurement-integration/7611; so I learned as you can edit configuration files. A lot of OpenHAB areas are involved:

 - addons / bindings: to let OpenHAB v.2 exec shell commands
 - items: object creation as speedtest data storage "device"; 
 - sitemaps: user UI, linked to the items
 - rules: automation rule just to collect speedtest data automatically

In other words, OpenHAB v.2 will run speedtest-cli shell script (a textual interface for the speedtest service) at regular time interval (I set a 2 hours refresh), stored its result in item objects and then link these items to a user UI.

This is the result on a new sitemap (Basic UI)


For weather service integration, I chose OpenWeatherMap (already knows it)

So, I followed again the official documentation (http://docs.openhab.org/addons/bindings/weather1/readme.html) and reach the target was not so difficult. This is my final result:


For the files configuration, I used Eclipse SmartHome Designer (http://docs.openhab.org/configuration/editors.html#esh-designer), a graphical editor which provides some facility.

Well, with these test I verified OpenHAB v.2 is a working system. In short time my OpenHAB v.2 will be able to lights up my garden lamp (I hope...)...thanks to MQTT