Domotica con Arduino

Quando sarà terminata la prima fase di progettazione, avete già pensato a quanti prototipi costruire? Più o meno quant'è il costo della scheda?

Non lo so, ci sarà la primissima prototipazione dove il gruppo di lavoro testerà e correggerà eventuali bug. Poi vedremo se ci sarà richiesta si deciderà se fare una serie piu grossa, sinceramente non vorrei trovarmi 100 500 schede ferme in garage a fare compagnia ai ragni, quindi si valuterà...
Per i costi tutto dipende, le prime dieci betatesting costeranno sicuramente di piu che le altre 100, perchè oltre al fatto che meno se ne fanno e piu costano e meno componenti si prendono meno sconti si hanno, c'è il fatto che nelle prime dieci le varie persone del gruppo ci mettono anche molto lavoro, telefonate, materiali di consumo, materiale per prove ecc...
Vedendo la scheda a occhio e croce per un 100 200 pezzi secondo me si sta sotto ai 100 euro.
Poi ripeto, dipende tutto dai numeri in gioco.

Ovviamente schemi, file gerber e quantaltro saranno disponibili. Quindi uno è liberissimo di andare a costruirsela da chi vuole o farsela in casa.

se funziona il tutto per venderle non ci vuole molto

Grandissimi.. thread molto interessante!

Interfacciare la domotica anche con il telefono di casa?
In questo modo basterebbe avere il cordless sotto mano e digitare un numero corrispondente alla stanza per accendere la luce.
Potrebbe anche funzionare come controllo remoto...

interessante la soluzione di aggangio elettricamente diretto di arduino con la linea telefonica.

ma per "l'interfacciamento domotico" dell'impianto telefonico, nella sua accezione più ampia, io transiterei tramite un serverino linux centrale su cui sia installato il mitico asterisk, se necessario interfacciando poi questa macchina linux con arduino (via seriale/usb).

con questo piccolo sforzo, gli scenari che si aprono diventano molto interessanti:

  • controllo locale scenari da linea interna
  • controllo remoto della casa con una telefonata al numero voip riservato e comandi inviati via dtmf
  • avvisi vocali sul cellulare per monitoraggio/anomalie/allarmi
  • etc etc

in ogni caso mi sono già segnato il riferimento all'interessante chippettino segnalato nel filmato youtube.... grazie!

Per un progetto ho utilizzato proprio Asterisk.
Con uno script AGI, chiamando un determinato interno, si accedeva ad un IVR per comandare l'apertura di cancelli e luci esterne.

L'Arduino era in questo caso connessa via ethernet shield (le uscite son pilotabili anche da web app integrata in sw di videosorveglianza) , ma si potrebbe anche attaccare direttamente via usb/seriale al server Asterisk stesso o a un embedded device (tipo AGA o NSLU2) con installazione Asterisk minimale e il solo interno IVR...

L'unico limite con gli strumenti che ci sono è la fantasia :smiley:

@pitusso
ESATTO!

Domandona un pochino off-topic, ma non troppo: cercando un modo per far parlare arduino con un computer, ho trovato il progetto "Firmata" (http://firmata.org).

E' perfetto per far fare ad Arduino il livello più basso di manipolazione di sensori e attuatori, lasciando la supervisione a qualcosa di più evoluto di un ethernet shild sul fronte dell'implementazione del TCP/IP: un serverino linux, di tipo embedded.

Per far parlare quest'ultimo con un arduino+firmata, vorrei usare qualcosa di facile da maneggiare a livello prototipale, e ho incontrato queste due librerie in python:

http://bitbucket.org/tino/pyfirmata/src
e
http://code.google.com/p/pyduino/

Ho anche trovato molte cose non basate su firmata, tra cui:

https://code.google.com/p/ioduino/

qualcuno li ha mai usati?

con firmata in generale puoi rendere arduino uno slave seriale che risponde ai comandi che tu gli invii.

un esempio banale pc-arduino:

pc: cosa leggi sulla analog0?
arduino: leggo il valore 123
pc: allora scrivi alto su digital13
arduino: digital13->high

con firmata puoi usare una pletora di linguaggi di alto-medio livello e puoi usare anche processing.

p.s. io un po' di tempo fa avevo utilizzato GitHub - lupeke/python-firmata: Python bindings for the Firmata protocol

avevo ben inteso le potenzialità di firmata, al punto che qualche tempo fa l'avevo usato per interfacciare arduino con flash... la cosa carina era che la libreria flash era sufficientemente evoluta da consentirmi di impostare delle funzioni di callback actionscript, invece di fare continuamente io il polling (che comunque avviene, ma in maniera trasparente alla programmazione fatta da me).

la libreria che mi hai indicato sembra interessante, se non altro perché mi pare sia più seguita delle altre cose che ho trovato io, visto che gli ultimi interventi sono "appena" di qualche mese fa (altre librerie sono in stallo da oltre 1 anno...).

come detto la mia idea sarebbe quella di usare al posto dell'ethernet shield un serverino linux embedded interfacciato con il mondo esterno (nel nostro caso, sensori e relé) tramite un arduino con il firmware firmata che parla con il serverino linux tramite programmini in python.

in tal modo arduino non risente dei limiti degli stack tcp/ip minimali (e a sentire l'esperienza concreta di astroz, pure poco affidabili) dei chip dedicati a soluzioni totalmente basate su microcontrollore.

in pratica, il meglio di due mondi: interfacciabilità hardware massima grazie ad arduino; con linux, networking avanzato, multitasking, riprogrammabilità totale, e molto altro.

Ciao a tutti :slight_smile: ho letto questa discussione...
L'argomento mi interessa molto e vorrei partecipare e dare una mano.
In programmazione me la cavicchio, ho scritto anche un piccolo e semplice programma in java che comunica con arduino: questi legge alcuni sensori di luce e temp e invia dati al pc, dal programma in java posso inoltre inviare comandi per accendere i pin di output.

Volevo sapere cosa è possibile fare per dare una mano :wink: :wink:

Ciao,
a che punto è la progettazione HW?? c'è già un prototipo? Ci aggiornate su quello che succede?

buongiono a tutti....
ho letto con interesse le varie considerazioni fatte sull'argomento e ne attendo fiducioso i possibili sviluppi. personamente ritengo che utlizzare un bus ethernet non sia una gran cosa... vedrei piottosto più adeguata e versatile una soluzione su rs485: in pratica un bus a 4 fili con segnale e alimentazione. ogni dispositivo del sistema dovrebbe quindi avere una propria sezione di regolazione dell'alimentazione e il transceiver rs485. non vi pare?

ps - avrei la necessità di far realizzare delle schede PCB: avete qualche suggerimento economico di cui me le può fare

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: