Domotizzare in autonomia la casa - un consiglio ed aiuto

[Fulvio Spelta]

Ciao a tutti,

poiché sto ristrutturando una casa, come dice l'oggetto vi chiedo cortesemente un consiglio ed un aiuto per impostare la domotica,

che non vorrei fare spintissima (per essere precisi terrei separata la parte multimedia dalla parte domotica vera e propria).

Riassunto delle necessità principali

• automazione tapparelle (su/giù)
  
• automazione luci (on/off)
  
• automazione cancelli e basculanti
  
• controllo temperatura ambienti ed esterna
  
• controllo luminosità
  
• sensori presenza (connessi ad esempio a logging e ad accensione automatica di luci ambiente)
  
• logging e storicizzazione dei dati
  

Esperienza attuale

Attualmente ho predisposto un lab con:

• Arduino 1 e eth shield
  
• Arduino mega e eth shield
  
• DINO II
  
• OpenRemote
  
• OpenHAB
  

Ho lavorato un po' ed ho realizzato piccoli sketch con i quali misuro la temperatura con un DS18B20 e la rendo disponibile 

via http/raw/xml/json a openhab/openremote per la storicizzazione in rrdj4, mysql e open.sen.se.

Il tutto è molto intrigante e funziona piuttosto bene, per cui mi sono deciso a realizzare in proprio la domotica della nuova casa;

ovviamente occorre che il risultato sia robusto ed affidabile.

Sto quindi cercando di progettare l'infrastruttura che per il momento mi sono immaginato così:

- LAY1: layer di attuazione composto da n DINO II collegati a pulsanti per il comando di luci, tapparelle, tutti connessi a ethernet

i DINO del LAY1 devono essere autonomi e svolgere le funzioni di attuazione in autonomia; mi piacerebbe che l'azionamento 

di un pulsante su un DINO possa attivare un relè su un altro DINO lo stato dei relè dovrebbe essere reso disponibile per il 

layer di interfaccia

LAY2: layer si sensoristica che pensavo di realizzare mediante 1 arduino mega che legga lo stato 

dei numerosi sensori on/off che controllano lo stato di apertura/chiusura delle finestre, acquisisca la temperatura da 

alcuni DS18B20 che metterò in alcune zone, acquisisca la luminosità da un sensore fotosensibile, ecc.

Anche in questo caso le misure/gli stati devono essere rese disponibili agli strati di interfaccia

IF1: vorrei attivare un sever openhab che raccolga le info dai layer precedenti e presenti dei pannelli molto gradevoli

che mostrino lo stato della casa e permettano interazione centralizzate e via internet. Tramite i servizi di persistenza

di openhab provvederei anche a memorizzare dati ad esempio sul consumo elettrico e/o logging ad esempio su apertura/chiusura

porte, ecc.

Ho fatto qualche prova ed ho attivo un server sul quale ho costruito un pannello (connesso in websockets) di monitor 

della potenza elettrica (vedi allegato) e storicizzazione dei dati su db mysql e su open.sen.se

Prima domanda: commenti e/o suggerimenti ?

Per lo strato LAY1 di attuazione pensavo di utilizzare souliss quale firmware per i DINO ma devo dire che anche leggendo

la wiki l'approccio al framework non è semplicissimo,ma ci sto lavorando: avete suggerimenti per rendere più veloce l'apprendimento?

Per ultimo, ho letto sulla wiki che l'interazione con souliss mediante http/json non è più supportata quindi come posso

acquisire e comandare lo strato di attuazione souliss da openhab?

Ho scritto molto e mi fermo quindi qui in attesa di vs commenti e suggerimenti.

grazie 1K

[Di Maio, Dario]

Ciao Fulvio,

Benvenuto e buon Natale :)

Non sono lucidissimo in quanto reduce dal cenone, ma credo di poterti dare un primo indirizzo alla problematica.

Quello che vuoi fare a livello LAYER1 e 2 puoi farlo con Souliss prendendolo come é ora. Per le DINo c'é un esempio dimostrativo che "inverte" gli input di una scheda e li indirizza su una gemella, con relativo viceversa.

La parte openHAB é molto interessante, perché da tempo cerco qualcuno che voglia dedicarsi allo sviluppo di un plugin.
In breve JSON non é più supportato in quanto la struttura delle comunicazioni Souliss é completamente su eventi e ciò si addice male con protocolli in polling (cosa che normalmente,  ma non necessariamente, accade lavorando su TCP e HTTP).
Di fondo c'é un problema di RAM (per nodi basati su EMC28J60) e quindi é complesso trovare spazio per gestire protocolli ASCII e memorizzare in un nodo lo stato di tutti gli altri.

Da come scrivi, credo che tu possa portare avanti lo sviluppo di un plugin usando il protocollo binario usato tra le schede (ed anche per Android).

Se ti va di sperimentare posso esserti di supporto.
Per dare una prima lettura, scarica la versione A4.4 e troverai dei documenti di supporto.

Un plugin per openHAB sarebbe un bel passo, una volta capito il meccanismo é molto semplice da implementare.

Fammi sapere cosa ne pensi.

Dario.

P.S.: Per le luci, prevedi luci di cortesia a strisce LED e luci di lettura a bulbo. Se vuoi ridurre il numero di punti di controllo, quelle da lettura puoi intercettarle tutte a monte.

Per il layer2, rischi di dover passare cavi in lungo ed in largo se concentri tutto in un punto. Prendi una scheda supplementare e connettila alla DINo via seriale (se non vuoi avgiungere altro Ethernet).

Ragiona da subito sull'architettura e discutiamome insieme, Souliss ti da molta flessibilità, può aiutarti a ridurre i cablaggi.
Per i sensori, cablaggi troppo lunghi possono essere problematici.

From mobile.

--
You received this message because you are subscribed to the Google Groups "souliss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to souliss+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Di Maio, Dario]

Parlavi di un allegato per la presentazione di dati su un webserver, sono curioso, allega qualche esempio :)

Dario.

2013/12/24 Fulvio Spelta <fulvio...@gmail.com>

--

[Fulvio Spelta]

Ciao, Buon Natale e grazie per la risposta; provo a tenere ordine commentando per punti.

Domotica operativa layer1 e 2

Quello che vuoi fare a livello LAYER1 e 2 puoi farlo con Souliss prendendolo come é ora. Per le DINo c'é un esempio dimostrativo che "inverte" gli input di una scheda e li indirizza su una gemella, con relativo viceversa.

Mi era fatto la stessa idea, come ti dicevo sto cercando di studiarci un po' (spero in questo periodo natalizio) ma ovviamente entrare "a freddo" in un progetto articolato come souliss richiede un po' di concentrazione ed test.

Al momento ho compilato ed eseguito correttamente su un DINO II l'esempio "ssDINo_ex01_LightsGateway" e sono riuscito a connettere la app.

Come prossimi passi vorrei

• Passare a IP statico (il meccanismo automatico è molto fine ma in ambiente complesso e progettato a priori preferisco avere un indirizzamento statico)
  
• Dovrei poi completare un poco la mia conoscenza con il framework pensavo tramite
  
• Realizzazione di mini rete con gateway e nodo slave (sempre luci)
  
• Realizzazione esempio di passaggio comandi da un nodo ad un altro (come mi sugerivi)
  
• Implementazione su DINO II (o altro arduino) della acquisizione temperatura tramite DS18B20 (ho visto sul forum un draft (che va corretto minimanente per quanto riguarda l'acquisizione dal sensore) ma lo scoglio più grande è per me capire come aggiungere la funzione "on top" del gateway o dello slave DINO II lights in modo da utilizzare il pin già dedicato al 1-wire presente sui DINO II
  

OpenHAB Plugin

Un plugin per openHAB sarebbe un bel passo, una volta capito il meccanismo é molto semplice da implementare.

Hai ragione sarebbe il massimo e magari fra un po' potremo provarci. Ti confesso che, mentre con arduino riesco minimamente a programmare pescando dai miei ricordi di inizio attività lavorativa, purtroppo java non ho mai avuto occasione di utilizzarlo e quindi anche in questo caso occorre un significativo tempo di "setup" per avviare l'attività.

Ho, tempo fa, provato a configurarmi l'ambiente e clonare il sw, ma occorre tempo e conoscenze che per ora non ho. Ne riparliamo più avanti :-)

OpenHAB alternative

Attualmente ho sperimentato con successo aggancio alternativo poll via http sia per l'acquisizione di informazioni (stato on/off di linee, acquisizione temparatura dal famoso sensore DS18B20) e funziona benissimo.

Per capirci ora nel laboratorio ho attivo un sistema come da schema:

Tralasciando per ora la parte monitor potenza elettrica (che vedrai negli esempi dopo ma la cui realizzazione è molto semplice)

il link fra OpenHAB e arduino l'ho realizzato mediante 2 diverse chiamate http:

chiamata di get per acquisizione info temperatura o stato del pin esempio di definizione

{ http="<[http://<address>/wm3/json/t/0:30000:REGEX((.*))]" }

In poratica la chiamata ad un url convenzionale tipo:

/wm3 - costante root

/json - tipo di output richiesto (può essere raw, xml, json)

/t - sonda temperatura

/0 - numero sonda

mentre la definzione di un pin digitale che può essere sia letto che impostato (comando carichi) è:

{ http="<[http://192.168.10.90:9090/wm3/json/d/6:5000:REGEX((.*))] >[1:POST:http://192.168.10.90:9090/wm3/json/d/6/1] >[0:POST:http://192.168.10.90:9090/wm3/json/d/6/0]", autoupdate="false" }

Ovviamente la struttura delle url o l'uso del GET o POST è una scelta che può essere rivista al fine di semplificare l'implementazione lato arduino.

Un altra alternativa da analizzare per l'acquisizione dello stato dei carichi o dei sensori, che potrebbe essere più in linea con il modello ad eventi souliss, è utilizzare l'interfaccia REST di OpenHAB mediante la quale dovrebbe essere possibile mediante semplici url segnalare a OpenHAB la disponibilità di nuove informazioni.

https://github.com/openhab/openhab/wiki/Samples-REST

Magari la implementazione di un gateway "ad hoc"per openHAB la si potrebbe fare su un hw più carrozzato come un mega.

Layer Sensori

Per il layer2, rischi di dover passare cavi in lungo ed in largo se concentri tutto in un punto. Prendi una scheda supplementare e connettila alla DINo via seriale (se non vuoi avgiungere altro Ethernet).

Ho già messo tubi ovunque (con grande gioia dell'elettricista :-) che però è ormai preso quanto me dall'avventura) e pensavo di far convergere il tutto verso un arduino mega di raccolta; tra l'altro tutta la rete di sensori open/close va anche connessa all'antifurto, che, per principio di separazione delle funzioni deve avere circuiti propri.

Per completare alcuni esempi di quanto finora provato:

Interfaccia utente standard OpenHAB (configurata per il lab):

Esempio di grafico OpenHAB con dati temperatura storicizzati:

Esempio grafico open.sen.se con dati di crico elettrico storicizzati:

Esempio di dashboard realizzata da me con client websocket per avere aggiornamento in tempo reale da openhab più widget "PerfectWidgetsExpress" e un po' di javascript di collante scritto da me:

Spero di aver dto una migliore idea dello stato delle cose e del potenziale che si può attivare.

Proverò qualche esempio che mi hai consigliato e, immagino, ti chiederò chiarimenti :-)

Grazie e auguri a tutti.

f

[Di Maio, Dario]

Ciao Fulvio,

• Passare a IP statico (il meccanismo automatico è molto fine ma in ambiente complesso e progettato a priori preferisco avere un indirizzamento statico)
  

Si assolutamente, le funzioni di plug&play sono nate per permettere di pre-caricare Souliss sulle schede e renderlo immediatamente fruibile, in quella modalità si riesce a sfruttare solo minimamente le possibilità del framework.

 

• Implementazione su DINO II (o altro arduino) della acquisizione temperatura tramite DS18B20 (ho visto sul forum un draft (che va corretto minimanente per quanto riguarda l'acquisizione dal sensore) ma lo scoglio più grande è per me capire come aggiungere la funzione "on top" del gateway o dello slave DINO II lights in modo da utilizzare il pin già dedicato al 1-wire presente sui DINO II

On top?

OpenHAB alternative

Attualmente ho sperimentato con successo aggancio alternativo poll via http sia per l'acquisizione di informazioni (stato on/off di linee, acquisizione temparatura dal famoso sensore DS18B20) e funziona benissimo.

Per capirci ora nel laboratorio ho attivo un sistema come da schema:

Tralasciando per ora la parte monitor potenza elettrica (che vedrai negli esempi dopo ma la cui realizzazione è molto semplice)

il link fra OpenHAB e arduino l'ho realizzato mediante 2 diverse chiamate http:

chiamata di get per acquisizione info temperatura o stato del pin esempio di definizione

{ http="<[http://<address>/wm3/json/t/0:30000:REGEX((.*))]" }

In poratica la chiamata ad un url convenzionale tipo:

/wm3 - costante root

/json - tipo di output richiesto (può essere raw, xml, json)

/t - sonda temperatura

/0 - numero sonda

mentre la definzione di un pin digitale che può essere sia letto che impostato (comando carichi) è:

{ http="<[http://192.168.10.90:9090/wm3/json/d/6:5000:REGEX((.*))] >[1:POST:http://192.168.10.90:9090/wm3/json/d/6/1] >[0:POST:http://192.168.10.90:9090/wm3/json/d/6/0]", autoupdate="false" }

Ovviamente la struttura delle url o l'uso del GET o POST è una scelta che può essere rivista al fine di semplificare l'implementazione lato arduino.

Sembrano delle chiamate alquanto complesse, sopratutto se confrontate con le chiamate HTTP/JSON presenti in Souliss fino alla versione A4.

Riesci a condividire il codice che utilizzi per questa implementazione? Quanta RAM utilizza?

Fino ad oggi è prevalso un modello tale da garantire le stesse funzionalità su ogni piattaforma, usando come target ATmega328 ed interfacce di comunicazione varie, lato Ethernet la necessità di implementare lo stack IP in software ha introdotto limiti stringenti.

Però stavamo pensando di fare un eccezione per ATmega2560 (Arduino Mega) con Ethernet W5100/W5200 dove in effetti i vincoli si potrebbero rilassare molto.
 

Un altra alternativa da analizzare per l'acquisizione dello stato dei carichi o dei sensori, che potrebbe essere più in linea con il modello ad eventi souliss, è utilizzare l'interfaccia REST di OpenHAB mediante la quale dovrebbe essere possibile mediante semplici url segnalare a OpenHAB la disponibilità di nuove informazioni.

https://github.com/openhab/openhab/wiki/Samples-REST

Magari la implementazione di un gateway "ad hoc"per openHAB la si potrebbe fare su un hw più carrozzato come un mega.

Il problema principale è che la versione A5 ha un gateway che colletta i dati, ma lo fa solo per il passaggio verso le interfacce utente. Prima manteneva lo stato in RAM. Questa modifica (Pass through) ha permesso di incrementare notevolmente il numero di dispositivi gestiti da ogni nodo, perché un vincolo di progettazione di MaCaco (protocollo e struttura dati usati da Souliss) è che tutti condividano la stessa struttura dati.

Ora si può pensare, nel caso di Arduino Mega, di prevedere qualcosa di diverso.

 

Se guardi nel forum, alla voce Zozzariello, trovi una strada di sviluppo particolare. In sostanza rendiamo SoulissApp un server Android per servire una dashboard e gli update su Xively, è tutto in uno stato embrionale.

Con altre persone sul forum si era parlato di openHAB, che tra l'altro, ha riscosso un notevole successo ed è fatto molto bene.

E' giunto il tempo di definire quale strada usare per openHAB, credo che tu possa aiutarci al riguardo.

Dario.