Progetto ReleDuino (Aggiornamento files al 18.07.2013)

Prima dell'intervento di Astrobeed, credevo che i terminatori fossero dei robots venuti dal futuro per uccidere Sarah Connor e suo figlio John. E' proprio vero che non si finisce mai d'imparare.

:grin:

Be ora sai chi è astrobeed, io ad esempio so cosa sono i terminatori, il ruolo che svolgono ma non avevo idea che fossero necessari nelle linee 485. I terminatori li usavamo con le vecchie schede di rete NE2000, il primo pc e l'ultimo richiedono un terminatore, che poi è uno spinotto BNC con dentro una resistenza da 50ohm.

Maledetto zoomx mi ha preceduto. :smiley:

Ciao.

MauroTec:
I terminatori li usavamo con le vecchie schede di rete NE2000, il primo pc e l'ultimo richiedono un terminatore, che poi è uno spinotto BNC con dentro una resistenza da 50ohm.

Le "maledette" reti con cavo coassiale, i bnc e le pipette a T sulle schede, bastava che la donna delle pulizie tirava un cavo con la scopa per far bloccare tutta la rete :slight_smile:

astrobeed:
Le "maledette" reti con cavo coassiale, i bnc e le pipette a T sulle schede, bastava che la donna delle pulizie tirava un cavo con la scopa per far bloccare tutta la rete :slight_smile:

Cavolo, me le ero dimenticate, ho fatto una decina di impianti rete col sistema coassiale RG58, penso di avere ancora una bobina di quel cavo in magazzino, non è che interessa a qualcuno ..... ahahahahahaha che bei tempi .... almeno allora pagavano :slight_smile:

ciao

pablos:

astrobeed:
Le "maledette" reti con cavo coassiale, i bnc e le pipette a T sulle schede, bastava che la donna delle pulizie tirava un cavo con la scopa per far bloccare tutta la rete :slight_smile:

Cavolo, me le ero dimenticate, ho fatto una decina di impianti rete col sistema coassiale RG59, penso di avere ancora una bobina di quel cavo in magazzino, non è che interessa a qualcuno ..... ahahahahahaha che bei tempi .... almeno allora pagavano :slight_smile:

ciao

il cavo dovrebbe essere RG58, il 59 è più sottile ed ha un'impedenza maggiore (se non erro 75 ohm), non va bene per quel tipo di reti

io qualche giorno fa' ho pure ritrovato connettori e pinza crimpatrice...
ah, bei tempi

si ho corretto l'errore di battitura nel momento in cui stavi rispondendo Menniti,
la crimpatrice però la uso ancora per la videosorveglianza in cavo coassiale

Non credevo ci fossero "animaloni" del genere che potessero essere programmati con l'ide arduino. L'unico animalone che conosco sono io quando ero militare e mi portavo a letto le cubiste conosciute e sedotte in discoteca (peccato che poi si rivelava essere un sogno, e mi risvegliavo nella mia branda da solo).
Scherzi a parte, ci sono delle considerazioni che vorrei fare. Nel primo post ho spiegato com'è composta la ReleDuino ed il limite di dispositivi che è possibile inserire all'interno della rete domotica i2c, ma forse non sono stato abbastanza chiaro e cercherò di essere cristallino, questa volta.
Ci sono 2 tipi di schede che si ottengono dallo stesso circuito stampato a seconda dei chip che vengono posti: Le Master e le Slave.
Le master hanno, a differenza delle Slave, il chip Arduino e altri chip secondari. Ogni master può essere collegata fino ad un numero massio di 7 Slave, quindi ogni chip gestisce fino a 64 pulsanti e 64 relè (1 master + 7 slave = 8 releduino; ogni releduino gestisce 8 pulsanti e 8 relè; totale 64 pulsanti e 64 relè per ogni sottosistema comandato dal master).
Il limite è definito dagli indirizzi che si possono inserire negli integrati mcp23017 e pcf8574 (massimo 8 indirizzi per integrato, da 0x20 a 0x27 per gli output e da 0x38 a 0x3F per gli input). Installati i 7 slave, bisogna necessariamente inserire un altro master per poter permettere l'installazione di altre 7 slave, le quali saranno gestite dal chip del secondo master). In sostanza, senza farla troppo lunga, più schede slave metti e più aumentano i master, e quindi i chip arduino, i quali si gestiscono direttamente solo le slave della loro sottorete. Ogni master è poi collegato in serie tra loro: se vedete lo schema elettrico, i pca9600 (amplificatori i2c) sono due: 1 per collegare il master ai 7 slave e l'altro per collegare il master 1 al master 2, 3, 4, etc. Il master 1 gestisce direttamente i suoi 7 slave e indirettamente tutti gli slave degli altri master, dando l'ordine a questi ultimi di far eseguire ai loro slave il comando impartito. Questo sistema consente da un lato di poter superare il limite dei 128 indirizzi dello standard i2c (in realtà sono 112 utili e 16 riservati) e dall'altro di ripartire la potenza di calcolo di ogni chip relegando la sua "competenza" solo alla sua sottorete. I pca9600 hanno il "potere" di isolare il segnale i2c permettendo ad esso di "riverberarsi" solo all'interno di ogni sottorete master-slave.
Ci sarebbero altre considerazioni da fare, ma quelle poste credo siano sufficienti affinchè si capisca che il sistema da me progettato, almeno in teoria, é in grado di "auto-equilibrarsi" adattando la potenza di calcolo all'ampiezza della rete domotica, tenendo conto anche del fatto che se il chip non riuscisse a gestire le 7 slave, si può sempre diminuire il numero di slave per ogni master.
Per casa mia, ad esempio, previste 15 - 20 schede ReleDuino = 3 Master e 5 - 6 - 7 slave per master.
Questo sistema "decentralizzato" ha inoltre il vantaggio di non pregiudicare tutta la rete qualora una o più schede dovessero guastarsi (se si guasta l'animalone che facciamo? ci teniamo casa al buio?).
Magari l'animalone lo lasciamo per gestire compiti specifici e più complessi, magari prevedendo schede "supervisori" o simili in sistemi domotici molto complessi.

Federico_Paiano:
Non conosco bene CAN-bus, ma credo che anche questo non sia un protocollo completo. Questo standard descrive principalmente lo strato di scambio dati (data link layer), composto dallo strato sottostante "logico" (Logical Link Control, LLC) e dallo strato sottostante del Media Access Control, (MAC) e da alcuni aspetti dello strato "fisico" (physical layer). I protocolli di tutti gli altri layer sono lasciati alla libera scelta del progettista della rete, quindi per il momento meglio optare per soluzioni complete come i2c.
Se vorrai creare un protocollo per le ReleDuino magari possiamo pensare ad un'integrazione, o alla progettazione di schede che funzionano con un protocollo alternativo ad i2c che si appoggia al CAN, oppure potremmoo trasmettere il protocollo i2c usando il tipo di trasmissione dati CAN tramite l'integrato della nxp PCA82C250. A riguardo puoi l'eggerti l'application note AN460. Tutto si può fare, basta volerlo.

Ciao,

spero di non aver perso qualche pezzo per strada, ma entro nel discorso I2C e CAN. Se guardi l'idea di fondo, sono due protocolli elettricamente simili, sono entrabi basati su un bus pilotati in open-drain e per entrambi esistono microcontrollori che inglobano un controller in hardware
Ad esempio il micro ATMEGA64M1 ha un controller CAN in hardware (ma guarda caso, non I2C) ed è del tutto simile ad un ATmega328.

I due protocolli nascono però con scopi diversi, come già è stato detto I2C è nato per collegare dispositivi sullo stesso PCB e nasce per funzionare in master/slave. Il protocollo CAN ha invece un'interessante funzione di collision avoidance e nasce per collegamenti su distanze interessanti (1Km a 50 kbit/s) quindi può funzionare anche in peer-to-peer.

Proprio su questo aspetto vorrei soffermarmi, in un'applicazione che non richiede determinismo puntare sul master/slave comporta uno spreco di risorse o prestazioni pessime. Consideriamo un'installazione da 30 nodi (come citavi in precedenza) ed ammettiamo di effettuare un polling dei dati ogni secondo, nel peggiore dei casi (avendo un solo master) potresti aspettare fino a 30 secondi prima di ricevere il feedback ad un comando.
Il tutto interrogando le schede ogni secondo per eventi che accadranno poche decine di volte in una giornata.

La soluzione da intraprendere è quella di un protocollo ad eventi, in cui la comunicazione non avviene per polling, questo ovviamente richiede un protocollo elettricamente in grado di rilevare o evitare le collisioni (o il alternativa ciò va realizzato in hardware). Se si utilizzano i transceiver per Ethernet, Wireless 802.15.4 e CAN questa gestione avviene in hardware.

Chiusa questa parentesi, una nota d'impostazione, se vuoi realizzare la scheda per poi venderla, probabilmente conviene puntare a soluzioni tecniche leggermente diverse. Se pensi ad una scheda con comunicazione su filo, con relé ed ingressi trovi diverse soluzioni analoghe nel settore del fai da te, come quelle di KMTronic ed altri.

Se consideri una produzione in piccoli volumi, la soluzione più interessante è a mio avviso l'utilizzo di soluzioni modulari, come lo sono alcuni prodotti Olimex. Utilizzando un bus di espansione (nel caso di Olimex I2C e SPI) si riescono a realizzare dei prototipi con funzionalità diverse. In termini di costi difficilmente puoi restare sotto quelli realizzati da Olimex o altri, peggio ancora se consideri le schede a relé vendute in Cina. Ci sono differenze sostanziali tra i vari prodotti, ma credo che il punto su cui concentrarsi sia la scheda e la comunicazione, lasciando le periferisce a soluzioni di estensione.

Non bisogna dimentarsi che la domotica in quanto tale è ormai una storia vecchia, non è mai decollata e non decollerà mai. Probabilmente ci sarà spazio per un diverso tipo di automazione, che sarà legato anche all'automazione delle utenze classiche, ma passerà per elettrodomestici e dispositivi vari in grado di comunicare tra loro.
Non vedo un'utopia nel pensare che un generico elettrodomestico possa avere a bordo un micro aperto, in grado di comunicare con delle API alla scheda di controllo dell'elettrodomestico stesso.

I relé ci vogliono, ma non sono l'unica necessità, ne in piccolo si possono realizzare troppe varianti.

Un'altro aspetto, la comunicazione su cavo è interessante se il tutto viene installato mentre si realizza l'impianto elettrico, altrimenti diventa un vincolo forte. Esistono molti integrati con microcontrollore e radio, come l'ATmega128RFA1 che semplificano molto la vita e donano un'interfaccia di comunicazione via radio.

Personalmente credo che i problemi tecnici possano sempre essere affrontati e risolti, ma alla base ci vuole la voglia di volerli affrontare, complimenti per la passione.

Saluti,
Dario.

veseo:
Ciao,
spero di non aver perso qualche pezzo per strada, ma entro nel discorso I2C e CAN.

Ciao Dario,
Innanzitutto complimenti per l'invervento, che giudico molto equilibrato, pulito e orientato verso un confronto costruttivo ai fini dell'evoluzione del mio progetto, che ho reso disponibile a tutti licenziandolo tramite Commons Creative (spero di averlo fatto in modo corretto).
Fatte queste doverose e giuste premesse, vengo a risponderti.

Se guardi l'idea di fondo, sono due protocolli elettricamente simili, sono entrabi basati su un bus pilotati in open-drain e per entrambi esistono microcontrollori che inglobano un controller in hardware

Al momento sto studiando il protocollo RS485, in quanto avevo progettato l'installazione nella mia ReleDuino di un MAX485 che però non avevo inserito in modo corretto. Astrobeed mi fece notare degli errori che sto provvedendo ad eliminare. Non sto studiando il protocollo CAN, ma viste le sue caratteristiche di immunità ai disturbi EMC e di elevata velocità anche su lunghe distanze, credo che sarà affrontato nei miei prossimi studi non appena avrò terminato quelli su RS485.
Da una ricerca fatta su WikiPedia ho letto che il CAN, a differenza di i2c, non è un protocollo completo, e questo mi obbligherebbe ad appogiarmi ad un protocollo che opera sui layer del CAN (tipo CanBus, CanOpen, ProfiBuf, DeviceNet, etc). Probabilmente lo farò, ma ci vorrà del tempo e spero di trovare persone che mi appoggeranno in questo lavoro. Per il momento la scelta rimane su i2c, che testerò sulle lunghe distanze tramite l'installazione degli amplificatori che ho adottato sulla scheda (PCA9600); io non sottovaluterei i2c, soprattutto perchè il mio sistema opera su livelli logici diversi da quelli classici (12 volts con capacità parassita tollerata fino a 4000 pF); appena torno a casa, a fine mese, posterò alcune foto della scheda e non appena possibile pubblicherò un video con 2 schede collegate con una piattina telefonica (cavo non schermato e non twistato) di circa 50 metri (secondo le specifiche NXP la mia configurazione potrebbe arrivare fino a 100 metri). Con il CAN credo che farei un bel balzo qualitativo ma prima di affrontare una modifica bisogna studiarla e ci vuole tempo nella scelta della configurazione migliore da adottare; spero che troverò collaboratori anche all'interno di questa community, sia nell'implementazione dell'hardware che del software. Rimanendo in ambito software, una soluzione ottimale sarebbe quella di creare una libreria "CAN" da associare all'ide arduino, proprio come la "wire", che possa facilitare anche un programmatore non esperto nell'uso dei GPIO (mcp23017 e pcf8574) contenuti nella ReleDuino. Ho scelto questi due integrati per la gestione degli input e degli output perchè sono molto utilizzati e ci sono molte guide e video dimostrativi in rete.

Ad esempio il micro ATMEGA64M1 ha un controller CAN in hardware (ma guarda caso, non I2C) ed è del tutto simile ad un ATmega328.

Ti risulta che l'atmega64m1 si possa programmare conl'ide arduino? Se fosse possibile, terminato l'ipotetico protocollo CAN-based, potrei implementarlo nella ReleDuino al posto del 328P.

I due protocolli nascono però con scopi diversi, come già è stato detto I2C è nato per collegare dispositivi sullo stesso PCB e nasce per funzionare in master/slave. Il protocollo CAN ha invece un'interessante funzione di collision avoidance e nasce per collegamenti su distanze interessanti (1Km a 50 kbit/s) quindi può funzionare anche in peer-to-peer.

Confermo che i2c nacque per operare all'interno di una stessa pcb o nella comunicazione di pcb molto vicine tra loro, tuttavia questo standard ha subito una notevole evoluzione nel tempo; a tal proposito, ti do il link di una presentazione su questo standard che pongo caldamente alla tua attenzione, soprattutto la parte relativa agli amplificatori di segnale per lunghe distanze contenuta nel capitolo "bus buffers": http://www.jjmb.nl/datasheets/i2c/presentation_i2c.pdf. Sul CAN non mi posso esprimere perchè non ho solide conoscenze a riguardo, pur sapendo "di fama" sulla sua immunità ai disturbi elettromagnetici. Entrambi i protocolli però, e non solo CAN, hanno una funzione di collision avoidance CSMA/CA dando priorità allo slave con indirizzo più basso, senza che i dati trasmessi da esso vengano danneggiati (come avviene invece sul collision detection CSMA/CD).

Proprio su questo aspetto vorrei soffermarmi, in un'applicazione che non richiede determinismo puntare sul master/slave comporta uno spreco di risorse o prestazioni pessime. Consideriamo un'installazione da 30 nodi (come citavi in precedenza) ed ammettiamo di effettuare un polling dei dati ogni secondo, nel peggiore dei casi (avendo un solo master) potresti aspettare fino a 30 secondi prima di ricevere il feedback ad un comando.
Il tutto interrogando le schede ogni secondo per eventi che accadranno poche decine di volte in una giornata.

La lettura dello stato dei pulsanti non avviene per polling ma per interrupt: alla pressione del pulsante un pin del pcf8574 manda un segnale ad Arduino, il quale SOLO in quel caso interroga tutti i pulsanti della sotto-rete (non di tutta la rete), che sono al massimo 64, agendo poi come da programmazione.
La gestione dei sensori presenti in una scheda ancora da progettare (la futura SensorDuino) probabilmente verrà gestita da un protocollo diverso: stavo pensando al protocollo 1-wire per l'occasione, ma ancora è presto per parlarne.

La soluzione da intraprendere è quella di un protocollo ad eventi, in cui la comunicazione non avviene per polling, questo ovviamente richiede un protocollo elettricamente in grado di rilevare o evitare le collisioni (o il alternativa ciò va realizzato in hardware). Se si utilizzano i transceiver per Ethernet, Wireless 802.15.4 e CAN questa gestione avviene in hardware.

Anche i2c, come detto prima, ha una gestione delle collisioni in hardware simile a CAN; ciò che non so, e su cui spero mi potranno dare delucidazioni in questa community, è se i2c ha la ritrasmissione dei dati nel caso ci sia una o più collisioni, o se devo prevederla nel software.

veseo:
Chiusa questa parentesi, una nota d'impostazione, se vuoi realizzare la scheda per poi venderla, probabilmente conviene puntare a soluzioni tecniche leggermente diverse. Se pensi ad una scheda con comunicazione su filo, con relé ed ingressi trovi diverse soluzioni analoghe nel settore del fai da te, come quelle di KMTronic ed altri.

Se consideri una produzione in piccoli volumi, la soluzione più interessante è a mio avviso l'utilizzo di soluzioni modulari, come lo sono alcuni prodotti Olimex. Utilizzando un bus di espansione (nel caso di Olimex I2C e SPI) si riescono a realizzare dei prototipi con funzionalità diverse. In termini di costi difficilmente puoi restare sotto quelli realizzati da Olimex o altri, peggio ancora se consideri le schede a relé vendute in Cina. Ci sono differenze sostanziali tra i vari prodotti, ma credo che il punto su cui concentrarsi sia la scheda e la comunicazione, lasciando le periferisce a soluzioni di estensione.

Una precisazione alla tua nota d'impostazione che, credimi, ho apprezzato molto: il mio obbiettivo non è lucrare, o quanto meno non è sicuramente quello prioritario. Più che altro vorrei portare avanti la filosofia basata sull'open-hardware di Arduino, progettando una scheda con lo stesso chip di base, che si possa programmare altrettanto facilmente con lo stesso ide, e PER TUTTI: facile, economica e dalle enormi potenzialità.

Ancora non ho visto le soluzioni KMTronic e Olimex ma ti ringrazio per la nota che porrò in tempi brevi alla mia attenzione; io ti consiglio invece di guardare le soluzioni "OpenDomotica", soluzione domotica completa e molto evoluta, e "Chameleon", scheda domotica montata su modulo DIN, entrambe combatibili Arduino.

Non bisogna dimentarsi che la domotica in quanto tale è ormai una storia vecchia, non è mai decollata e non decollerà mai. Probabilmente ci sarà spazio per un diverso tipo di automazione, che sarà legato anche all'automazione delle utenze classiche, ma passerà per elettrodomestici e dispositivi vari in grado di comunicare tra loro.
Non vedo un'utopia nel pensare che un generico elettrodomestico possa avere a bordo un micro aperto, in grado di comunicare con delle API alla scheda di controllo dell'elettrodomestico stesso.

Io non sono d'accordo quando dici che la domotica non decollerà mai, credo invece che non decollerà fino a quando ci saranno protocolli chiusi o finti aperti (come KNX), basati su hardware che non sarà mai disponibile in modalità open. A tal proposito ti faccio l'esempio di PLC, che rispetto ad Arduino è infinitamente più affidabile e potente (alla fine un 328P non è paragonabile neanche al più blando dei PIC) ma che, a mio modesto avviso, è rimasto "di nicchia" e non ha conquistato e appassionato il mondo come Arduino proprio perchè rimasto chiuso agli "addetti ai lavori", difficile da avvicinare alla massa.
Il mio sogno, che probabilmente non realizzerò mai, è di fare la stessa cosa per la domotica con la mia ReleDuino e con le altre schede che progetterò in futuro, si spera in una collaborazione futura sempre più fitta con altri soggetti (per il momento sono solo e forse lo rimarrò per molto tempo ancora).

I relé ci vogliono, ma non sono l'unica necessità, ne in piccolo si possono realizzare troppe varianti.

???

Un'altro aspetto, la comunicazione su cavo è interessante se il tutto viene installato mentre si realizza l'impianto elettrico, altrimenti diventa un vincolo forte. Esistono molti integrati con microcontrollore e radio, come l'ATmega128RFA1 che semplificano molto la vita e donano un'interfaccia di comunicazione via radio.

Concordo sui limiti delle comunicazioni via cavo per "l'ammodernamento" dei vecchi impianti. Io avevo pensato ad XBee per superare questo vincolo. Secondo te l'ATmega128RFA1 si può programmare con l'ide Arduino?

Personalmente credo che i problemi tecnici possano sempre essere affrontati e risolti, ma alla base ci vuole la voglia di volerli affrontare, complimenti per la passione.

Su questo punto sfondi una porta aperta, e grazie per i complimenti che apprezzo veramente tanto.

Saluti,
Dario.

Saluti, Federico.

veseo,
se la domotica non decollerà mai o meno non saprei, è effettivamente una storia vecchia. Ma alcune storie vecchie alla fine sono decollate, altre no. Tablet e smartphone c'erano da tempo ma sono decollati solo da pochi anni. Windows Phone è alla versione 8 ma prima si chiamava Windows Mobile, è più vecchio dello iOS ma non ha mai sfondato.
Probabilmente ci vuole un "qualcosa" che ancora manca.
Arduino stesso non è il primo caso di una scheda con microcontrollore, pensa al BasicStamp o alla stessa scheda da cui deriva Arduino.
Apprezzo anche io i tuoi commenti, soprattutto perché fatti da uno che ha il suo principale interesse proprio nella domotica.

@Francesco,
io non credo che Arduino debba il suo successo alla relativa facilità di programmazione o all'ambiente aperto. Il fatto che l'IDE sia aperto o meno credo influenzi una esigua minoranza degli utilizzatori, la stragrande maggioranza non ci fa nemmeno caso. Forse non è neanche l'hardware aperto, altrimenti non si spiegherebbe il successo del RaspberryPI, il cui hardware ancora non è stato copiato da nessuno.
L'unica cosa che differenzia Arduino e RaspberryPI è il basso costo iniziale e il basso costo delle schede e degli shield, forse anche il fatto che c'è una grossa produzione cinese che forse non avrà una grande qualità ma che permette sicuramente di giocarci senza avere troppe pretese.
Sicuramente conta la comunità che prevale anche sul prezzo. Il Launchpad MSP430 della Texas costa meno di 4.5€ compreso spedizione espresso ed ha anche un IDE clone di Arduino (alcuni programmi funzionano senza alcuna modifica) ma la sua comunità è nettamente inferiore.
Mi piacerebbe collaborare ma le mie conoscenze di elettronica e di domotica sono scarsine.
Ho un po' più di esperienza con la sensoristica ma poca poca.

@Federico

Rispondo ad alcuni tuoi punti, l'aspetto più importante è che le soluzioni tecniche che stai scegliendo non sono adatte a quanto hai descritto (o quanto meno a quanto sono riuscito a capire).

Il primo punto è che I2C non può funizonare in P2P e non ha meccanismi di rilevazione delle collisioni, il protocollo prevede la tramsissione del clock dal master verso gli slave, di conseguenza uno slave può inviare dati solo sull'attivazione del clock da parte del master. Inoltre, gli indirizzi I2C utilizzano l'ottavo bit per definire la modalità d'accesso (lettura o scrittura).
In sostanza è il master che decide quando e se leggere o scrivere su un nodo.

E' in linea generale prevista la possibilità di utilizzare interrupt, che per la natura del protocollo sono segnali esterni, quindi va portato un segnale per ogni slave (o in alternativa si realizza un interrupt cumulato, facendo il polling su tutti i nodi in caso di interruzione).

Ultimo, l'implementazione hardware dell'I2C nasce per scopi diversi, come già detto in precedenza.

Nel raffronto I2C e CAN, sono due protocolli che definiscono i livelli PHY e MAC della struttura ISO/OSI, per non farla lunga, per entrambi ti servirà un protocollo utile ad interpretare i dati trasmessi. Un byte trasmesso in I2C o CAN è fine a se stesso in entrambi i casi, perché sono protocolli di trasporto, sta all'applicazione (o ai protocolli stratificati sopra) definire cosa fare con quel byte e come interpretarlo.

La libreria Wire è un'interfaccia verso i registri (non un protocollo) e per realizzare qualcosa di scalabile, servirà una soluzione analoga lato CAN.

Relativamente ai microcontrollori citati, tutti gli AVR possono essere programmati con la IDE, ma è necessario definire i core (layout pin, registri, interrupt, ...) e i due citati non sono inclusi nello standard, il 128RFA1 ha dei core sviluppati all'interno del progetto Zigduino.

Relativamente ai PLC, hanno avuto un enorme successo, ma non sono nati per le applicazioni in casa. In casa (a mio avviso) non serve concentrare le funzionalità, ma distribuirle per ridurre al minimo i cablaggi.

Saluti,
Dario.

zoomx:
veseo,
se la domotica non decollerà mai o meno non saprei, è effettivamente una storia vecchia. Ma alcune storie vecchie alla fine sono decollate, altre no. Tablet e smartphone c'erano da tempo ma sono decollati solo da pochi anni. Windows Phone è alla versione 8 ma prima si chiamava Windows Mobile, è più vecchio dello iOS ma non ha mai sfondato.
Probabilmente ci vuole un "qualcosa" che ancora manca.
Arduino stesso non è il primo caso di una scheda con microcontrollore, pensa al BasicStamp o alla stessa scheda da cui deriva Arduino.
Apprezzo anche io i tuoi commenti, soprattutto perché fatti da uno che ha il suo principale interesse proprio nella domotica.

Lungi la domotica dall'essere il mio principale interesse :smiley:

Sono d'accordo, non esiste ancora una forma che abbia catturato il mercato, ma a mio avviso non si chiamerà domotica perché esulerà da quel concetto.

veseo:
In casa (a mio avviso) non serve concentrare le funzionalità, ma distribuirle per ridurre al minimo i cablaggi.

quoto, sopratutto in caso di adattamento di adatti pre-esistenti, il motivo per cui (imho) la domotica fatica a decollare, oltre a costi ancora proibitivi

lesto:

veseo:
In casa (a mio avviso) non serve concentrare le funzionalità, ma distribuirle per ridurre al minimo i cablaggi.

quoto, sopratutto in caso di adattamento di adatti pre-esistenti, il motivo per cui (imho) la domotica fatica a decollare, oltre a costi ancora proibitivi

quoto anch'io, costa meno un maggiordomo :slight_smile: :), ma io il mio impianto domotico ce l'ho! con comandi molto semplici

  • "Donna accendi la luce!"
  • "Donna cambia canale!"
  • "Donna apri la porta!"
  • "Donna fai la lavatrice!"

Però un po' costa ahahahahahahhaha e ogni tanto devo fare io da CPU di riserva :slight_smile: :slight_smile:

ciao

[quote author=pablos link=topic=165076.msg1257070#msg1257070
quoto anch'io, costa meno un maggiordomo :slight_smile: :), ma io il mio impianto domotico ce l'ho! con comandi molto semplici

  • "Donna accendi la luce!"
  • "Donna cambia canale!"
  • "Donna apri la porta!"
  • "Donna fai la lavatrice!"

Però un po' costa ahahahahahahhaha e ogni tanto devo fare io da CPU di riserva :slight_smile: :slight_smile:

ciao
[/quote]

:grin:

veseo:
@Federico
Rispondo ad alcuni tuoi punti, l'aspetto più importante è che le soluzioni tecniche che stai scegliendo non sono adatte a quanto hai descritto (o quanto meno a quanto sono riuscito a capire).

Nel raffronto I2C e CAN, sono due protocolli che definiscono i livelli PHY e MAC della struttura ISO/OSI, per non farla lunga, per entrambi ti servirà un protocollo utile ad interpretare i dati trasmessi. Un byte trasmesso in I2C o CAN è fine a se stesso in entrambi i casi, perché sono protocolli di trasporto, sta all'applicazione (o ai protocolli stratificati sopra) definire cosa fare con quel byte e come interpretarlo.

Facciamo una cosa ... così come anticipato il 31 torno (finalmente) nella mia dolce casetta. Appena torno compro un pannello (l'avrei dovuto fare comunque) e ci metto un primo prototipo di ReleDuino già funzionante (molto dissimile dall'attuale soluzione, ma funziona bene per una dimostrazione); posterò poi il video su youtube e qui metterò lo sketch implementato per far funzionare la ReleDuino in quel modo; poi metto su un altro pannello una seconda ReleDuino (sempre il primo prototipo) anch'essa funzionante e le collego insieme tramite i connettori i2c; ovviamente posterò uno sketch anche in quest'ultimo caso, così ognuno di voi potrà fornirmi indicazioni avendo un quadro più chiaro di come funzionano, ovviamente tutti sono invitati anche a stravolgere le mie soluzioni, però per favore chiunque lo voglia fare m'indichi anche il perchè si deve scegliere una nuova soluzione proposta piuttosto che quella esistente; purtroppo non sono mai stato bravo a scrivere in modo chiaro e forse in questo caso un video varrà più di mille scritture.

Il primo punto è che I2C non può funizonare in P2P e non ha meccanismi di rilevazione delle collisioni, il protocollo prevede la tramsissione del clock dal master verso gli slave, di conseguenza uno slave può inviare dati solo sull'attivazione del clock da parte del master. Inoltre, gli indirizzi I2C utilizzano l'ottavo bit per definire la modalità d'accesso (lettura o scrittura).

Scusa ma forse parliamo di due collisioni diverse :smiley:
Citando lo standard ISO/OSI (non sai che piacere mi fai quando citi gli standard, perchè è così che si dovrebbe sempre fare), ho sbagliato dicendo più volte che i2c è un protocollo "completo", ed in effetti non è dissimile in questo caso dal CAN, anzi quest'ultimo ha anche dei protocolli già pronti che si appoggiano sui suoi layers ed in effetti, usando termini calcistici CAN/I2C 1-0. Ora soffermandoci sul layer MAC, che dovrebbe essere un sotto-livello del layer 2 (DataLink Layer, seguendo proprio l'ISO/OSI), cito il suo obiettivo: "Permettere il trasferimento affidabile di dati attraverso il livello fisico. Invia frame di dati con la necessaria sincronizzazione ed effettua un controllo degli errori e delle perdite di segnale. Tutto ciò consente di far apparire, al livello superiore, il mezzo fisico come una linea di trasmissione esente da errori di trasmissione", infatti l'ACK è già contenuto nell'i2c come conferma di segnale trasmesso correttamente.
Poi il termine "errore" è contenuto anche nel "Transport Layer", ma con un significato diverso da quello del DLL (non c'è bisogno di spiegartelo perchè ho visto che mi potresti dare molti insegnamenti a riguardo).
Forse è qui che non sono riuscito a spiegarmi quando parlavo del collision avoidance.

In sostanza è il master che decide quando e se leggere o scrivere su un nodo.

Si, esatto.

E' in linea generale prevista la possibilità di utilizzare interrupt, che per la natura del protocollo sono segnali esterni, quindi va portato un segnale per ogni slave (o in alternativa si realizza un interrupt cumulato, facendo il polling su tutti i nodi in caso di interruzione).

La scheda ha già previsto un apposito connettore dove collegare un conduttore in serie insieme a quelli dell'i2c, che funge proprio da interrupt per la rilevazione del cambiamento di stato degli input; in pratica ho già adottato l'alternativa che hai citato, ma il polling non va fatto su tutti i nodi perchè i vari PCA9600 non comunicano tra loro ma solo attraverso il chip arduino (se vuoi ti fornisco le apposite "application note" di NXP), il polling va fatto al massimo sugli 8 pcf8574 che gestiscono gli input della sotto-rete (8 byte al massimo di dati richiesti per ogni pulsante premuto o rilasciato, un'inezia anche per il più lento dei protocolli).

Ultimo, l'implementazione hardware dell'I2C nasce per scopi diversi, come già detto in precedenza.

Io non guardo come un protocollo nasce, guardo come cresce e si evolve, ma non voglio sembrare fazioso.

La libreria Wire è un'interfaccia verso i registri (non un protocollo) e per realizzare qualcosa di scalabile, servirà una soluzione analoga lato CAN.

Hai ragione.

Relativamente ai PLC, hanno avuto un enorme successo, ma non sono nati per le applicazioni in casa.

Mai sentito parlare di Home PLC ? Credi che abbia "sfondato il mercato"?

In casa (a mio avviso) non serve concentrare le funzionalità, ma distribuirle per ridurre al minimo i cablaggi.

Concordo al 100%, ed in effetti le ReleDuino offrono una soluzione "all in one" a "blocchi da 8" (8 relè e 8 pulsanti per ogni scheda), poi le releduino le metti dove vuoi come se fossero un "punto di derivazione". Ovviamente bisogna collegare in serie le releduino per permettere alle stesse di comunicare tra loro, ma è un collegamento seriale a mio avviso molto semplice e poco costoso da attuare (se si usano le piattine telefoniche).

Saluti,
Dario.

Grazie per i tuoi interventi, confermo che sono molto equilibrati e puliti.
Ora forse è tempo di farvi vedere di cosa stiamo parlando e appena torno a casa pubblico un video con una ReleDuino in funzione (mai provata con carichi reali ma sempre a vuoto, spero che la predizione degli autoreset di astrobeed non si verifichi).
Saluti, Federico.

Federico, hai preso in considerazione le onde convogliate?
E' una fesseria?

Io l'unica esperienza che ho sono un paio di Power line attraverso cui ho fatto passare il video di una webcam, una trentina o forse più di filo non recentissimo su cui immagino ci siano disturbi.

Fermo restando che se oggi dovessi cablare da zero una casa farei passare un cavo ethernet.

Ragazzi sto studiando RS485 e l'implementazione della rete con questo standard. Ho letto che la scelta del valore resistivo per ottenere la prepolarizzazione sui conduttori dipende anche dal numero di componenti che sono allacciati alla rete. Il MAX485 ha un'impedenza d'ingresso di 12k e, se ho capito bene, va considerato come se fosse una resistenza posta in parallelo da aggiungere ai terminatori da 120R posti ai capi della linea. Poichè nella rete che si verrebbe a creare non c'è un numero prestabilito di ReleDuino Master (quelle col MAX485) che si dovranno mettere (dipende dal numero di stanze e comunque è sempre possibile aggiungere altre schede), c'è un valore "universale" che in pratica funzionerebbe indipendentemente dal numero di dispositivi connessi alla rete? Come si fa nelle situazioni reali in questi casi? Spero che ci sia una soluzione "comoda" a riguardo.
Grazie a tutti.

Ho fatto dei calcoli teorizzando vari dispositivi MAX485 collegati alla rete: in pratica con 2 resistenze da 560R collegati a +5V e GND dovrei mantenere la linea polarizzata anche in assenza di drivers attivi.
Se ho sbagliato qualcosa magari fatemelo sapere, grazie a tutti.

zoomx:
Federico, hai preso in considerazione le onde convogliate?
E' una fesseria?

Non conosco questa tecnologia. Farò delle ricerche a riguardo.
Grazie.