Blog migrato su nuova piattaforma

Disclaimer

Prestare sempre attenzione a seguire le indicazioni fornite in questo blog, soprattutto se si tratta di apparecchiature elettriche collegate alla tensione di 220V. Non mi ritengo responsabile di danni causati dall'aver seguito i consigli qui pubblicati.
Grazie

sabato 25 novembre 2017

Home Automation System - I primi sensori...




Dopo aver fatto un pò di esperimenti e preso dimestichezza con OpenHAB è arrivato il momento di costruire il primo sensore da inserire nel nostro sistema di Home Automation.

Partiamo dalla cucina, dove voglio inserire un rilevatore di gas, un sensore di temperature e di umidità.

Il tutto verrà controllato da una scheda ESP8266 NodeMcu. Ho scelto questa scheda in quanto ha già il Wifi integrato, gestisce numerosi ingressi digitali più uno analogico, è programmabile come Arduino e soprattutto...costa molto poco...Su Banggood sono riuscito a portarne due a casa al costo di € 2,76 l'una, non male...

Per chi fosse interessato qui c'è il link del prodotto:

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


I sensori che andrò ad utilizzare sono i seguenti:

- Sensore di Gas MQ-4: sensibile principalmente al metano (quello che interessa a me...) e anche al propano e butano. Questo sensore lo avevo già utilizzato per qualche esperimento con Arduino qualche mese fa. Eccolo


Sensore Gas MQ-4 su Banggood.com

- Sensore di Temperatura / Umidità DHT11: è un sensore molto economico (con poco più di 5 euro ne ho acquistati 5) e il rilevamento della temperatura ha un errore di +/- 2°C e misura solo temperature positive. La temperatura viene rilevata con massima precisione di 1°C, quindi niente cifre decimali...A causa di queste limitazioni ho deciso di acquistare ed utilizzare i sensori della Dallas, i ds18b20 (sia per esterno che per interno...)...questo DHT11 lo utilizzerò solo per l'umidità


Pacco da 5 su Banggood.com

Pacco da 3 su Banggood.com

Sensore singolo su Banggood.com

- Sensore di Temperatura Dallas ds18b20: rispetto al precedente ha una precisione di mezzo grado e permette di misurare anche temperature negative, quindi è l'ideale per misurare temperature esterne (cosa che ho in progetto di fare...utilizzando la versione sonda da esterno)


Sensore singolo su Banggood.com

Pacco da 5 su Banggood.com

Sonda da esterno su Banggood.com

Faccio qualche prova con i diversi sensori utilizzando una breadboard...


...finchè non trovo la configurazione corretta...quindi mi creo una schedina "definitiva" in maniera un pò artigianale...



Oltre alla scheda ESP8266 e ai sensori, ho aggiunto un led di indicazione della trasmissione dei dati e un connettore per l'alimentazione esterna. La scheda infatti viene alimentata attraverso un piccolo alimentatore 5V 450mA, connesso alla morsettiera azzurra vicino alla scheda. In questo modo, oltre ad alimentare al scheda, alimento anche i diversi sensori.

Il led, il ds18b20 e il DHT11 sono connessi ad ingressi/uscite digitali mentre il sensore del gas MQ-4 è connesso all'unico ingresso analogico presente sulla scheda.

E' arrivato il momento di scrivere il software di gestione...come ambiente di sviluppo ho deciso di utilizzare Visual Studio Code, con estensione Platformio...lo trovo molto comodo e leggero, rispetto all'IDE di Arduino...La scelta è ricaduta su questo ambiente anche perchè esiste un plugin per OpenHAB, che permette di editare in maniera evoluta i file di configurazione (tipo Eclipse SmartHome Designer, ma molto più user-friendly...parere soggettivo...). In questo modo ho un unico ambiente per tutto.

Il software fa in modo che la schedina, tramite il wifi di casa, si connetta al broker MQTT di OpenHAB, acquisisca i dati dei sensori ed invii un messaggio in formato Json sul topic nodemcu/mainfloor/esp8266mcu11/temphumiditygas/state.

La campionatura dei sensori avviene ogni 5 secondi mentre ogni minuto la media delle campionature viene inviata al server. Al momento dell'invio dei dati al server, il led verde lampeggia 3 volte per indicare l'attività di rete in corso.

Ecco un esempio di messaggio inviato dal device al broker MQTT:

{"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}}


Il blocco gas è relativo al sensore MQ-4, il blocco tempHum al DHT11 e il blocco temp al ds18b20

Per adesso ho deciso di mantenere i dati di temperatura di entrambi i sensori per metterli a confronto e vedere come si comportano.

Bene, sembra tutto funzionare...metto quindi il dispositivo al suo posto in cucina


Adesso tocca ad OpenHAB...devo configurarlo per permettere di ricevere i dati e pubblicarli sulla sitemap. Una volta fatto questo, posso anche configurare una nuova dashboard su Grafana, per valutare l'andamento nel tempo dei dati acquisiti.

In OpenHAB non devo far altro che aggiungere i nuovi items per ricevere le informazioni da MQTT. Creo allora un nuovo file chiamato esp8266mcu11.items (esp8266mcu11 è l'identificativo univoco che ho assegnato al dispositivo appena nato...) nella cartella /etc/openhab2/items e aggiungo le seguenti linee:

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)]" }

Tocca poi alla sitemap...aggiungo le seguenti righe:

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
}



E questo è il risultato:


Ottimo, ho aggiunto un altro mattoncino...adesso creiamo la nuova dashboard in Grafana con i dati di temperatura, umidità e gas in cucina:


Ultimo step è quello di aggiungere il dispositivo al monitoraggio della rete...in modo tale che OpenHAB mi notifichi nel caso vada offline. Allora tramite PAPERUI aggiungo il dispositivo di rete utilizzando il Network Binding e ne creo i relativi items, linkando i channels. L'item relativo alla presenza online del dispositivo lo aggiungo al gruppo gNetworkCheck e da adesso in poi il suo stato di presenza in rete sarà monitorato da OpenHAB.

giovedì 16 novembre 2017

Home Automation System - Dashboard con Grafana




La scelta di InfluxDB come motore di persistenza dei dati di OpenHAB è stata dettata anche dal fatto che è facilmente integrabile in Grafana, una piattaforma opensource per la creazione di dashboard web interattive.

Grafana lo installo sempre sul Raspberry PI3, dove girano OpenHAB e InfluxDB, utilizzando lo strumento di configurazione di OpenHAB (openhabian-config), selezionando l'opzione "optional components"


Dopo l'installazione e l'avvio del servizio, la piattaforma risulta raggiungibile sulla porta 3000 via http.

Qui c'è un'ottima guida per la configurazione di Grafana e InfluxDB

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

La creazione delle dashboard e veramente molto facile...una volta definito il data source che punta alla nostra istanza di InfluxDB


Ogni dashboard è un insieme di righe e oggetti; per recuperare i dati si seleziona la grandezza che interessa e via...magicamente appaiono i dati nel grafico, in base all'intervallo temporale selezionato.

Ecco la mia dashboard di esempio dove ho inserito:

- in alto a sinistra i tempi di ping di due dispositivi in rete
- in alto a destra i dati dello speedtest (upload e download su due assi indipendenti)
- in basso i dati di temperature e umiditià del mio paese, ottenuti dal servizio OpenWeatherMap (su due assi indipendenti)


lunedì 6 novembre 2017

Home Automation System - Persistenza dei dati con InfluxDB





Negli ultimi giorni ho introdotto il concetto di "persistenza" dei dati in OpenHAB v.2 in modo da storicizzare i dati acquisti e preparare delle dashboard di consultazione.

Come sempre la documentazione ufficiale è abbastanza esaustiva:


Come motore di persistenza ho scelto InfluxDB, un motore database ottimizzato per memorizzare serie di dati basate su data/ora. La mia scelta è stata dettata anche dal fatto che InfluxDB si integra benissimo con Grafana, una piattaforma web per la creazione di dashboard interattive.

Per prima cosa installo InfluxDB su RPI3 (lo stesso su cui gira OpenHAB) seguendo la documentazione ufficiale https://docs.influxdata.com/influxdb/v1.3/introduction/installation/

Successivamente bisogna abilitare il motore di persistenza su OpenHAB v.2, utilizzando PaperUI, sezione Add-ons, tab Persistence


A questo punto bisogna configurare OpenHAB con le informazioni di connessione al database InfluxDB appena creato, modificando il file services/influxdb.cfg nella solita cartella di configurazione di OpenHAB. Nel mio caso, avendo lasciato le opzioni suggerite, ho dovuto solo inserire la password dell'utente, il resto è tutto lasciato ai valori di default.

Questo è il mio file di configurazione:

# 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>

Sulla guida ufficiale si trovano tutte le opzioni: http://docs.openhab.org/addons/persistence/influxdb/readme.html

Adesso occorre configurare le strategie di persistenza che OpenHAB utilizzerà per memorizzare i dati su InfluxDB; in sostanza devo decidere, item per item, quando memorizzare il dato sul database. Si può decidere di persistere il dato ogni volta che esso cambia, ogni volta che viene aggiornato (anche se non cambia...) oppure ad intervalli regolari di tempo, utilizzando la modalità di schedulazione di Quartz. Per fare questo si deve creare un file di configurazione della persistenza, nella cartella /etc/openhab2/persistence, chiamato influxdb.persist. In questo file andiamo a definire le modalità di persistenza che vogliamo usare (sezione Strategies...) per assegnarle ai vari items / gruppi (sezione Items...).

Documentazione ufficiale

La mia sezione Strategies è la seguente:

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

Per l'assegnazione di "classi di persistenza" degli items ho trovato molto utile utilizzare i gruppi; ho quindi definito dei nuovi gruppi nel solito file /etc/items/groups.items

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

a cui andrò ad assegnare le classi di persistenza sopra definite, nella sezione Items del file influxdb.persist

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

A questo punto per decidere quale item persistere e come, mi basterà assegnare i gruppi corretti.

Nel prossimo post parlerò di Grafana, ottimo strumento per la creazione di dashboard.

domenica 29 ottobre 2017

Home Automation System - Nuovi arrivi in posta...




Venerdì scorso, il postino ha bussato alla porta e mi ha portato alcuni nuovi giocattolini dalla Cina...


Tra gli altri, abbiamo

- un SONOFF B1, lampada RGB controllata via WiFi;
- un SONOFF 4Ch, 4 relay comandati via WiFi;
- alcuni sensori di temperatura / umidità DHT11
- alcune coppie di trasmettitori / ricevitori RF433
- un paio di ESP8266 NodeMCU

Il progetto va avanti...

martedì 24 ottobre 2017

Home Automation System - OpenHAB v.2 Piccolo miglioramento per il monitoring della rete




Dopo l'introduzione dei gruppi nel mio setup di OpenHAB v.2 ho migliorato leggermente la configurazione del monitoring di rete.

Ho infatti aggiunto un gruppo chiamato gNetworkCheck, che verrà assegnato a tutti i dispositivi che verranno tenuti sotto monitoraggio. Questo gruppo assumerà il valore ON quando tutti gli item contenuti saranno in stato ON, altrimenti OFF.

La regola che gestisce il monitoraggio a questo punto non viene definita per ogni dispositivo, ma direttamente sul gruppo; in questo modo ogni volta che aggiungo un dispositivo da monitorare, è sufficiente che esso venga assegnato anche al gruppo gNetworkCheck, senza dover scrivere una "rule" a lui dedicata.

Ho quindi modificato il mio file /etc/openhab2/rules/checks.rules, eliminando tutte le regole associate ai singoli "item" ed inserendone una sola relativa al gruppo:

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


Seguendo un suggerimento di un thread del forum di OpenHAB (https://community.openhab.org/t/determining-the-triggering-item-in-the-body-of-a-rule/2654/4?u=alex73) sono riuscito ad identificare l'elemento che ha scatenato il cambio di valore del gruppo. In questo modo lo posso indicare nel testo della notifica.

Ecco la sitemap aggiornata con l'indicazione del gruppo


mercoledì 18 ottobre 2017

Home Automation System - Usiamo i gruppi di OpenHAB v.2




Altro passo in avanti con OpenHAB v.2...parliamo di "gruppi"; leggendo la documentazione ufficiale (http://docs.openhab.org/configuration/items.html#groups) e dopo averli studiati un pochino mi sono reso conto che non sono delle semplici etichette per categorizzare gli items gestiti da OpenHAB, ma possono servire anche come "aggregatori di informazioni" nelle sitemap, essere utilizzati nelle "rules" ed avere un loro valore puntuale, derivato dai valori dei singoli items ad essi associati. Possono anche ricevere dei comandi che saranno inviati agli oggetti contenuti.

Il "gruppo" non è nient'altro che un item con delle particolarità. Esso infatti viene definito in un file .items presente nella cartella degli items. Ho quindi creato un file dedicato, chiamato groups.items, nella cartella /etc/openhab2/items ed ho iniziato a definire alcuni gruppi che mi potranno tornare utili nel proseguio della configurazione del sistema.

I gruppi possono essere annidati e quindi è possibile creare una vera e propria struttura gerarchica.

La sintassi la trovate nella documentazione ufficiale ed è molto semplice.

I gruppi che ho iniziato a creare mi serviranno per raggruppare gli item secondo i piani e le stanze della casa (main floor, first floor, kitchen, garden...), la tipologia di item (sensor, switch, network, etc etc...), l'utilizzo (lights, temperature etc etc...) e man mano che mi serviranno ulteriori categorizzazioni le andrò ad aggiungere...

Ho fatto in modo che alcuni di questi gruppi possano avere un loro valore, dipendente dai valori degli item / gruppi contenuti. Alcuni esempi:

- il gruppo gTemperatureFirstFloor conterrà tutti i sensori di temperatura presenti al primo piano e il suo valore sarà definito come la media dei valori di tutti i sensori;

- il gruppo gEnergyConsumer conterrà tutti i sensori di misurazione potenza consumata e il suo valore ne sarà la somma;

- il gruppo gLightSwitchGarden conterrà tutti gli switch delle luci del giardino ed il suo valore sarà un ON se almeno uno switch sarà in stato ON altrimenti OFF

Questi gruppi potranno essere inseriti anche nelle sitemap dove si potrà vedere il relativo valore (se lo hanno...) e, tramite un click, vedere tutti gli item / gruppi in esso contenuti, creando una vera e propria visualizzazione gerarchia.

Ad esempio, riprendiamo il gruppo delle luci esterne ed affianchiamogli i gruppi delle luci dei vari piani della casa: gLightSwitchFirstFloor, gLightSwitchMainFloor, gLightSwitchGroundFloor (all'interno di essi inseriremo gli items relativi agli switch delle luci...). Creiamo un nuovo gruppo chiamato gLightSwitch ed inseriremo al suo interno tutti i gruppi delle luci definiti prima.

Inserendo in una sitemap il gruppo gLightSwitch avremo a disposizione una navigazione gerarchica fino ad arrivare ai singoli items, passando dai gruppi intermedi, ognuno con il proprio valore riassuntivo; inviando comandi a gLightSwitch potremmo comandare, tramite un solo oggetto, l'accensione e lo spegnimento di tutte le luci di casa.


Ecco un video di esempio per la gestione delle luci


mercoledì 11 ottobre 2017

Home Automation System - OpenHAB v.2 e monitoring della rete locale




Per continuare nella scoperta e approfondimento di questo "affascinante" mondo di OpenHAB v.2 mi sono cimentato nella creazione di un piccolo sistema di monitoring della rete locale.

Per questo scopo OpenHAB v.2 ci offre un Binding 2.0 direttamente configurabile da interfaccia Paper UI: il Network Binding, attivabile facilmente dalla sezione Add-Ons

Come al solito la guida ufficiale è molto esaustiva: http://docs.openhab.org/addons/bindings/network/readme.html

Questo binding ci mette a disposizione uno strumento di scansione della rete tramite ping di sistema e/o port scanning per individuare i dispositivi che entrano ed escono dalla rete stessa. In questo modo ci permette di associare lo stato di ONLINE / OFFLINE ai vari dispositivi di rete censiti.

I nuovi Things saranno i dispositivi individuabili con l'indirizzo di rete e mettono a disposizione due canali:

- Online: ci permette di associare degli Items di tipo "switch" per rappresentare se un device è connesso alla rete o meno;

- Time: viene associato ad Items di tipo Number che memorizzano il tempo di risposta del device

Non appena installato il nuovo binding, i things vengono subito identificati e OpenHAB ce lo  notifica attraverso la voce di menù INBOX, in alto a sinistra (eventualmente si può forzare la ricerca utilizzando l'icona SCAN in alto a destra)


Una volta identificati gli apparati di rete che si vogliono monitorare, con dei semplici click si generano i Things e, tramite i Channels messi a disposizione, gli Items

Ecco un esempio di Thing -> Channels -> Item relativo al mio router


Ed ecco la pagina di configurazione del Thing "Home Router":


Oltre ai vari parametri di configurazione che si trovano ben descritti nella documentazione ufficiale (http://docs.openhab.org/addons/bindings/network/readme.html), io ho utilizzato anche quello chiamato "Location", nella parte alta, in modo tale da identificare fisicamente la posizione del dispositivo e raggruppare insieme quelli nello stesso luogo di casa.
Ho deciso di utilizzare come "Location" predefinite i piani della casa più il giardino, quindi per adesso il router lo inserisco al "primo piano".

Dopo aver aggiunto tutti i dispositivi che voglio monitorare, per verificare che tutto funzioni correttamente, vado nella sezione "Control" e seleziono la location "First Floor".
Ecco il risultato:



Non mi rimane altro che pubblicare queste informazioni sulla sitemap. Andiamo quindi sul nostro editor SmartHome Designer e apriamo il file /etc/openhab2/sitemaps/test.sitemap.

Aggiungiamo, subito sotto la sezione "General", un nuovo frame chiamato Network in cui inseriamo gli Items appena creati in Paper UI. Per fare questo aggiungiamo le seguenti righe:

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 e  LamanNAS_Online/Time sono i nomi degli Item così come li possiamo vedere su Paper UI).

Ecco il risultato:


Per rendere tutto più "vivo" e soprattutto utile, non mi resta che creare una regola per ogni dispositivo per far sì che mi venga notificato quando avviene il passaggio da ONLINE a OFFLINE e viceversa...

Andiamo quindi a modificare il nostro file /etc/openhab2/rules/checks.rules, dove troviamo già la regola per la notifica degli aggiornamenti di TASMOTA, aggiungengo le seguenti righe:

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





domenica 8 ottobre 2017

Home Automation System - Controllo degli aggiornamenti di TASMOTA con OpenHAB v.2




Un piccolo post riguardo l'inserimento in OpenHAB v.2 di una notifica automatica in caso di aggiornamento della versione del firmware TASMOTA per i SONOFF

Come abbiamo già scoperto in un post precedente e come si "intuisce" dalla documentazione ufficiale di TASMOTA (https://github.com/arendst/Sonoff-Tasmota/wiki/Upgrade#firmware-binary-sources), l'utente @smadds gestisce un broker MQTT pubblico "sonoff.maddox.co.uk:1883" sul quale viene pubblicato l'ultimo aggiornamento della versione del firmware TASMOTA su topic sonoff-version.

Sulla mia configurazione ho facilmente aggiunto un "item" legato, tramite MQTT, a questo valore che poi ho pubblicato sulla mia sitemap.

Per prima cosa ho dovuto creare una nuova connessione MQTT (chiamata sonoffmaddox-mqtt) al broker di @smadds, andando ad aggiungere al file /etc/openhab2/services/mqtt.cfg le seguenti righe:

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

Ho creato quindi un nuovo file nella cartella /etc/openhab2/items che ho chiamato general.items, nel quale ho inserito la seguente riga:

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


Il mio item si chiama SonoffTasmotaVersion, è di tipo "String" ed è legato alla connessione mqtt sonoffmaddox-mqtt, topic sonoff-version. In questo modo tutte le volte che verrà pubblicato qualcosa sul topic sonoff-version del broker sonoff.maddox.co.uk:1883 il mio item verrà aggiornato.

Ultimo passaggio: aggiungere l'item nella sitemap, in modo tale da visualizzare sempre l'ultima versione disponibile di TASMOTA.

Per fare questo, modifico il solito file /etc/openhab2/sitemaps/test.sitemap, aggiungendo, in testa, la visualizzazione dell'item appena creato, all'interno di un "frame" chiamato "general":

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

Ecco il risultato:



Per rendere tutto più utile, ho inserito una regola che mi notifica ogni volta che la versione di TASMOTA viene aggiornata.

Aggiungo quindi il file /etc/openhab2/rules/checks.rules ed inserisco le seguenti righe all'interno:

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

La funzione sendNotification invia una notifica all'utente specificato; questa notifica viene visualizzata sui dispositivi mobile che hanno installato l'app di OpenHAB agganciata al cloud di OpenHAB (MyOpenHAB). La configurazione è molto semplice; basta seguire la guida ufficiale qui http://docs.openhab.org/addons/io/openhabcloud/readme.html

Attendo il prossimo aggiornamento per verificare che la regola funzioni.

lunedì 2 ottobre 2017

Home Automation System - Pulsanti e Switch esterni al SONOFF Basic con TASMOTA





Per utilizzare i SONOFF nel mio impianto luci, ho bisogno che siano attivabili, oltre che tramite OpenHAB anche fisicamente, tramite pulsanti e/o interruttori classici da parete.

Il modo più semplice è quello di usare un pulsante collegato direttamente ai pin del pulsante fisico presente nel SONOFF. Avevo già fatto una prova con il primo SONOFF Basic, come descritto in un post precedente (http://domoticaduino.blogspot.com/2017/08/home-automation-system-sonoff-e-mqtt_19.html).

In questo modo possiamo attivare e disattivare il SONOFF come se agissimo sul pulsante fisico. Ma nel mio caso, ho la necessità di dover controllare i SONOFF anche tramite interruttori/switch da parete. Leggendo la documentazione di TASMOTA, scopro che c'è la possibilità di collegare un pulsante o un interruttore al GPIO14. La cosa bella è che grazie a TASMOTA possiamo decidere se utilizzare un bottone o un interruttore; quindi attivare il SONOFF con un impulso (pulsante) oppure con un segnale continuo (interruttore).

Per fare questo occorre collegare il pulsante / interruttore al pin GPIO14 e al GND; entrambi i pin sono facilmente raggiungibili sul SONOFF Basic. Il GPIO14 è il pin non utilizzato sulla basetta dell'interfaccia seriale, mentre il GND lo ritroviamo subito di fianco (già utilizzato per la comunicazione seriale).





Una volta collegato il pulsante / interruttore non dobbiamo far altro che dire a TASMOTA che al GPIO14 è collegato uno SWITCH e configurare la modalità con cui dovrà lavorare.

Sull'interfaccia web del SONOFF, nel menù di configurazione modulo, vado a settare la tendina del GPIO14 con il valore 09 Switch1


Successivamente si dovrà settare il parametro SwitchMode, tramite Console. Se lavorerò con un pulsante, setterò il valore 3, se invece avrò un interruttore inserirò il valore 0.


Ecco un video con i test di entrambe le modalità





sabato 30 settembre 2017

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




E' arrivato finalmente il momento di integrare MQTT in OpenHAB v.2.

Come descritto in un post precedente (http://domoticaduino.blogspot.com/2017/08/home-automation-system-sonoff-e-mqtt_19.html), attualmente ho un SONOFF Basic già installato e che comanda un lampione in giardino. Come abbiamo visto è già configurato per lavorare con MQTT e quindi lo integriamo in OpenHAB.

Seguo step by step il wiki di Tasmota, dove si parla di integrazione con OpenHAB (https://github.com/arendst/Sonoff-Tasmota/wiki/openHAB) e come prima cosa installo diversi ADDONS in OpenHAB:









A questo punto bisogna configurare la connessione di OpenHAB verso il broker MQTT, che ricordo essere installato sul Raspberry PI 3 dove c'è anche lo stesso OpenHAB. Per fare questo bisogna modificare il file di configurazione /etc/openhab2/config/mqtt.cfg o direttamente dalla shell linux (con nano o vi) oppure utilizzando Eclipse SmartHome Designer, un editor di testo evoluto che semplifica la modifica dei file di configurazione di OpenHAB v.2. Io lo utilizzo per comodità. La sua installazione è molto semplice e quello di cui necessita è semplicemente il path in cui trovare i file di configurazione di OpenHAB. Nel mio caso ho mappato una unità disco di rete chiamata Z che punta alla share samba definita automaticamente durante l'installazione di openHABianPI.

In particolare i parametri di configurazione che ho configurato sono i seguenti:

openhabianpi-mqtt.url=tcp://localhost:1883
server e porta del broker MQTT

openhabianpi-mqtt.clientId=openhabianpi
Client Id con cui openHAB si presenta al broker MQTT

openhabianpi-mqtt.user=openhabian
Username per l'accesso al broker MQTT

openhabianpi-mqtt.pwd=XXXXXXX
Password per l'accesso al broker MQTT

openhabianpi-mqtt.retain=true
Indica se al broker se mantenere i messaggi inviati

openhabianpi-mqtt è il nome logico che ho dato alla connessione ed è ripetuto in ogni parametro, questo perchè potremmo avere diverse connessione mqtt ognuna con il proprio nome. Questo nome verrà poi utilizzato nella configurazione degli items.

Se tutto è andato a buon fine, all'avvio di OpenHAB si dovrebbero trovare due righe di log simili a queste:


Bene, adesso si devono configurare gli items e la sitemap di OpenHAB.

Creo quindi un file nella cartella /etc/openhab2/items chiamato sonoffbasic01.items ed in cui vado ad inserire le definizioni degli items legati al comando del lampione da gestire.

Vado quindi a definire un oggetto di tipo "Switch" (di categoria light) che verrà agganciato al full topic mqtt del SONOFF Basic 01, che ricordo essere tasmota/garden/light/%topic%/%prefix%/. Ecco la sintassi:

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]"
             }

Per informazioni sulla sintassi dei file .items, consultare la documentazione ufficiale http://docs.openhab.org/configuration/items.html

In questo modo ho definito un item chiamato Garden_Light_1Lamp agganciato ai messaggi MQTT appartenenti a determinati topics definiti dal blocco racchiuso tra {...}

Adesso vado ad inserire l'item in una sitemap per poterlo utilizzare. Modifico quindi il file di definizione della sitemap, andando ad aggiungere le seguenti righe:

Frame label="Lights" {

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


}

Non appena salvato, OpenHAB aggiorna la sitemap e se quindi andiamo a vederla, troviamo il nuovo blocco "Lights"



Ecco un video che riassume l'esito dell'integrazione:






lunedì 25 settembre 2017

Home Automation System - SONOFF Dev, un nuovo arrivo




Arrivato un pacco...un nuovo e fiammante SONOFF Dev...tutto da testare e scoprire...comprato direttamente sul sito della iTead a poco più di 7 euro, spedizione compresa.



In poche parole è una piccola scheda di sviluppo basata sul famoso chip ESP8266.

Include connettività WiFi, 5 GPIO, 1 ADC, una porta seriale e uscite a 3.3V o 5V. Ha già incluso un connettore micro USB per la connessione al PC o ad un alimentatore 5V esterno ed è programmabile attraverso l'IDE di Arduino.

Non arriva con firmware preinstallato e quindi necessità di qualche conoscenza di programmazione per riuscire ad utilizzarlo.

Nei prossimi giorni farò qualche test per poi integrarlo nel sistema di Home Automation System, collegandogli qualche sensore.

mercoledì 20 settembre 2017

Home Automation System - OpenHAB 2 all'opera



Dopo aver giocato con i dispositivi fisici, è arrivato il momento di spostarci in area "software". Chi ha già letto i post precedenti saprà che ho scelto di usare OpenHAB v.2, già installato su un nuovo Raspberry PI3, come descritto in un post precedente:


Per me questo mondo è abbastanza nuovo, quindi seguirò fedelmente le informazioni presenti sulla documentazione ufficiale (http://docs.openhab.org/introduction.html), facendo molto riferimento anche alla community (https://community.openhab.org/) in cui si trovano numerose risorse utili.

In parole molto semplici ed in base a quanto ho capito, concettualmente OpenHAB v.2 effettua una mappatura tra dispositivi fisici (reali o virtuali...), chiamati "things", ed entità logiche, chiamate "items". Questi ultimi saranno gli oggetti presenti nelle nostre interfacce di gestione e che avremo a disposizione per gestire il nostro "Home Automation System".


Da www.openhab.org

Per integrare i diversi dispositivi reali e virtuali (things) in OpenHAB v.2 si utilizzano i Bindings, che non sono altro che degli oggetti che permettono ad OpenHAB v.2 di comunicare con i dispositivi esterni (siano essi veri dispositivi fisici o solo WebService che forniscono dati...) e quindi renderli disponibili sul sistema di Home Automation.

L'integrazione degli "items" all'interno delle interfacce "utente" di OpenHAB v.2 viene fatta attraverso la definizione di "Sitemaps", mentre l'automatizzazione e la gestione degli eventi è inserita all'interno delle cosiddette "Rules".

Tutti i dati che transitano sul "Bus di comunicazione" di OpenHAB v.2 possono (ed in alcuni casi devono...) essere resi persistenti e storicizzati attraverso l'utilizzo di motori di persistenza chiamati "Persistence".

Tutti questi concetti verranno approfonditi man mano che andremo avanti con la nostra configurazione.

Il mio sistema è quindi pronto per essere configurato ed utilizzato. Riassumo la configurazione SW attuale sul mio Raspberry PI3

OpenHAB v 2.1
Broker MQTT mosquitto, con autenticazione abilitata
Grafana
InfluxDB, come motore di persistenza di OpenHAB
Reverse proxy SSL con autenticazione, tramite NGINX , per esporre in sicurezza su internet OpenHAB Grafana.

La configurazione standard (selezionando lo "standard package" al termine del setup) dei moduli di OpenHAB v.2 è la seguente:

- BASIC UI: interfaccia grafica responsive per l'utilizzatore del sistema; si basa sulla definizione delle Sitemaps

- PAPER UI: modulo grafico di configurazione, purtroppo non ancora completo (molte cose si continuano a fare tramite modifica diretta di file di configurazione)

- HABPANEL: interfaccia grafica "utilizzatore", nata principalmente per tablet


Esistono comunque altri moduli installabili successivamente tramite la sezione ADDONS di PAPER UI.

Per concludere la panoramica, cito ancora le applicazioni mobile per utilizzare OpenHAB v.2 da smartphone e/o tablet, comode per avere sempre tutto a portata di mano, ovunque noi siamo...




Windows OpenHAB App installabile anche direttamente su PC Windows 10, anche se devo ammettere non mi sembra funzioni molto bene.


E' arrivato il momento di cominciare a far funzionare OpenHAB v.2

Per prendere confidenza iniziamo con qualcosa di facile, prima di addentrarci nella configurazione di MQTT per integrare i SONOFF.

Dopo aver seguito il tutorial "beginners" per prendere confidenza con l'ambiente, non avendo a disposizione al momento dispositivi fisici integrabili direttamente in OpenHAB v.2 (come ad esempio le lampadine LIFX e/o i dispositivi KNX), provo l'integrazione dei dati di speedtest e dei dati atmosferici forniti da servizi esterni.

Per l'integrazione dello speedtest ho seguito quest'ottimo tutorial, direttamente sul sito ufficiale https://community.openhab.org/t/speedtest-cli-internet-up-downlink-measurement-integration/7611, attraverso il quale ho imparato come avviene la configurazione tramite modifica dei file di testo. Infatti vengono coinvolte le seguenti aree di OpenHAB:

 - addons / bindings: per permettere ad OpenHAB v.2 di eseguire dei comandi di shell
 - items: la creazione di oggetti che permettono la memorizzazione dei dati di speedtest; 
 - sitemaps: visualizzazione nell'interfaccia utente dei dati raccolti, collegando ad oggetti grafici gli items di cui sopra
 - rules: creazione di regole per automatizzare la raccolta dati

In sostanza viene detto ad OpenHAB v.2 di eseguire ad intervalli di tempo da definire (io ho previsto di eseguire uno speedtest ogni 2 ore) lo script unix speedtest-cli (interfaccia testuale verso il servizio SpeedTest), memorizzarne i valori di upload, download e ping (...e tanti altri) in oggetti di tipo "items" (come se fossero delle variabili) e collegare questi oggetti a rappresentazioni grafiche in un'interfaccia utente.

In poche parole questo è il risultato sulla mia prima sitemap, vista tramite l'interfaccia web nativa Basic UI


Per quanto riguarda l'integrazione del servizio metereologico, OpenHAB v.2 ha a disposizione diverse tipologie di provider; io ho scelto (perchè lo conoscevo già...) OpenWeatherMap.

Anche in questo caso ho seguito la documentazione ufficiale (http://docs.openhab.org/addons/bindings/weather1/readme.html) e non è stato tanto difficile raggiungere l'obiettivo. Anche in questo caso ho dovuto attivare degli addons / bindings, configurarli, creare degli items ed agganciarli ad una sitemap.

il risultato finale è questo (la mia sitemap inizia piano piano a crescere...):



In entrambi i casi le diverse configurazioni (tranne l'attivazione degli addons / bindings, fatta in Paper UI) sono state fatte direttamente sui file di configurazione testuali. Per farlo ho utilizzato Eclipse SmartHome Designer (http://docs.openhab.org/configuration/editors.html#esh-designer), un editor grafico che offre un minimo aiuto durante le modifiche.

Bene, con queste due "prove" ho verificato che il sistema è funzionante. Tra poco il mio OpenHAB v.2 riuscirà ad accendere il lampione in giardino...grazie all'aiuto di MQTT che ci permetterà di integrare diversi prodotti e servizi.