Show Posts
Pages: 1 ... 9 10 [11] 12 13 ... 24
151  International / Hardware / Re: Richiesta consigli per domotica con Arduino on: June 11, 2013, 03:47:49 pm
Ciao Lucenet,

ho letto velocemente la discussione, provo a rispondere ad alcune domande che mi sembra siano pendenti.

Parto dall'architettura di rete, Ethernet fa riferimento a diversi standard ma quello attuale (10/100/1000 BASE-T) implementato nei PC e Switch/Hub presenti in tutte le case prevede un'architettura a stella, il cui centro è lo switch (o la rete di switch).
Uno dei vecchi standard Ethernet prevedeva il collegamento in bus con cavo coassiale, oggi non è facile trovare questi componenti ne integrarli completamente nella rete LAN domestica.

Se hai deciso di optare per Ethernet hai diverse soluzioni, lato scheda Arduino devi utilizzare un transceiver che interfacci il microcontrollore con al rete, i più comuni sono Wiznet W5100 (montato sulle Arduino Ethernet ufficiali) e Microchip ENC28J60 (montato su altri prodotti compatibili).
Tra i due c'è una differenza abissale, il primo implementa lo stack TCP/IP in hardware ed il secondo in software, in termini pratici con il secondo hai meno spazio per i tuoi programmi e generalmente prestazioni più basse.

Un altro aspetto importante è l'interfaccia di comunicazione, se pensi di adottare l'ENC28J60 (molto più economico del W5100) non è il caso di buttarsi in interfacce web, perché troppo voraci per essere gestire insieme allo stack TCP/IP in software con prestazioni decenti. La quantità di RAM di cui disporrai complessivamente sarà poca e la frammentazione dei pacchetti allungherà i tempi di risposta.

Non entro nel merito delle certificazioni, non le conosco molto, ma per certo Arduino non è certificato CE se messo insieme a dispositivi in bassa tensione (> 70 V), questo indipendentemente dal luogo d'installazione.

Saluti,
Dario.
152  Topics / Home Automation and Networked Objects / Re: Starting a Home Automation Business with Arduino on: June 07, 2013, 06:00:56 am
Hi,

you can have a look at souliss, it should work for you. Consider that Arduino boards doesn't have the certification to be installed as devices, this doesn't means that you cannot, but that your business should care about.

Regards,
Dario.
153  International / Hardware / Re: Progetto ReleDuino (Aggiornamento dei files al 18.05.2013) on: May 28, 2013, 03:48:32 pm
[quote author=pablos link=topic=165076.msg1257070#msg1257070
quoto anch'io, costa meno un maggiordomo smiley smiley, 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 smiley smiley

ciao
[/quote]

 smiley-mr-green
154  International / Hardware / Re: Progetto ReleDuino (Aggiornamento dei files al 18.05.2013) on: May 28, 2013, 02:25:14 pm
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-grin

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.
155  International / Hardware / Re: Progetto ReleDuino (Aggiornamento dei files al 18.05.2013) on: May 28, 2013, 02:24:03 pm
@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.
156  International / Hardware / Re: Progetto ReleDuino on: May 24, 2013, 06:56:11 pm
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.



157  International / Generale / Re: Arduino Yún on: May 19, 2013, 01:34:55 pm
A mio avviso questo nuovo prodotto sancisce la "fine" della shield WiFi, nata con troppe limitazioni. Dai componenti che utilizza la Yun sembra poter essere paragonata all'unione tra un Arduino Leonardo ed un TP-LINK WR703, dopotutto esistono alcuni esempi di TP-LINK con OpenWrt che dialogano attraverso USART con microcontrollori.

E' una soluzione interessante, l'effettivo "beneficio" dipenderà da quanto risulterà semplice spostare il lavoro sui protocolli ASCII attraverso gli script fatti girare su Linux.

Saluti,
Dario.
158  International / Megatopic / Re: Souliss, Domotica e IoT on: May 15, 2013, 02:49:06 pm
Ciao,

certo, essendo un aspetto di dettaglio ti invito a spostarti sul forum del progetto (il nuovo su g group) in modo da vedere quale possa essere il problema.

Saluti,
Dario.
159  International / Megatopic / Re: Souliss, Domotica e IoT on: May 06, 2013, 02:37:54 pm
Ciao,

per partire fatti un giro sul wiki di Souliss (domani esce la nuova versione) per iniziare a capire cosa puoi realizzare e come, se hai domande generali puoi farle direttamente qui, se sono di dettaglio è meglio inserirle sul forum di Souliss.

In relazione alla tua domanda, la risposta è NI. La DINo supporta la connessione in RS485, puoi quindi utilizzare i moduli a relé di KMTronic per espandere il numero di relé, KMTronic dovrebbe aver diffuso degli esempi di utilizzo, perché in Souliss non è attualmente supportata l'estensione via RS485 dei relé, ma dovrebbe essere semplice realizzarla.

Sul sito trovi tutto l'hardware supportato, così puoi decidere come muoverti.

Saluti,
Dario.
160  International / Hardware / Re: Utilizzo di due Arduino on: May 05, 2013, 07:43:26 am
Non riesco a trovarlo, ma è da qualche parte sul forum italiano.

Vanno bene I2C o la seriale, ma I2C è master/slave quindi va bene solo se uno solo dei due nodi deve effettuare la richiesta dati (altrimenti diventa leggermente più complessa la gestione), la seriale è punto-punto (ma solo tra due punti) quindi i nodi sono equivalenti.

Saluti,
Dario.
161  International / Hardware / Re: Domotica rudimentale on: May 04, 2013, 01:20:21 pm
Grazie a tutti per le risposte.
@veseo, sicuramente opterò per la soluzione cablata, vivere in un ambiente pieno di radiazioni non mi piace per nulla.
Pensa che a casa non ho neanche il wifi(lo attivo solo se mi serve veramente). Lo so che vivamo in un mondo pieno di radiazioni, ma se riesco a limitarle è meglio. Sai com'è non è vero ma ci credo.  smiley-mr-green

Fai bene smiley-grin
162  Topics / Home Automation and Networked Objects / Re: Problems with Arduino DUE and ENC28J60. on: May 04, 2013, 12:17:04 pm
English isn't mine smiley

First step is to have a look to the official SPI drivers and port your code using that drivers instead of the one included in Ethercard (or any other that you are using), then look if you have still compilation errors and move forward.

Regards,
Dario.
163  International / Hardware / Re: Domotica rudimentale on: May 04, 2013, 12:09:38 pm
Le scelte sono diverse per tali distanze e possono essere sia cablate, sia senza fili. Tra quelle cablate ci sono due macro possibilità:
- Seriale basata su RS-485
- Seriale basata su Ethernet

La prima ha come vantaggio intrinseco la possibilità di realizzare un bus di comunicazione, riducendo la lunghezza complessiva del cablaggio. Lo svantaggio è che richiede un protocollo master/slave o la gestione delle collisioni in software se serve un peer-to-peer.

La seconda ha come vantaggio la gestione in hardware delle collisioni, ma richiede generalmente una maggiore lunghezza del cablaggio perché l'architettura è una stella (con centro l'hub o lo switch).

Le soluzioni senza filo sono diverse, anche qui ci sono due famiglie da dividere per frequenze:
- Transceiver a 2.4 GHz
- Transceiver a 900 MHz

I primi sono più economici e diffusi (anche in termini di librerie) ma hanno una portata minore, in linea generale possono rientrare nei 30 metri, ma dipende molto dalla disposizione.

I secondi hanno una portata maggiore, ma sono attualmente meno usati in ambito DIY e quindi c'è minore disponibilità di librerie software.

Esistono anche radio a 433 MHz, ma il discorso è un poco più complesso, normalmente sono delle trasmittenti e riceventi pure ed in termini astratti sono una sorta di RS-485 senza fili, c'è da considerare il duty massimo di trasmissione e sopratutto non essendo un tranceiver vero rende le cose leggermente più complesse nella gestione (ad esempio la gestione della modulazione in trasmissione va fatta in software). Qualche libreria anche per questi c'è.

Se l'obiettivo è la domotica nel senso classico (relé ed ingressi) e ti interessano le soluzioni senza fili, puoi dare un occhio ai prodotti di AirQ Networks. Sono delle schede con transceiver 433 MHz (quindi è tutto gestito in hardware) con relé ed ingressi optoisolati, raggiungibili con una shield.
In questo caso puoi realizzare un nodo centrale da cui controllare tutte queste periferiche remote.

Se ti interessano soluzioni più flessibili, puoi dare un occhio ai prodotti Olimex, dove trovi transceiver per Ethernet, 2.4 GHz e 900 MHz ed anche RS-485.

Saluti,
Dario.
164  Topics / Home Automation and Networked Objects / Re: Problems with Arduino DUE and ENC28J60. on: May 04, 2013, 10:25:14 am
Basically only official sketches that runs over Arduino UNO can run directly (or with few effort) on Arduino DUE, this because the Arduino core (the libraries) was migrated for the ARM CPU used in the DUE. Every other Arduino sketch won't run without a porting.

Some non-official Arduino sketches that runs UNO may run also on DUE, it depends if they are based on custom libraries or if are based only on the Arduino core, in the latter case it should run. The EtherCard library has an its own SPI driver (doesn't use the Arduino ones) and this is creating your problems.

I've never been in detail with ARM, so I don't know if there are others to be considered. As minimum you need to review all pins assignment and all direct access to register and interrupts, it should be not so hard, because the library doesn't use a lot of those.

I can try to help if you want.

Regards,
Dario.
165  International / Hardware / Re: Utilizzo di due Arduino on: April 29, 2013, 06:00:09 am
Se non ricordo male, circa un anno fa venne rilasciata una semplice liberia per condividere le variabili tra due schede. Utilizzava la comunicazione seriale, che vista la comunicazione tra due estemi di una bici, dovrebbe andare bene.

Era molto semplice, partiva dal presupposto di dichiarare le variabili in due sketch in modo da avere gli stessi indirizzi assoluti e poi sincronizzava i valori da un master verso uno slave. Se trovo il link (era sul forum) lo inserisco, però per funzionare serve che ci sia lo stesso microcontrollore da entrambi i lati.

Saluti,
Dario.
Pages: 1 ... 9 10 [11] 12 13 ... 24