29/10/061

Linux, Domotica  & Autocostruzione

Quale Software &Quale Hardware ???

Cosa è possibile fare ?

29/10/062

Introduzione

Di solito quando si parla di domotica si parla SOLO il multimedia…

Ben diverso è pilotare dispositivi 'fisici' installati nella nostra casa.

Porto il mio esempio di autocostruzione di un semplice sistema domotico

Chi vi parla è un comune perito elettronico … non occorre essere ‘guru’

Vedremo come si possono fare esperimenti e cosa offre il mercato.

29/10/063

Aspettative dal sistema

Controllo e gestione dell’illuminazioneSicurezzaLettura e comando di riscaldamento e forniture 

acqua­luce­gasTelecontrollo ed allarmi via SMS e webPiù che alle ultimissime novità io preferisco 

l'affidabilità, quindi non si cercheranno soluzioni 'estreme' ma piuttosto si preferiranno protocolli ed hardware ben collaudati !

29/10/064

Come ho impostato il sistemaUsare un server centrale + una serie 

di centraline locali indipendenti per migliorare la responsività ai comandi nonché la tolleranza ai guasti

Questo inoltre ci permetterà un costruzione modulare che potrà crescere man mano…

29/10/065

Che porte usareSi sperimenta spesso con la porta parallela. È relativamente facile da usare ma soffre di molti limiti: Ha solo 12 linee di uscita e 4 di ingresso, è a livelli di tensione TTL e quindi non possiamo allontanare troppo la centralina da collegarvi.Molto meglio usare la porta seriale. Con una semplice interfaccia potremo collegare molte centraline sulla stessa linea molto lunga  ed indirizzare ogni volta solo quella che ci interessa con un semplice protocollo.Si trovano facilmente schede seriali multiporta che ci permetteranno di avere 8­16 porte indipendenti.Un consiglio: lasciate perdere l'USB, non è affidabile!!!. Men che meno i convertitori usb­rs232, a meno che proprio non ne possiate fare a meno (ad esempio usando un portatile...)

29/10/066

L’HardwareCentraline autocostruite: ho usato microprocessori 8 bit 

come PIC16F84 e AT89C2051Entrambi questi microprocessori, così come molti altri, 

possono essere programmati con schedine a basso costoPreferite processori con un minimo di periferiche non 

limitatevi al solito 16F84 !Queste sono collegate via Current Loop su una porta seriale 

al serverIl current Loop consente l’isolamento galvanico e risente 

poco dei disturbiInteressante potrebbe essere il canbus, ma non esistono 

interfacce economiche per il pc, rimane il problema dell’isolamento galvanico e la rete non puo essere a stella.

29/10/067

L’Hardware

Ogni centralina ha un indirizzo univoco e viene interrogata ciclicamente dal server per conoscerne lo stato

Il server può inviare comandi alle centraline per accendere o spegnere dispositivi

I dispositivi vengono comandati da relè a bassa tensione

Il comando delle luci deve essere modificato sostituendo gli interruttori con pulsanti che entrano nelle centraline a 220v

Le centraline si comportano autonomamente per l’accensione e lo spegnimento da pulsanti

29/10/068

L’hardware

Il server comanda l’attività sulle linee seriali, nessuna centralina puo iniziare la comunicazione se non interrogata

Raggruppando i comandi delle luci in un unico quadro del piano si sono usate centraline da 3­4 uscite semplificando la costruzione

Sul mio sito ci sono schemi di alcune, altrimenti si possono adattare kit già esistenti.

Vediamo un paio di schemi concreti. il primo è tratto direttamente dallo schema di una centralina realmente funzionante a casa mia.

29/10/069

Un esempio di centralina

29/10/0610

Schema di principio di una rete di di collegamento in current loop

29/10/0611

Schema pratico di un convertitore RS232­current loop

29/10/0612

Software per lo sviluppo

I microprocessori delle centraline sono 8 bit per ragioni di costo quindi le risorse sono limitate, il linguaggio principe è l’assembler

Esistono tuttavia compilatori C o Basic che consentono tempi di sviluppo molto ridotti, l’efficienza nel caso del basic è al di la da venire……..

Il Linux esistono SDCC per 80x51 e Hitec per PICL’assembler pic per windows è ottimo e gratuito…..Esempi sempre nel mio sito

29/10/0613

Cosa esiste di già pronto: X10

Il protocollo X10 consente di comunicare via onde convogliate evitando di stendere cavi schermati 

Esistono moduli già pronti da installare nel quadro elettrico o dietro pulsanti , una centralina apposita viene collegata fra server e rete elettrica, ogni modulo viene indirizzato da una coppia di selettori per un totale di 256 dispositivi comandabili.

Esistono radiocomandi con apposite centraline che fanno da ponte fra rete e radiocomando, esistono pure pannelli touch screen e quant’altro

Tanto per non fare pubblicità io avevo acquistato alcuni moduli su www.intellihome.be

29/10/0614

Cosa esiste di già pronto: X10

Cercate in sourceforge come “X10 house”, troverete molte cose interessanti per interfacciare una centralina standard CM11:

X10BOT : un demone che ascolta quanto arriva dalla centralina CM11 ed esegue script in tcl

X10 universal device driver: crea dei device sotto /dev per ogni vostro dispositivo X10 ! potrete comandarli facilmente da qualunque programma o script per esempio con CRON

Home control system: un vero e proprio sistema domotica che include anche X10

X10 Mp3Anywhere: comandate XMMS via X10 !IPX10 : non dimentichiamo la rete ! questo è un gateway fra 

inter/intranet e il sistema X10SONO + DI 150 !

29/10/0615

X10:moduli commerciali

29/10/0616

Cosa esiste di già pronto: X10Pregi: Moduli già costruiti e a norme di 

sicurezza, semplicità d’uso, installazione possibile in qualunque impianto senza modifiche

Difetti: Costo elevato, lentezza del protocollo, alcuni moduli non possono essere interrogati, limiti di comunicazione fra reti differenti

29/10/0617

Cosa esiste di già pronto: centraline

Sulla rivista Futura Elettronica sono state pubblicate centraline pilotabili via web o porta seriale con poche modifiche possono essere adattate al nostro scopo

Quelle via web sono più lente e possono bloccare il server, preferite quelle seriali

Diffidate sempre di quelle USB, men che meno se non usano chipset standard e ben collaudati come FDTI, se il prodotto non è ben ingegnerizzato puo crearvi serissimi problemi di affidabilità oltre che spesso non avere supporto driver per Linux. La seriale è un protocollo semplice e sperimentato da almeno 30 anni !!!!!

29/10/0618

Sul sito www.acmesystems.it troverete un esempio di interessante SBC con linux embedded. In pratica avremo un kernel Linux 2.4.x o 2.6.x su flash rom che viene esploso in ram all'avvio e crea un completo filesystem linux. Esiste un kit di sviluppo che fornisce tutti i files per compilare ed integrare proprie applicazioni scritte in C o script di shell. On board abbiamo porte di I/O, rete, usb, I2C etc.Unico neo forse il costo, circa 130 euro .

Un potente controller embedded: Axis FoxBoard

29/10/0619

Hardware: moddingL’idea: alcuni router adsl a basso costo usano Linux, 

modifichiamoli per poterli usare come piccoli serverhttp://sprite.student.utwente.nl/~jeroen/projects/lb000021www.amilda.org     http://www.sunspot.co.uk/Projects/Sweex.htmIn questo modo diminuiamo di molto i costi rispetto alla soluzione 

precedente, uno di questi router l'ho trovato su ebay a 8 euro ! Nuovo l'ho comprato a 35 euro spedizione compresa.

Il linguaggio principe è il C, anche qui esiste un kit completo di sviluppo, naturalmente gratis. Si possono comunque usare anche script di shell. Purtroppo NON esiste orologio RTC su cui appoggiare CRON, ma se ne puo sempre mettere uno esterno che comunichi via seriale.

29/10/0620

Server: Perchè Linux ???

Perché è affidabile !!!Con distribuzioni adeguate potete usare vecchi PC come server 

riducendo il consumo elettricoTanta gente usa Visual Basic per sperimentare, ma chi parla pensa 

che sia negativo. E’ accattivante perché in pochi passi vi consente di creare interfacce grafiche molto carine, ma la sintassi troppo lassiva del basic tende a crearvi presto problemi di affidabilità … come per il resto della piattaforma… Inoltre un programma creato in quell'ambiente ha spesso problemi di portabilità, a meno di non creare installer etc...

Non abbiate paura di Linux, l’importante è cominciare ! Una volta addentrati nell’uso resterete colpiti ad esempio dalla potenza di script di shell

29/10/0621

Perchè Linux ???

Windows di primo impatto è semplice da usare ma in realtà molti programmi sono concepiti per una forte interazione diretta con l’utente e poco automatizzabili, ad esempio quello per la centralina X10…

CRON vi permette di automatizzare facilmente molte operazioniCon semplici script di shell potete effettuare operazioni che 

altrimenti richiederebbero veri e propri programmi scritti ad hocEsiste una sterminata quantità di script per inviare messaggi, 

generare grafici (gnuplot) comunicare con programmi via rete (hose)

29/10/0622

Software per il lato server: che linguaggio ?

Python è molto semplice e facile da imparareE’ ad oggetti e molto completoIn poche righe si possono implementare una interfaccia di rete, 

aggiornamenti di siti web, messaggistica email ed altroPer una guida procurarsi: “Python 2.1 bible” di Dave Brueck and 

Stephen Tanner ISBN 0­764­4807­7

29/10/0623

Software per il lato server: Accedere alle porte

Le porte seriali in Linux sono accessibili via file virtuali /dev/ttySxx, qualunque linguaggio che possa leggere e scrivere su un file può quindi accedervi, questo è molto piu semplice che in windows. Un esempio ? eccolo ! non c'è nemmeno bisogno di un linguaggio, basta il prompt dei comandi:

stty -F /dev/ttyS0 9600 cs8 -parenb raw -echoecho “prova di messaggio” > /dev/ttyS0

Per settare i parametri di comunicazione basta usare il comando ‘stty’ in uno script che avvia anche il server

Il software server deve girare continuamente ed essere scritto in modo da evitare che si blocchi ! Usare per quanto possibile i costrutti ‘try’ nei punti critici

Deve gestire file di log per controllare periodicamente se qualcosa va storto

29/10/0624

Software per il lato server: Accedere alle porteLe porte vanno aperte in modo “nonblocking” per evitare che il 

programma principale si blocchi in caso di mancata risposta di una delle centraline.

  global dom2c  #inizializza e apre porta seriale centraline current loop   #piano terra  os.system('stty ­F /dev/ttyR4 4800 ­crtscts ­parenb cs8 ­cstopb raw ­echo')  fds = os.open ('/dev/ttyR4',os.O_RDWR|os.O_NONBLOCK)  dom2c = os.fdopen (fds,'r+')

29/10/0625

Software per il lato server: Accedere alle porte

Gestite un timeout che prosegua oltre (e metta a log l'evento) in caso di mancata risposta entro un tempo predefinito (200 msec bastano !) diamo un esempio:

  dom2c.write('#1q')  #chiedi il report alla centralina   dom2c.flush()  time.sleep(0.2) #attendiamo 0.2 sec poi leggiamo la risposta  datirx = ""  try:      datirx = dom2c.read(4)    if (datirx != ''):      dom2instat = int(datirx[0:1],16) etc etc    else:      dservices.updateerr('errore ricezione centralina domot1')

29/10/0626

Software per il lato server: struttura 

tipoInizializzate tutte le variabili necessarie, aprite i file 

che vi servono poi avviate un loop principaleOgni loop interrogate le centraline per rilevare lo 

stato degli ingressi e dei dispositivi controllatiElaborate lo stato delle usciteSe qualche uscita è cambiata inviatene i relativo 

comando alla centralina in fondo al programma

29/10/0627

Software :il protocollo Fra server e centraline che protocollo utilizziamo ?Vi consiglio caldamente di usare solo caratteri ascii il più possibile mnemonici. Usare caratteri ascii vi permetterà un debug piu veloce dato che potrete leggere 

che comandi transitano sulla rete con un semplice programma di terminale come “minicom”. Inoltre vi semplificherà il protocollo.

Ad esempio io ho usate il seguente:Ogni comando inizia con un carattere di attenzione '#' che non può mai essere 

usato diversamente.Segue l'indirizzo di destinazione della centralina composto da una cifra ascii 0­9Proseguiamo con un comando letterale ad esempio S (set) per accendere, R 

(reset) per sepgnere e Q (query) per interrogare sullo stato correnteSeguono i dati ad esempio il numero 1 per indicare il primo dispositivo 

comandato dalla centralina, magari inviateli due volte per ridurre la possibilità di errori.

Un comando che ad esempio accende la luce dell'ingresso di casa mia è:#1S11

29/10/0628

Possibili espansioni:

Collegando un cellulare con un cavetto seriale potete mandare messaggi sms in caso di eventi gravi (fughe di gas, intrusioni ?)(Io ho usato un modulo specifico gsm per automazione:Ericsson GM47)Un altoparlante a tromba mi avvisa se il carico di rete è eccessivo e stacco dispositivi critici (forno, lavatrice).Sonde termiche per controllare la temperatura dei frigoriferi, se vanno oltre una soglia diamo l'allarme !Avete il server sotto gruppo di continuità ? aggiungete un cellulare gsm ed inviatevi un sms se salta la corrente (magari mentre siete via in vacanza...)Basta un po di fantasia !

29/10/0629

Software per i clientPossiamo creare client per il controllo dell’impianto da un pcIl linguaggio TCL/TK è molto semplice e grazie a VTcl permette di 

generare interfacce utente con un ambiente grafico completoIn questo linguaggio è facile interfacciarsi al server python via socket di 

rete tcp/ipPer una guida procurarsi:Graphical Applications with TCL & TK di Eric 

Foster­Johnson ISBN 1­55851­569­0 ma esistono anche tutorial in rete

Il Tcl le prime volte sembra un po strano, la sintassi è qualcosa di mai visto in altri linguaggi, ma mentre leggevo il  libro qui indicato restavo stupito dalla semplicità costruttiva

Dimenticavo la cosa più importante... TCL/TK è multipiattaforma ! occorre installare l'interprete, ma poi un programma scritto per Linux funzionerà anche in Windows o addirittura MacOs !!!

29/10/0630

Sintassi TCLAd esempio: per interrogare un server (in python o altro, non importa) :  set nethdl [socket 192.168.0.102 1020]ovvero nethdl sarà il canale su cui opereremo, aperto all'indirizzo 192.168.0.102 alla porta 1020  puts ­nonewline $nethdl "statreq"  flush $nethdl  gets $nethdl valfrservpoi inviamo al server la scritta statreq e leggiamo in valfrserv la risposta 

    if {[lindex $valfrserv 1] == 1} {     .house1.L1 configure ­image lampon    } else {     .house1.L1 configure ­image lampoff    } a seconda dello stato della seconda variabile restituita dal server cambiamo l'immagine dell'icona L1 con due simboli, rosso se accesa, blu se spenta.

29/10/0631

Software client: un esempio

29/10/0632

Con VTCL è facile !

29/10/0633

Un terminale seriale a basso consumo

Niente effetti speciali ! un vecchio sinclair Z88 consuma pochissima corrente (appena 1/2W !) e nell'ingresso di casa può fornire info sullo stato dell'impianto

29/10/0634

un GameBoy ???

Se su Elektor nel 2000 l'hanno trasformato in un oscilloscopio digitale a doppia traccia... perché non dovremmo poterlo trasformare in un terminale seriale per domotica ? magari wireless !Esiste un toolkit completo di sviluppo in C gratuito cercate in  www.gbdk.sourceforge.net

29/10/0635

Limiti e sicurezza

Se non vivete ‘soli’ attenzione all’affidabilità !!!Attenzione alla autocostruzione delle centraline a 

220v, documentatevi sulle norme di sicurezzaNon spingete all’estremo l’automazione, potrebbe 

diventare poco pratica e creare falsi allarmi

29/10/0636

Esempi concretiSul mio sito c’è documentato quanto ho fatto:           WWW.FUSO­LUCI.IT

Controllo dell’illuminazione.telecomando e scenariControllo del riscaldamentoMonitoraggio di punti critici: sovraccarico fughe di acqua/gasMessaggistica sms e altoparlanteSegreteria telefonicaClient di rete per controllare l’impianto

espansioni future in programma:monitoraggio temperatura frigoriferiserrande automatiche in caso di pioggiaIrrigazione automatica