Cavolo Luke vai a mille! In due post hai dato dei link utilissimi e sopratutto degli ottimi spunti su cui lavorare!! 
Quella dei Can bus non totalmente open non la sapevo.. ma l'ultimo che hai linkato sembra buono! Da valutare bene!
Un pò di info per capire a grandi linee il protocollo eib: http://www.jaec.info/Home%20Automation/Protocols-buses-house/Eib-Protocol/eib-protocol.php
e sempre dallo stesso link:
http://www.jaec.info/Home%20Automation/Protocols-buses-house/Protocols-Buses-House/protocols-buses-house.php
nelle conclusioni contiene, a mio parere, spunti condivisibili;
tra l'altro parla del BACnet dicendo che sia il protocollo più avanzato e open che ci sia... ma quanti ne esistono...!! :o :-?
(tutorial BACnet: http://www.bacnet.org/Tutorial/HMN-Overview/sld001.htm)
Signori buongiorno, mi scuso intanto se tratto o parlo di cose già trattate, ma il mio tempo è assolutamente ridottissimo e non ho avuto tempo di leggere a fondo le 6 pagine precedenti.
Non l'avevo ancora descritto nel dettaglio, ma in passato aprii un topic per parlare del mio progetto di domotica.
In realtà il progetto è ancora in corso di realizzazione anche se già "pseudo-funziona"...ve lo descrivo.
Ho una villa nella periferia di Roma, molto grande (2 saloni, 2 cucine, 3 bagni, 4 camere, giardino). L'impianto è architettato in questo modo:
- 5 nodi funzionali (Arduino 2009)
- comunicazione tra i nodi via Ethernet Shield (tutti i nodi sono nella mia rete LAN)
- ognuno di questi 5 nodi è collegato con altrettante schede (autocostruite) con installati sopra 2 shift-register (74hc595) ognuna
- le schede shift-register sono collegate a dei relè che agiscono sull'impianto ad alta tensione
- nodo Arduino Mega per la gestione della centrale d'allarme che riceve in Input circa 35 sensori (tra PIR e magnetici) in giro per casa e si collega in Output con combinatore Lince e sirene da esterni Lince/Elkron
Calcolate che ho installato finora (e un nodo non l'ho ancora messo in piedi) 130 Relè e ho circa altrettanti pulsanti...per ora i pulsanti (serie civile bTicino Axolute) sono collegati (non tutti perchè non mi bastano gli input di Arduino) direttamente ai pin di Arduino, l'idea (quando avrò tempo) è di realizzare delle schede Shift-Register di Input per moltiplicare sostanzialmente gli indressi di Arduino 2009.
Il progetto lo stò mettendo in piedi da agosto scorso con un mio amico, a poco più che tempo perso, e a livello software abbiamo realizzato:
- protocollo di comunicazione
- sketch di gestione dei nodi PLC: scansiona i pulsanti e la rete Ethernet, al verificarsi della presenza di un evento su una porta di Input o di un comando pervenuto dalla LAN, esegue il comando (Es. cambia lo stato di OUtput di una porta). La configurazione della scheda di rete (IP, MAC Address) e l'azione collegata ad ognuna delle porte di Input è salvata nella EEPROM
- applicativo client su Windows (C# x framework .net) per l'invio della configurazione sui vari nodi
- web app (stupidissima) in PHP per l'invio dei comandi ai singoli nodi (accendi/spegni luce) tramite pagina Web, pagina esposta sulla WAN tramite serverino Apache.
Ecco...è un sistema piuttosto mastodontico, visto che gestisce di fatto:
- tutte le luci di casa
- la caldaia ed in futuro i climatizzatori
- l'irrigazione del prato
- l'apertura e la chiusura delle finestre (lucernari) a tetto motorizzate
- antifurto
Dunque, così tanto per dire, mi ritrovo di fronte ai seguenti problemi...ve li elenco non tanto per avere un vostro aiuto comunque assolutamente più che gradito, ma per mettervi di fronte alla mia esperienza.
- libreria Eternet: apertura/chiusura socket in continuazione provoca a volte e non ho capito ancora a quali condizioni il blocco della comunicazione...praticamente non c'è più connettività da e per arduino
- Ethernet Shield: se usate la ethernet shield così come vi arriva, sappiate che all'alimentazione dell'Arduino non tramite USB, ma tramite alimentazione diretta, l'Ethernet Shield non và in UpLink (sostanzialmente è come se non si connettesse allo Switch) finchè non si resetta il nodo...sostanzialmente se salta il contatore o "và via la luce", al suo ritorno tocca resettare manualmente tutti i nodi
- non esiste un sistema (quantomeno semplice...qualcosa ho letto ma devo approfondire) per gestire un WatchDog Timer...sostanzialmente se qualcosa và in palla non è facile gestire un "auto-reset"
- alimentatelo a 7/8volt l'arduino o và in fiamme (io ora l'alimento a 13,8volt...dovrò implementare uno stabilizzatore)
- la RAM è veramente poca se si vuole gestire una configurazione dinamica e la EEPROM (che cmq ha cicli di scrittura limitati) è lenta
Sicuramente mi scordo di qualcosa...ora ho scritto così di getto. Metto a disposizione la mia esperienza per discutere con voi, sarebbe bello se succedesse lo stesso con me! 
Ciaooooooooooooooooo
Dario
P.S: Ah...sono di Roma.
Ottime informazioni!
(Peccato che io non sappia fare niente di tutto questo) però di sicuro saranno utili..
Complimenti astroz, hai messo in piedi un bel sistema.
Purtroppo non ho esperienza con ethernet shield altrimenti ti avrei aiutato volentieri.
Riguardo la domotica con arduino quello che si vede in giro (anche su forum di alti paesi) e su cui forse non si ci allinea
è che la maggior parte delle persone vede la cosa come per un uso strettamente personale.
Spesso si vede il caso della persona che non vuole smembrare casa e usa X10, altri preferiscono sistemi diversi su powerline,
oppure qualcun'altro si diverte con i moduli xbee, nel tuo caso l'ethernet ecc..
Manca un sistema che sia veramente "Libero" ...free as in freedom per dirla alla Stalman.
Un sistema libero dovrebbe essere nel modo migliore accessibile a tutti, perché chi non ha le competenze specifiche
per poterlo usare e meno libero di chi le ha. Quindi più semplice = più libero perchè di più facile comprensione.
Anche l'accessibilità economica può essere una discriminante per la libertà; più è caro meno è libero (al contrario del software,
in cui l'impatto economico può essere forse limitato solo dalla potenza di calcolo necessaria,con l'hardware si può creare
facilmente questo problema).
Idealmente l'ethernet è una soluzione brillante ma l'impatto economico dell'impianto e i costi dei singoli moduli
lo rendono meno fattibile. ...per non parlare poi della fragilità del sistema (se si rompe uno switch non accendo più la luce?)
Nelle pagine precedenti ho letto l'intervento di un architetto (stefano72) che poneva il punto sulla semplicità.
E' importantissimo che l'impiantista possa realizzare un sistema domotico senza essere un tecnico iper specializzato.
Io penso che con un pò d'impegno si può realizzare qualcosa di più semplice di quello che offre oggi il mercato.
Visto che mi trovo, riguardo sempre l'intervento di Stefano, volevo dibattere sull'eventualità di integrare audio e video nel sistema.
Penso che la cosa sia per ora troppo complessa ma bisognerebbe già prevedere una possibile espansione in tal senso.
(affiancando l'ethernet al sistema ad esempio, ma senza renderlo necessario per il funzionamento del resto dell'impianto)
Per la cosa potrebbero venirci in aiuto altri progetti open come beagleboard o foxboard.
Passiamo alla parte un po più tecnica:
Le mie ricerche proseguono, sto studiando un po' il vscp su can e mi sembra molto allettante. Il protocollo è libero, anche
se il software è semilibero (ci sono restrizioni per l'uso commerciale) pensate possa essere un problema?
Per quanto riquarda EIB documenti sull'architettura non mancano, il problema è che non riesco a capire se veramente
sia così aperto come viene spacciato o ci sono restrizioni.
La cosa simpatica dell'eib è che mi pare possa trasportare anche l'audio ed in più c'è un solo doppino per l'alimentazione e
e i dati.
Il GROSSISSIMO problema è che per quanto stia sbattendo la testa sul monitor, non riesco a trovare nessuna informazione
riguardo al layer fisico e di protocollo. Come funziona elettricamente sto maledetto standard? ci sono componenti che mi permettono
collegarmi sul suo bus direttamente? ...alla fine ho mollato anche perché forse è meglio capire prima come stiamo messi a livello di royalty.
Un altro standard che mi sono guardato un pò è lonworks di Echelon
La politica è un pò più aperta, non bisogna affiliarsi allo standard, come succede per molti altri,
ma si posso anche usare comonenti già "licenziati" per lo standard e che permettono di realizzare dei moduli a
proprio piacimento per qualsiasi uso. http://www.stocktwentytwo.com/product_detail.php?pid=521
Simpatica come soluzione ma nel nostro caso ci vincolerebbe alla Echelon.
Alla fine, un pò demoralizzato, ho cercato di fare una ricerca "al contrario"
ho cercato sul mercato la componentistica per collegarmi su un qualche bus per
vedere cosa ci fosse di facile reperibilità.
ho visto per esempio su rs-online http://it.rs-online.com/web/search/searchBrowseAction.html?method=browseSuperSection&N=4294593588#Interfacce
sembra che rs-485 e CAN siano gli unici di cui si trova facilmente qualcosa.
Personalmente sono sempre più propenso per CAN, quindi VSCP
E' uno standard più recente ed ha la gestione delle collisioni in hardware (per dirne solo alcune)
Scusate la lunghezza del messaggio.
A presto.
Ciao Luke!
onorato per essere stato citato! :d
al solito, da profano, rimbalzo sempre tra i soliti problemi per cui non trovo soluzioni.
-
Lo standard EIB non mi convince e non è - purtroppo - affatto del tutto libero;
-
senza presunzione, ma della società Echelon non mi fiderei; tra l'altro, per quello che ne sapevo, è quella che produce l'elettronica montata sugli attuali contatori italiani; Echelon è partecipata a sua volta da aziende italiane...
-
Purtroppo audio/video e semplicità (ed economia) cozzano tra di loro e in anni non ho trovato alcuna soluzione...
-
ma l'X10 è così terribile? e perchè?
Al di là delle applicazioni A/V sarebbe un sistema semplice e (quasi) economico: Arduino farebbe bridging con il PC e comanda l'automazione... Poi, sono sempre dell'idea che Arduino riceva i comandi manuali attraverso RF/WIFI (e quindi qualsiasi protocollo)
Bene bene...direi che l'interesse continua a rimanere vivo!
Colgo l'occasione per ripetere che la sezione di domotica sul Playground l'ho creata apposta per riassumere tutto il dialogo e il lavoro che si svolge qui sul forum attorno a questo argomento...così chi è arrivato dopo non deve per forza leggersi tutto!
Chiunque iscritto al playground è praticamente libero di fare aggiunte/modifiche.
Mentre rispetto alle ultime cose lette condivido ciò che ha scritto LukeSkyChopper, l'intento è proprio quello di creare un sistema modulare in grado di soddisfare tutte (o quasi) le esigenze.
Lo scoglio più grosso è proprio quello di scegliere un protocollo di comunicazione pratico, versatile, affidabile e pure open source. Aggiungerei anche costo zero!
In questi ultimi giorni non ho potuto cimentarmi sull'argomento, però per quel che sono riuscito a fare direi che sul CAN fortunatamente si riesce a trovare anche materiale pratico, mentre per tutto il resto le informazioni sono un po' più generiche.
E' interessante da leggere il sito trovato su vscp!
Modbus RTU è un bel protocollino apparentemente semplice e ben studiato su RS485 ed è uno standard industriale.
...che dire la mia indecisione, dovuta a scarsa esperienza rimane!
[OT mode ON]
@astroz78
- libreria Eternet: apertura/chiusura socket in continuazione provoca a volte e non ho capito ancora a quali condizioni il blocco della comunicazione...praticamente non c'è più connettività da e per arduino- Ethernet Shield: se usate la ethernet shield così come vi arriva, sappiate che all'alimentazione dell'Arduino non tramite USB, ma tramite alimentazione diretta, l'Ethernet Shield non và in UpLink (sostanzialmente è come se non si connettesse allo Switch) finchè non si resetta il nodo...sostanzialmente se salta il contatore o "và via la luce", al suo ritorno tocca resettare manualmente tutti i nodi- non esiste un sistema (quantomeno semplice...qualcosa ho letto ma devo approfondire) per gestire un WatchDog Timer...sostanzialmente se qualcosa và in palla non è facile gestire un "auto-reset"
i problemi riscontrati sulla Eth. Shield sono comuni. Nel forum in lingua inglese se ne è parlato molto, e vengono proposte delle soluzioni, che io stesso adotto per assicurarmi che lo shield funzioni.
Per quel che riguarda il problema del reset iniziale (e nel caso di blocco in genere), risolvi pilotando il reset della Eth. Shield con un pin, e quindi direttamente da sketch.
Per quel che riguarda il blocco della comunicazione, devi prevedere nello sketch delle routine che, in assenza di determinate caratteristiche, resettano lo shield sfruttando il workaround di cui sopra.
[OT mode OFF]
Salve, appena iscritto cerco di dare una mano...
scusate il doppio post ma non riuscivo a inserire link
Eccovi il mio concept:
a) 1 Arduino per stanza con interruttori, pulsanti, sensori di movimento, sensori di temperatura come ingressi (analogici o digitali) e un adeguato numero di relè come uscite
b) Comunicazione tra gli Arduino utilizzando lo standard RS485 (molto economico ) con 1 Master che gestisce il tutto e gli slave come componenti passivi (in configurazione multimaster, gestire le collisioni dei messeggi risulta molto difficile)
c) Protocollo di trasferimento: HDLC personalizzato in questo modo:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
|---|---|---|---|---|---|---|---|---|---|---|
| FLAG | ADDRESS | Control field | DATA | Checksum | ||||||
| ENQ,ACK,NACK | Action | Pin | Pin number | Value | ||||||
| 0x01 | 0x01-0x?? | 0x05,0x06,0x15 | ASCII(R/W) | ASCII(A/D) | 0x?? | 0x?? | 0x?? | somma valori | 0x04 |
Semplificando arduino slave riceve un comando del tipo
W D 13 1 (scrivi, pin digitale, 13, HIGH)
R D 10 ? ((leggi, pin digitale, 10, valore che restituisce nell'ACK)
R A 3 ? (leggi, pin analogico, 3, valore che restituisce nell'ACK (2 byte essendo compreso fra 0 e 1023))
W A 3 255 (scrivi, pin PWM, 3, 255)
d)Livello di trasporto protocollo: reliable data transfer (RDT) 3.0 (poco efficiente ma efficace e di media difficoltà nell'implementazione)
School of Computer Science - University of St Andrews pagina 28
e)L'Arduino Master si occupa di gestire la logica del sistema quindi potenzialmente può essere collegato con altri dispositivi per il controllo (tramite seriale al pc, o bluetooth al cellulare o ad un modem GSM)
f)Gli Arduini Slave sono composti essenzialmente da una scheda Arduino 2009 e uno shield con relè, pin per i pulsanti, il chip SN75176/MAX 485 (il primo costa meno di 1?) e doppio connettore RJ45 (quello del telefono per intenderci)
g)Il bus di comunicazione è composto da 4 fili: - +12V(preferibili ai 5V nel caso i releè fossero a 12)
- GND
- RS 485 A
- RS 485 B
Così abbiamo alimentazione e segnale tutto sul "doppino" telefonico
Molti spunti li ho presi da Tinkering with Electronics...: Arduino and RS485 (ENGLISH VERSION) ....
a mio parere la parte più difficile è scrivere il codice per gestire l'RDT e ovviamente il master che essendo il cervello di tutto è decisamente spesso da programmare; lo slave tutto sommato è semplice essendo un componente "passivo"
feedback e suggerimenti sono sempre ben accetti
Ciao a tutti!
scusate se insisto o mi esprimo primitivamente:
-
comandi e per quanto possibile attuazioni le trasmetterei via onde radio (è tecnicamente possibile e/o troppo costoso?): in questo modo non c'è nè il bus fisico che pone eventuali limitazioni, nè limita i pin di arduino (in questo modo posso avere più funzioni con meno arduini per casa ovvero con un arduino in conf slave servire almeno due locali); riduce i fili del bus fisico con risparmio di cavi, cablaggi etc.**
Altri vantaggi: -
prendo arduino, gli monto il chip RF, lavoro in sicurezza anche come hobbista inesperto (nessun collegamento in alta tensione);
-
posso assemblare gli attuatori per la powerline e montarli come l'X10 oppure chiamare l'elettricista e farli montare (e l'elettricista non mi impazzisce);
-
per sonde e sensori, non è necessario avere fili di bus ovunque ma posso così posizionarli dove è più conveniente, modificare all'ultimo minuto, anche in base alle esigenze mutate (esempio: cambio di casa in affitto)
-
magari troppo complesso: arduino rileva comandi utente attraverso wifi (penso a un app su android oppure qui: Tinkering with Electronics...: LINKDUINO: Embedded Web Server), telecomando rf universale (utile per disabili, riduzione costi degli interruttori con annessi e connessi, semplificazione impianto)
-
c'è poi eventualmente un modo per arduino di comunicare fisicamente sulla powerline? in questo modo, dove non servisse, si possono leggere/scrivere sensori/attuatori/comandi ove RF non fosse il caso.
Esempio: porto line di potenza in prossimità di finestre: che poi la usi per tapparelle, apertura anta, riavvolgimento tende interne/esterne, recuperatore calore o termovalvola, lo posso decidere anche dopo semplicemente montando il chip attuatore (e relativo motore) in seguito, con ulteriori economie in caso di ristrutturazione/upgrade, con estrema flessibilità, affidabilità e riduzione dei costi iniziali d'investimento.
Powerline ed RF usano lo stesso protocollo prescelto per omogeneità e semplicità di funzionamento...
Che ne dite?
** porto quest'esempio tra tanti: http://www.conrad.de/ce/de/product/560068/FUNKGESTEUERTES-HEIZUNGSTHERMOSTAT-SET/0812040;jsessionid=C0EB0060A011378BD89A5A9C0F9434CD.ASTPCCP2: sensori e motori attuazione (alimentati 2xAAA 1,5V) per valvole dei termosifoni, con sensore apertura finestra (forte variazione temperatura entro 3 minuti), trasmettono alla centralina via onde radio.
Si capiscono i vantaggi; svantaggio: sistema chiuso e banale che si riduce a acquistare una grande ridondanza di apparecchi costosucci x 1 appartamento; ed ecco xk cerco soluzione open con Arduino...
C'è qualcuno che mastica bene lo spagnolo??
http://www.arcan.es/ ...si commenta da solo!!! ;D
L'ultima versione dello shield aggiunge anche l'rs485!!!
Appena ho 1 attimo di tempo, vedo di tradurlo. Servono passaggi in particolare?
Ma la traduzione di google nn funzia?
Ho letto i vostri reply, ma chiedo scusa se li ho letti con estrema "fretta" e quindi magari non ho analizzato a fondo i vostri pensieri, ma sono nel panico + assoluto a lavoro, a casa ho le luci che s'accendono e si spengono come gli pare...quindi stò full immersion!
Dunque, solo una cosa riguardo il bus che ho scelto e, cioè, l'ethernet!
La mia scelta è ricaduta su questo bus in quanto sta di fatto diventando lo standard per veicolare qualsiasi informazione:
- VoIP
- IPTV
- dovrebbe diventare anche il bus standard che rimpiazzerà l'HDMI per la connessione tra dispositivi audio/video e TV HD (ora non ricordo il nome ma avevo letto un articolo)
Il problema "switch KO => impianto fermo" mi sembra un falso problema...anche se si brucia una "centralina" dell'impianto domotico l'impianto è fermo...io in 10 anni (a casa di mamma) non ho mai avuto uno e dico un KO da uno switch...e poi lo switch oggi come oggi costa 15 Euro...male che và se ne tiene uno di scorta e la sostituzione richiede 3 minuti ed è fattibile anche da una "nonna".
A mio avviso, oggi, le case moderne devono comunque essere tutte cablate ethernet per TV, dispositivi vari, access point, PC, etc. ...considerata poi la mole di dati riguardo la domotica (assolutamente irrisoria) e il fatto che oggi oramai le reti si fanno GigaBit, mi sembra un bus più che affidabile, testato e che già risolve tutta una serie di problematiche (es. collisioni, disturbi sui cavi, etc.etc.).
Il problema mio è che l'interfaccia Ethernet di Arduino (non sò se è un problema dello shield o della libreria Ethernet.h di interfaccia) fà cagare!!!
Per chi ha ipotizzato di usare segnali radio, beh...perdonami, ok il discorso di non dover "scassare" casa, ma mi pare una cazzata...tutto ciò che è legato a segnali radio mi ha sempre dato la certezza d'essere un qualcosa di "instabile"...il wifi, i cordless, gli apricancelli, i cellulari, il trasmettitore della oregon scientific del sensore temperatura esterna, vado avanti? Anche perchè rischi di mettere in piedi un sistema che si parla "radio" e funziona, poi interviene un fattore esterno (es. un vicino con un ripetitore di sky) e ti sputtana tutto xkè magari trasmette sulle stesse frequenze o qualche armonica disturba i tuoi segnali...assolutamente no! Tanto per farti capire la mia filosofia: ho + scassato casa x arrivare alle finestre con i cavi x i sensori dell'allarme (e avrei potuto usare sistemi wireless) che x la domotica!
Ah...altra cosa, riguardo la mia esperienza con Ethernet: quando il sistema funziona (spero di riuscire a stabilizzarlo a breve se no sò guai...) la comunicazione tra un nodo e l'altro della mia domotica è praticamente immediata. Esempio: ho il pulsante della luce del salone elettricamente connesso al nodo "2", ma la lampadina che deve comandare è elettricamente connessa al nodo "1". Quindi il nodo "2" che è in polling sulle porte di input, quando rileva la pressione del pulsante, legge in configurazione "cosa deve fare", impacchetta il comando (che non è di sua competenza) e lo manda al nodo "1" che lo riceve, lo interpreta e, visto che è di sua competenza lo esegue.
Ecco non faccio in tempo a rilasciare il muscolo che ha premuto il pulsante (quindi nemmeno a iniziare a togliere il dito) che la luce è già accesa...passeranno che sò 50 millis e mi tengo largo.
Mano mano che mi vengono cose da dirvi ve le dico, ripeto mi dispiace e mi scuso se non riesco a seguire la conversazione più attivamente, ma sono veramente inguaiato!
Ciaoooooooo
Ciao
cosa intendi per "fa cagare"? complimenti per l'approfondita e dettagliata analisi
Comunque l'idea era quella di fare un protocollo light con oggetti semplici e a basso costo basati su arduino cosi ognuno ha poi la possibilità di capire cosa succede nei vari nodi.
Ethernet non è veramente economico e il cablaggio è forse un po troppo macchinoso per un piccolo appartamento.
Mi rendo conto come sia difficile per le persone pensare semplice...
m
Massimo ma riusciamo ad usare un arduino per casa e non un arduino per stanza?
Mah...quando dico che la gestione "Ethernet" di Arduino "fà cagare" (mi avrete senz'altro perdonato il francesismo) intendo dire che è instabile e inaffidabile! Dovrò approfondire un po' la questione, ma per l'esperienza maturata finora quello è l'aggettivo meno cattivo che mi viene in mente...
Daccordo con il protocollo light e gli oggetti a basso costo...è la stessa idea che è alla base del mio progetto, però la considerazione è:
- il cablaggio ethernet non è vero che è così costoso (300 mt di cavo rigido costa 30 ?)
- gli apparati concentratori ethernet (switch) costano due soldi (con 10 ? ti porti a casa uno splendido switch 10/100 8 porte...ci aggiungi 10 ? e ti prendi un Gigabit)
- il cablaggio ethernet l'avrei comunque fatto (e dovrebbero farlo tutti) per condividere i contenuti in rete, per il dreambox, x collegare i PC (vedi post precedente odio il wifi in quanto comunicazione radio), x i telefoni VoIP, insomma per tutto e in futuro vedrete quante altre cose saranno veicolate ethernet (tra un po' anche la piantana dell'ikea avrà la presa ethernet)
- arduino + ethernet shield costano in tot 60 ? ...considerati almeno i 30 ? di arduino 2009, uno shield rs485 o per qualsiasi altro protocollo, tra l'altro sviluppato "ad-hoc" (ethernet shield è prodotto in serie) vi sfido a farlo costare meno di 30 ?
- i vari sistemi che prevedono un dispositivo "master" non mi piacciono: nella mia domotica ci sono 5 nodi che fanno tanto da server (ricevono i comandi) quanto da client (mandano comandi)...e quindi dialogano tra di loro. Se si pianta un nodo, si isola quella parte di impianto, il resto rimane operativo. In un sistema che prevede un "orchestratore" (master) se esso si pianta o si guasta addio alla funzionalità di tutto il sistema!
- io in casa (e non è piccola...160mq) ho 28 prese di rete a parete più le prese di rete per i nodi "domotici"...ho speso a occhio...150 ? per 5 patch panel (avrei potuto risparmiarmeli, ma mi piaceva il cablaggio "fatto bene") 30 ? per il cavo da intubare, 150 ? per 5 switch (io perchè sono megalomane e ho messo tutte quelle prese e ho voluto necessariamente ogni presa Gigabit, ma se vedessi solo l'aspetto della "domotica" avrei speso 10 ? per un solo switch), avrò speso 20/30 ? per un po' di cavettini patch cord da 30/40 cm, poi che altro? Boh!!! Mi pare basta...come "economia" ci siamo
- inoltre il sistema ethernet oggi può essere veicolato (qualora non si arrivi con il cavo o non si voglia sfasciare troppo casa) con i sistemi wireless (2 access point che fanno da bridge tra rete cablata e rete wireless costeranno 50/60 euro e non sono da "progettare" sono già fatti) e con i sistemi powerline (se non si cercano i 200 mbps su rete elettrica e ci si accontenta degli 85mbps con una 50/60 euro raggiungi ogni "luogo e ogni lago")
- e poi ripeto, l'interfaccia ethernet è in fortissima ascesa...io mi sento di investirci sopra! Ripeto senza aver considerato e fatto opportuni test sul sistema "ethernet" di arduino che è decisamente debole!
Oh...poi magari parlo così e ho fatto io qualche puttanata ed è x questa puttanata che il sistema è instabile.
Ve ne dico pure un'altra già che ci stò, però è fresca fresca non ho molti elementi da dare.
Per comandare i relè ho costruito delle semplici schede shift register con 2 x 74hc595 in cascata e, quindi, la comunicazione tra la catena Shift-Register e Arduino è basata su 3 fili (Clock, Data, Latch). Sotto gli S-R ho messo degli ULN2803A per avere un po' di corrente per pilotare le bobine dei relè.
Questa scheda (2x74hc595 + 2xuln2803) è una scheda a parte che connetto ad arduino con un cavo piatto (2x5 fili).
Ecco il sistema ha sempre funzionato, della serie che anche prima (quando non avevo ancora connesso fisicamente i pulsanti al sistema) quando potevo inviare comandi solo da remoto tramite ethernet (nel mio caso tramite pagina su web server php) non ha mai mancato un colpo: l'uscita delle varie porte sullo S-R rifletteva sempre esattamente lo stream di bit che gli inviavo dall'arduino.
Da quando ho fisicamente collegato i pulsanti al sistema, ora è impazzito e succede che premo un pulsante, l'arduino modifica lo stream di bit da inviare allo S-R e glielo manda. Ecco in questa fase il sistema si disallinea (es. mando 10000101 e in output S-R mi ritrovo 11000101...o qualsiasi altra combinazione). Faccio presente che i pulsanti sono cablati con cavo allarme (sezione 2x0.5mm + 4x0.22mm con comune a massa dell'arduino) e che oggi sono collegati direttamente ai pin dell'arduino senza passare per alcuna scheda di "interfaccia" ne' di demultiplexing.
Immagino si tratti di una qualche problematica legata a disturbi e segnali spurii che viaggiano sui cavi...d'altra parte il sistema a bassa tensione spesso viaggia insieme (negli stessi tubi) del cablaggio AT. Quindi in campana anche a queste problematiche...vi terrò aggiornati su come procedo (intanto voglio collegare le calze della schermatura dei cavi a terra).
Ciao Astroz!
Interessantissimo il tuo sistema.
Condivido appieno la scelta di Ethernet per A/V,poichè è (credo) l'unico modo x uscire dall'impasse dei trasporto di multimedia.
Ritengo che come backbone sia una via percorribile e ne hai dimostrato l'economicità.
Io mi trovo molto bene anche con i sistemi radio e credo sia interessante e pure opportuno in certi casi, che si possa pensare un bridge anche per l'RF.
Penso anche al concetto di eliminare il master: rende più affidabile il sistema e penso anche io che di serie vada tenuto un arduino piuttosto che uno switch di scorta... (lo si fa anche con le piastrelle...)
Quando avrai più tempo, potresti cortesemente scrivere un tutorialino passo passo per autocostruirsi un sistema come il tuo? Per quelli come me che nn sanno neppure dove ordinare i pezzi e installare il software...? :d
Grazie!
@atroz78
...quando dico che la gestione "Ethernet" di Arduino "fà cagare" (mi avrete senz'altro perdonato il francesismo) intendo dire che è instabile e inaffidabile!
sul fatto che è inaffidabile out of the box sono d'accordo, e se fai un giro anche nei forum di altre lingue i pareri sono gli stessi.
Principalmente: se si alimenta da rete (e non da USB), senza un reset non funziona; dopo un tempo indefinito (può trattarsi di ore o di giorni) si "pianta".
Come ti ho detto qualche post fa, però, sono problematiche che hanno workaround - possiamo aprire un thread apposito, se vuoi.
Ho installazioni con ethernet shield che funzionano da mesi, nonostante il caldo, qualche mancanza di corrente, e uso intensivo. Tutto senza dover andare fisicamente neppure a guardarla.
Riguardo al concept (domotica con Ethernet shield), mi trovo in linea con te.
Esiste già un protocollo collaudato (tcp/ip o udp), cavi, prese switch son cose facilmente reperibili e a basso costo, si integra nativamente con la rete domestica, etc etc.
Ma considerare qualche protocollo diverso (che sia CanBus/DMX/altro) con le opportune valutazioni, può anche portare a qualche alternativa valida...
ciao
m