Domotica con Arduino

Ciao a tutti!
Effettivamente, non ci sono molte news: c'è qualche aggiornamento?
Intanto: Buon Natale!
Ciao,
Stefano

si è bloccato il post fateci partecipi

Bhe sotto le feste penso che chiunque sia occupato un po' più occupato.. chi in vacanza, chi ha il negozio...
Puntiamo tutto sul 2011.. anche perchè poi nel 2012 finisce il mondo (AHAHAHA)

tutte scuse :slight_smile: io lurkavo questo post da un po' e ora e' tutto tornato silenzioso :slight_smile:

Ciao a tutti.
Colgo l'occasione di fare gli auguri a tutti per presentare un progettino ancora decisamente embrionale, ma che sembra essere compatibile con quanto ho letto finora in questo thread.
Al momento sto lavorando su uno shield per la domotica che contiene:

  • 2 AT24C1024 (sono troppe, ma le avevo ... e volevo sperimentare un po' I2C)
  • 1 RTC, al momento è un DS1307 con batteria ma preferirei usare un PCF8563 per via dell'interrupt e dei timer
  • 1 sottosistema CANBUS (MCP2515+MCP2551)
  • 1 termostato DS1621
    L'idea dovrebbe essere quella, almeno in prima approssimazione, di avere un Arduino come centrale e dei nodi remoti basati su MCP25050 (CANBUS EXTENDER 8 GPIO, 4 Input Analogici, 2 uscite PWM) e relativo transceiver MC2551 per la gestione di sensori e attuatori (al momento la questione "nodi remoti" è ancora molto in fase TBD perché da una prima analisi il MCP25050 non pare sia programmabile in modo non volatile per cui potrebbe richiedere un suo MICRO, il che aprirebbe a sistemi ad intelligenza distribuita).
    Comunque il mio "sogno" rimane comunque di avere un sistema che abbatta al massimo i cablaggi consentendo di viaggiare ove possibile con solo un quadripolare e i due cavi della 220V, installando i nodi sul fondo di comuni cassette da incasso e preparando dei nodi adattabili alle varie esigenze (sei pulsanti e un relay, quattro relay, otto pulsanti, ..., nella maniera più modulare possibile).
    La parte più complessa è il software da installare su Arduino per gestire il tutto. L'idea sarebbe quella di implementare un interprete di comandi che permettesse di programmare l'AVR una sola volta, indipendentemente da quali siano le programmazioni dell'impianto domotico che verremmo ad installare.
    Partiamo dal protocollo di comunicazione: va benissimo quello definito da Ambrogio a lunghezza fissa di 10 Byte (la lunghezza fissa mi è molto utile in programmazione).
    A dire il vero avrei preferito tentare di usarne uno esistente magari open (ad esempio Velbus) che ci apriva all'utilizzo di componentistica esistente di terze parti, garantendo al progetto maggiori probabilità di successo, ma, visti i costi, direi che vada benone anche così.
    Il protocollo di Ambrogio andrebbe espanso considerandolo un linguaggio di programmazione più che un protocollo di comunicazione.
    Ammettiamo che il primo byte del protocollo di Ambrogio non sia fisso a 0xF0, ma che 0xF0 sia il comando "invia messaggio", alla ricezione di un messaggio Arduino dovrebbe passarlo ad una funzione che lo confronta con una tabella di accettazione (stile firewall Iptables, se qualcuno ci ha lavorato) e ritorna un intero che è l'indirizzo del comando da eseguire. La tabella di accettazione andrebbe salvata sulla EEPROM, diciamo nei primi 100 Byte.
    I comandi risiedono anch'essi nella EEPROM e sono tutti di 10 Byte, per cui se la funzione ritorna, a titolo di esempio, 42, e la tabella comandi segue nella EEPROM la tabella di accettazione, AVR leggerà i 10 Byte che partono dall'indirizzo 520 (100+42*10) poi eseguirà quanto indicato, leggendo poi (ed eseguendo) i comandi presenti agli indirizzi 530, 540, 550, ... fino al raggiungimento di un comando di "STOP".
    A questo punto abbiamo 255 possibili comandi (ricordando che "0xF0", potrebbe essere "invia messaggio"), tra cui dovremo decidere "GET MESSAGE", "STORE MESSAGE", "STOP", "BRANCH", "ACCEPT MESSAGE" (con le wildcard per la creazione della tabella di accettazione), ecc.
    La parte che vedo più critica al momento è la gestione delle interruzioni soprattutto nelle operazioni lunghe (ad esempio la gestione di un cancello: se debbo attendere un minuto per chiudere non posso bloccare il tutto in attesa che sia passato il minuto, nè penso facile programmare "in concorrenza" su AVR).
    Si dovrà definire o uno stack di comandi o delle interruzioni basate su timer AVR o (anche) su RTC (per questo preferivo il PCF8563 che ha un proprio interrupt).
    Come dicevo più che un progetto sono "idee in libertà".
    Mi piacerebbe avere la vostra opinione.
    Ancora un augurio di un felicissimo Natale e un fantastico Anno Nuovo.
    TT:

Ciao a tutti,
io credo che per evitare problemi serva un gateway che traduca ed integri i vari protocolli, di modo da poter inviare e ricevere i comandi e le info da dispositivi di diverse marche.
Io mi occupo di domotica da anni e purtroppo uno dei problemi più grossi è il dover sostituire parti di impianti perchè non si parlano tra loro.
Non è possibile usare N-gatewarduini che parlano tra di loro in seriale? :slight_smile:

Ciao Daviddream.
Hai sicuramente ragione sulla questione protocolli, anch'io infatti avevo pensato di utilizzarne per lo meno uno esistente, magari diffuso, per cercare di inserirsi sull'esistente e per dare flessibilità e gradualità al progetto: intanto creiamo un ArDomoController che funziona con sensori e attuatori sul mercato, (e con altri ArDomoController, per sistemi a intelligenza distribuita) poi iniziamo a progettare sensori ed attuatori (che saranno molto probabilmente più economici di quelli sul mercato...)
Ma il problema è (e tu che sei esperto potresti fare un analisi): quale/i protocollo/i potrebbero essere papabili?
Dovrebbero essere Open, documentati e abbastanza diffusi, compatibili con carrier a basso livello vari (RS485, CanBus, Ethernet,...) e non troppo complessi da gestire.
Ciao.
TT:

Secondo me questo progetto non può andare avanti perchè tutti hanno esigenze diverse: c'è chi parla di diversi nodi, di un nodo centrale, chi di ethernet chi di RF...
Secondo me l'unica soluzione è copiare uno standard come X10 rendendolo "meno costoso" cioè almeno penso che queste ditte che vendono questi adattatori sparino prezzi assurdi ma non credo che l'elettronica all'interno di questi aggeggi sia così costosa
Quindi direi di partire pensando a come scopiazzare adattatori tipo X10, che più o meno servono a tutti (in una scatola di derivazione o dietro alla poltrona della nonna) e che sono anche la parte più difficile, poi si passa alla gestione dove si può fare un progetto generale e poi lo si modifica a seconda delle esigenze

Ma no, secondo me non è vero. Si era trovata una strada che poteva mettere daccordo più o meno tutti. Siamo fermi alla realizzazione dell'hardware ... speriamo che non sia tutto morto ! Io potrò contribuire con qualche mia idea quando parleremo di protocollo ... per ora attendo ma non mi sembrava male ciò che è stato fatto fino ad ora.

@ Ambrogio.
Se il problema è l'hardware quanto ho descritto nel mio messaggio precedente esiste già e funziona, o per lo meno minaccia di farlo (i led lampeggiano, la memoria si legge e scrive, l'orologio comunica l'ora e il termostato scatta). Ora, visto che dal punto di vista hardware sono decisamente un principiante potrei vedere di pubblicare lo schema (Fritzing?) per poterlo controllare ed eventualmente migliorare tutti insieme.
@ Guglio
Non sono del tutto d'accordo. Che tutti abbiano esigenze differenti è normale in impiantistica. In fase progettuale bisognerà essere altamente flessibili per poi poter implementare il maggior numero di esigenze possibili. E fin qui non è stato detto nulla che tagli fuori una qualche esigenza. Il protocollo di Ambrogio non ha problemi con RS485, CANBUS o Ethernet, nè con una implementazione centralizzata nè con intelligenza distribuita. E', semplicemente, ad un livello superiore. Poi, eventualmente, si penseranno alle implementazioni di basso livello per creare la colla logica fra protocollo e livelli hardware sottostanti. Sono invece d'accordo, come ho già detto, sul fatto che non fosse da disprezzare l'idea (sempreché possibile...) di usare un protocollo esistente, per le note ragioni. Ma visto che, prendendo in mano un listino dell'esistente, potremmo uscire con dei periferici ad un costo di un decimo dell'esistente, direi che potremmo andare benone così.

A questo punto secondo me bisogna procedere con la progettazione dell'intelligenza da mettere sulla/sulle centrali/e (Arduini) e sulla decisione della gestione dei periferici (pulsanti, relay, dimmer, ...).

Ciao
TT:

Secondo me è inutile accavallare n progetti quando si era partiti con uno, anche per non buttare via il lavoro che i ragazzi che si sono trovati in skype hanno portato avanti fino a questo punto.

Putroppo in questo periodo sono stato un po preso e non ho potuto parteciparvi ma confido in un aggiornamento dopo le feste :wink:

Ciao Ragazzi,
Buon Anno a tutti!
Da un po' nn c'è più movimento qui: quali sono le novità? Riprendiamo?
@Morodor, che news ci sono?
Ciao!

si dai ragazzi!

riprecontiniziamo!

Ehi Ragazzi! Ma dove siete tutti??

io sono qui :slight_smile:

@bl4d3: ho visto il tuo sito con il progetto; quindi c'è lo shield, iterfaccia ethernet+arduino; almeno è un inizio: mancherebbe qualche motorino di attuazione ad esempio x tapparelle o apertura/chiusura valvole termosifoni, gas etc e sensori specifici x gas, allagamento etc (ma questi si collegano sull'arduino locale, giusto?);
in pratica un arduino+shield in ogni stanza a 40? caduno chiavi in mano.
c'è anche modo di integrare microfono e una cassa locale, giusto?
mentre, della telecamera, dicevi che fosse già disponibile, come pure il sensore movimento.
se è così, si può già iniziare a giocare...!

CHIBI Arduino, molto interessante... ma sono transciever multimaster? C'è un limite massimo di Chibi Arduini connessi fra loro?
E sopratutto non c'è modo di crearsi in casa / comprare solo la parte TX/RX abbattendo così di molto i costi?
Grazie

@stefano72 penso che con un relè si possa comandare il motore della tapparella o un'elettrovalvola o chi per esso, per integrare lo stream di una telecamera arduino non centra molto, recuperi direttamente lo stream mjpeg o mpeg4 o via rtsp e lo emebeddi nel telefono, alcune telecamere hanno la possibilità di triggerare chiamate http sul presentarsi di determinati eventi (motion detection. oscurata, ecc..) li si che potresti mandare una chiamata ad arduino per azionare qualcosa

@Giuglio i dispositivi che si possono collegare sono boh...mi sembrava di averlo letto una cifra > 100, se qualcuno vuole creare un modulino rx e tx che usa lo stack di chibi si faccia avanti, è sempre utile abbattere i costi!

Signori, io ogni tanto, raramente, capito su questo forum e vedo che chiedete che fine abbiamo fatto...io, parlando per me, mi dovete scusare, ma stò veramente nella BIP...a lavoro massacro continuo e poi ho impegni musicali fittissimi che non mi consentono di fare altro!!!

Pure l'impianto di casa mia è quasi fermo...non trovo mai tempo per lavorarci!!!

Sarà così per almeno tutto gennaio, spero subito dopo di avere un po' di tempo...per allinearvi/allinearci!!!

Astroz in bocca al lupo allora!

Se c'è qualche brav'anima che è in grado di estrarre uno schema per uno stack partendo dal chibi, quelli che hanno scelto la soluzione wireless (come me) protrebbero trovare una risposta alle proprie domande!

EDIT:

Mi correggo, gli schemi ci sono http://www.freaklabs.org/chibi/fl-avrusb32-dev.pdf
Anzi è nato prima come stack e poi è diventato arduino
http://freaklabs.org/index.php/Chibi-A-Simple-Open-Source-Wireless-Stack.html

Solo che io non ci capisco na cippa di come costruirne uno xD