Pages: 1 2 [3] 4 5 ... 7   Go Down
Author Topic: Souliss, Domotica e IoT basata su Arduino ed Android  (Read 26259 times)
0 Members and 1 Guest are viewing this topic.
0
Offline Offline
Faraday Member
**
Karma: 47
Posts: 5954
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

yes
allego lo  schema a blocchi.

Attualmente le applicazioni che ho trovato, (vedi il link che ho messo dello shield) non implementano il TCP/IP completo
Quindi si potrebbe decidere se provare a scriverlo (o trovarlo se magari e' stato fatto), oppure lavorar su mac, oppure la terza strada, quella appunto del link mio:
--------
" instead of implementing full TCP protocl, a single data packet TCP protocol is used. You webpage contents, including all html tags, must be in one packet. The length of packet is limited by the SRAM size, currently half of the RAM space (500 bytes) is used for network Packet buffer. It is sufficient for simple webpages as shown below."
--------
« Last Edit: January 07, 2012, 03:47:52 pm by Testato » Logged

- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

Napoli
Offline Offline
Sr. Member
****
Karma: 7
Posts: 356
Post fata resurgo
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Cosa intendi per sottoscrizione dei dati ? In che parti hai semplificato modbus?
Nella mia rete ho vari slave modbus che se interrogati accedono ai propri database o ai propri sensori e riportano al master quanto questo chiedo loro. Il tutto sftuttado la single regiser function code e la multi register function code. Ho 4 funzioni per fare tutto.

Con MaCaco ci sono diverse modalità per ricevere e/o inviare i dati, per convenzione indico con N1 il nodo che possiede i dati:
- Sottoscrizione, il nodo ricevente N2 effettua una richiesta ad N1. Alla richiesta segue una risposta contenente i dati, a questo punto N1 invierà i dati solo se gli stessi varieranno. Il nodo sottoscrittore N2, valuta lo stato di salute del canale (un timer con valore di time-out variabile) ed eventualmente rinnova la sottoscrizione.

- Polling, il nodo ricevente N2 effettua una richiesta ad N1. Alla richiesta segue una risposta. Per avere i dati periodicamente, il nodo N2 effettua richieste continue.

- Pushing, il nodo N1 scrive nel nodo N2. L'invio dati può essere gestito da un timer (sconsigliato) o dagli eventi (i dati sono cambiati) a cura dell'utente.

La struttura del protocollo è più semplice, anche se concettualmente identica. Ad esempio, per non mantenere uno stato delle richieste, i functional code di richiesta e risposta sono diversi e legati da un fattore 0x10 (ad esempio 0x05 è la richiesta di sottoscrizione, 0x15 è la risposta) e nell'header del messaggio è contenuto il puntatore all'area dati in cui gli stessi andranno memorizzati quando giunti a destinazione.

Ulteriori semplificazioni:
- Assenza della gestione errori, se viene richiesto di scrivere dove non consentito o leggere dati non presenti, non viene notificato nulla. Semplicemente il frame viene scartato.
- Assenza di CRC, il tutto viene affidato ai CRC di livello MAC o IP in base al driver usato.

Tutto il resto è analogo, le richieste sono per gruppi di dati contigui.

Saluti,
Dario.
Logged

Souliss - Open-source Distributed Home Automation with Arduino and Android

http://www.souliss.net
Follow at @soulissteam

@veseotech

Napoli
Offline Offline
Sr. Member
****
Karma: 7
Posts: 356
Post fata resurgo
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@ Testato, @ legacy,

Il protocollo TCP/IP è necessario se poi si vuole usare HTTP per interfacce grafiche generiche, ad esempio basate su browsers. Sono d'accordo, non è necessario un TCP completo, ma dedicare 500 byte solo come buffer dati su un 328 da 2k è troppo. Inoltre a questi 500 byte vanno aggiunti quelli necessari a mantenere lo stato delle socket.

L'utilizzo diretto in vNet è fattibile, il livello MAC è più che sufficiente, ma si perde la possibilità di avere funzionalità di interfaccia semplici.

Ad esempio, l'idea iniziale per Souliss era di portare l'intero framework su diverse piattaforme. Però poi ho virato verso JSON, quindi usando HTTP come protocollo, per ridurre i tempi di implementazione di un'interfaccia veloce da costruire.

Il punto cruciale è nelle risorse necessarie, vorrei poter aggiungere al codice la possibilità di effettuare alcune configurazioni run-time e l'auto-addressing (sia per nodi Ethernet, sia per nodi Chibi) e sopratutto non voglio giungere ad una libreria che non lasci spazio all'applicazione utente.

Il motivo per cui l'interfaccia web non è caricata da SD, ma va caricata in locale dal PC è per l'eccessivo utilizzo di risorse di TinyWebServer. Ciò per dire che volendo rimanere nel target del 328, il raggio d'azione non è vasto.

Mi impegno nel valutare le librerie esistenti per integrarle in vNet, ma i tempi saranno lunghi, per ora è previsto un lungo periodo in cui il codice non verrà modificato perché mi dedicherò esclusivamente alla riscrittura della documentazione.

Saluti,
Dario.
« Last Edit: January 07, 2012, 07:14:43 pm by veseo » Logged

Souliss - Open-source Distributed Home Automation with Arduino and Android

http://www.souliss.net
Follow at @soulissteam

@veseotech

0
Offline Offline
Faraday Member
**
Karma: 47
Posts: 5954
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

ottimo,
quando serve un qualsiasi test sulla versione ENC fai un fischio.
Io nel frattempo se trovo altre librerie arduiniche sul ENC28J60 le posto qui
Logged

- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

0
Offline Offline
Faraday Member
**
Karma: 31
Posts: 2908
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Tu fai generalizzazioni che secondo me non hanno senso pratico.
Dici smiley-eek

Comuque, io di udp, ip, tcp non ci capisco nulla, ho studiato in passato ovviamente, ma non ho mai implementato un protocollo, layer ecc. Forse però nel tuo caso hai demandato le funzionalitò http ad una periferica non prevista da veseo (quella cosa che hai detto tu con linux su, che non so cosa sia).

Io seguo, ma non ho il background per contribuire, mi manca il tempo e la volonta per dedicarmi alle problematiche di rete.

Invece capisco che se devi accendere la luce il comando lo invii solo una volta e a quello che ho capito varie logiche sono implementate in MaCaco.

Vi seguo, in silenzio.

Ciao.
Logged

AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

0
Offline Offline
Faraday Member
**
Karma: 31
Posts: 2908
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Prima della migrazione dei server avevo risposto, ma è andato in timeout e poi down totale.

Sinteticamente hai raggione qui:
Quote
Non mi serve alcuna delle funzionalita' offerte dal tcp/ip se devo far parlre 2 nodi domotici, il protocollo modbus va piu' che bene e a livello fisico gli basta anche una serialina.

Al momento non vedo necessità di portarsi dietro http sui nodi, ma ovviamente un nodo speciale deve avere interfaccia tramite http to udp, per gestire la casa tramite application web.

Penso che questo pensiero lo condivida anche veseo.

Quindi su upd hai frame modbus, ottimo, flesibile direi.

Ciao.
Logged

AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

Napoli
Offline Offline
Sr. Member
****
Karma: 7
Posts: 356
Post fata resurgo
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@ legacy, @ MauroTec,

Mauro ha colto il fulcro del discorso, le due soluzioni (Souliss e quella di legacy) hanno due architetture diverse. Detto questo, alcune cose dette sono corrette altre no. Provo a fare un punto della situazione.

La comunicazione tra nodi non avviene in HTTP, ma in MaCaco che è di suo un protocollo ispirato al Modbus e necessità solo di un layer inferiore che sia almeno MAC (o superiore). La possibilità di lavorare in HTTP (e quindi in TCP/IP) nasce se un nodo oltre a fare il suo lavoro è anche un'interfaccia verso le applicazioni utente.

Il concetto di fondo dello sviluppo di Souliss è la scalabilità. Intendo dire, se una persona vuole "automatizzare" solo una parte della casa e non tutta (ad esempio solo il cancello d'ingresso, solo il garage, solo la soffitta, ...) diventa economicamente svantaggiosa un'architettura con nodi diversi per funzionalità diverse.

Se si guarda a come è scritto Souliss, le funzionalità possono essere sovrapposte, ma su ogni nodo viene caricato solo il codice effettivamente necessario. In base alle dimensioni dell'impianto si può partire da una scheda, per finire ad un numero non facilmente quantificabile all'interno dei limiti di indirizzamento. Il limite è definito dal traffico sopportabile dai nodi, traffico che è generato dagli eventi (il sistema può non usare il polling).

Se l'architetture è complessa e le funzionalità richieste non sono gestibili da un 328 (es: scenari complessi, archiviazione eventi, ...) si possono introdurre nodi dedicati, ma è una scelta.

Tornando alle scelte sul protocollo, l'idea alla base è quella di utilizzare chip che offrano il livello MAC e comunichino in SPI, oggi giorno è abbastanza comune in molti chip. Offrono un livello MAC i chip a 2.4 Ghz della Nordic e Atmel, così come quelli Ethernet.
Quindi mi affido al CRC dei livelli inferiori (in hardware), senza introdurne un ulteriore in software.

Il vero limite del 328 non è nella potenza computazionale (almeno per questo livello di applicazioni) ma nella RAM/FLASH a disposizione, quindi rinunciare al CRC software mi aiuta a risparmiare.

A mio avviso il vero punto importante di MaCaco è la gestione per sottoscrizione degli eventi, garantisce tempi di risposta estremamente più rapidi del polling. E' un concetto che va in crisi solo se il numero di eventi cresce a dismisura, ma questo non è il caso di un sistema domotico.

Un'altro vantaggio di MaCaco è quello relativo al P2P, ad esempio, posso realizzare in modo semplice logiche distribuite su più nodi. Su un nodo metto i comandi, su uno la logica, sull'altro le uscite (è un esempio estremizzato, ma fattibile). Usando un Master/Slave è fattibile, ma il tempo di risposta introduce un fattore 3.

Le logiche per la gestione domotica sono implementate in Souliss, MaCaco è esclusivamente un protocollo di trasmissione. Sotto c'è vNet, virtualizza il mezzo di trasmissione e gestione routing (aumenta la portata con nodi intermedi) e bridging, volendo, si può benissimo applicare Modbus sopra vNet, ottenendo nodi di diversa tipologia in grado di comunicare tra loro.

Detto questo, nell'implementazione Ethernet di vNet viene utilizzato TCP/IP. Il motivo è semplice, è supportato il W5100 ed in questo caso che sia RAW MAC, UDP/IP o TCP/IP non cambia il carico sul 328. Guadagno la gestione diretta degli ACK, che in MaCaco avviene in modo indiretto e solo in caso di sottoscrizione dei dati (non in polling o pushing mode).

Cosa viene usato dentro vNet (MAC, UDP, TCP) dipende da come sono scritti i driver e non ha alcuna implicazione. Ad esempio, i driver per la radio ATMEL di Chibiduino usano il livello MAC mentre quelli per il W5100 il TCP/IP. L'unico vincolo, deve esserci armonia sullo stesso mezzo di comunicazione

Volendo supportare un chip ethernet che offra il solo livello MAC, si può usare tranquillamente il solo livello MAC. Ovviamente non ci sarebbe compatibilità con il W5100 usato come TCP/IP.
Scegliendo questa strada, si torna al punto iniziale. Per ottenere un'interfaccia grafica in HTTP/JSON diventa indispensabile un dispositivo aggiunto.
Per essere rigorosi, si potrebbe ovviare al problema, gestendo la comunicazione nel dispositivo che funge da interfaccia utente (PC, tablet, ...) direttamente con una comunicazione a livello MAC. Questo significherebbe portare il framework su tali dispositivi.
Nella realtà, questa era in parte la mia idea iniziale, ma è stata temporaneamente scartata per due motivi: impone la piattaforma ed è dispendiosa da realizzare.

Al contrario HTTP/JSON sono facilmente gestibili il AJAX/jQuery, creando un'interfaccia grafica web based e disponibile su più dispositivi. Ma HTTP/JSON è facilmente gestibile anche nelle applicazioni iPhone ed Android.

Il "giro" delle informazioni su Souliss è analogo a quanto descritto da legacy, la differenza è che posso avere un nodo su cui girano JSON Server (perché non uso un web server) e le logiche di pari passo.

Ovviamente io tiro l'acqua al mio mulino smiley

Saluti,
Dario.
Logged

Souliss - Open-source Distributed Home Automation with Arduino and Android

http://www.souliss.net
Follow at @soulissteam

@veseotech

Napoli
Offline Offline
Sr. Member
****
Karma: 7
Posts: 356
Post fata resurgo
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@ legacy

Potremmo discutere per ore, rimanendo ognuno sulle proprie posizioni. Le nostre sono due soluzioni legate a due concetti diversi ed in parte divergenti. Il mondo è bello perché è vario smiley

Venendo ai tuoi commenti:

Il costo non è solo quello del nodo in se (maggiore di 20 euro), ma il costo degli alimentatori e dell'alimentazione, il maggiore spazio richiesto. Ho sempre creduto nel "quello che non c'è non si rompe" e l'idea di distribuire i compiti tra i nodi è uno degli aspetti principali del progetto.

Suddividere il codice in librerie è già un modo per "imperare", se poi girano su un unico nodo o su nodi diversi, se fatto bene non cambia nulla. Anche io sviluppo il codice da solo, in tempi relativamente lunghi (il progetto è parito a Maggio del 2010) dedicandoci qualche ora la sera. Ultimamente ho ricevuto delle proposte di collaborazione per la parte di interfaccia smiley

Se consideriamo la funzionalità di un publish/subscribing, gli eventi difficilmente si sovrappongono ed è per questo che uso questa funzionalità in MaCaco smiley, ma ricorda che sottovalutare Murphy è il primo passo verso il baratro smiley

L'implementazione parziale del TCP/IP di cui si parlava, era relativa al supporto alla frammentazione dei pacchetti e non all'algoritmo che regola l'occupazione della banda. Tra le righe il W5100 non supporta la frammentazione dei pacchetti (se non ricordo male). Quindi il problema non si pone.

Ritornando al protcollo MaCaco, utilizzare un protocollo derivato e non il Modbus è legato ai motivi già discussi, come tutte le decisioni ha dei pregi e dei vantaggi. Personalmente, non intendo introdurre una compatibilità verso prodotti commerciali.
La compatibilità verso prodotti commerciali proprietari ha senso se si sta progettando prodotto competitiore low cost, ma per un progetto Open Source non ne vedo l'utilità. Inoltre i costi necessari per testare ciò sarebbero fuori dalla mia portata.

Leggendo alcune tue considerazioni, come costo orario e retrocompatibilità, sembra che tu stia lavorando ad un progetto proprietario da immettere sul mercato. In quel caso, utilizzare un numero maggiore di nodi hardware ha un vantaggio diretto in termini di danari, ma è il motivo (a mio avviso) per cui i prodotti commerciali hanno un nodo per il clock, un nodo per gli scenari, un nodo per ogni cosa...

Relativamente a vNet, è un modo per avere tre funzionalità: astrazione, routing e bridging. Queste sono fornite a livello IP, ma non ho intenzione di sviluppare IP su un nodo, quindi uso una soluzione diversa con diverse analogie con IP. Questo mi garantisce delle funzionalità di base anche su interfacce MAC.

Detto questo, spero che da questa discussione nasca la possibilità di migliorare lo sviluppo del mio codice, basandomi su quanto da te fatto e viceversa. Ma tranquillo, non prenderò Apache! smiley

Saluti,
Dario.
Logged

Souliss - Open-source Distributed Home Automation with Arduino and Android

http://www.souliss.net
Follow at @soulissteam

@veseotech

Napoli
Offline Offline
Sr. Member
****
Karma: 7
Posts: 356
Post fata resurgo
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I commerciali venderebbero anche la madre smiley

Ho una decina di schde, tra arduino e chibiduino che utilizzo di volta in volta con cablaggi temporanei.

Per il CRC, anche aggiungendolo non avrei la compatibilità con il Modbus. Ho functional code diversi per risposta e richesta, questo semplifica tanto la gestione e mi risparmia la gestione di stato dei messaggi.

Saluti,
Dario.
Logged

Souliss - Open-source Distributed Home Automation with Arduino and Android

http://www.souliss.net
Follow at @soulissteam

@veseotech

Bologna
Offline Offline
Newbie
*
Karma: 0
Posts: 42
L'anima sta all'uomo come l'uomo sta alla macchina
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Salve, ho provato a compilare l'esempio 6 di Souliss su Arduino Ethernet. Per non intasare il forum, ho annotato i miei problemi  sul wiki del progetto: https://sourceforge.net/p/veseo-souliss/wiki/Home/

Souliss sembra davvero un ottimo lavoro, complimenti, anche se la curva di apprendimento pare ripida! smiley
Logged

twitter: @shineangelic

Napoli
Offline Offline
Sr. Member
****
Karma: 7
Posts: 356
Post fata resurgo
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Ciao,

il progetto supporta l'IDE 0022, in effetti non è riportato in modo chiaro. I problemi che hai riportato nei commenti al wiki sono tutti legati alla nuova IDE in versione 1. Nel wiki ho riporato alcune risposte.

Ti consiglio di utilizzare l'IDE 0022, il supporto alla versione 1 arriverà in futuro.

Saluti,
Dario.
« Last Edit: January 24, 2012, 11:32:24 am by veseo » Logged

Souliss - Open-source Distributed Home Automation with Arduino and Android

http://www.souliss.net
Follow at @soulissteam

@veseotech

0
Offline Offline
Faraday Member
**
Karma: 47
Posts: 5954
Arduino rocks
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

interessante come per 4 volte ti e' stato detto di usare la versione 022 (anche la 023 va bene), e tu continui come se niente fosse.
Lo scopo principale e' farlo funzionare o farlo funzinare su ide 1.0 ? smiley
Logged

- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

Napoli
Offline Offline
Sr. Member
****
Karma: 7
Posts: 356
Post fata resurgo
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

interessante come per 4 volte ti e' stato detto di usare la versione 022 (anche la 023 va bene), e tu continui come se niente fosse.
Lo scopo principale e' farlo funzionare o farlo funzinare su ide 1.0 ? smiley

Colpa mia, sono io ad aver ripetuto quell'informazione più volte giusto per tenerne traccia. Ho risposto a tutte in un colpo.
Logged

Souliss - Open-source Distributed Home Automation with Arduino and Android

http://www.souliss.net
Follow at @soulissteam

@veseotech

Napoli
Offline Offline
Sr. Member
****
Karma: 7
Posts: 356
Post fata resurgo
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Per questione di ordine, ho riportato i problemi evidenziati in precedenza come ticket rimuovendo i commenti dal wiki.

Invito chiunque voglia ricevere supporto sul codice ad utilizzare i ticket, segnalando l'apertura anche via messaggio privato sul forum.

Grazie,
Dario.
Logged

Souliss - Open-source Distributed Home Automation with Arduino and Android

http://www.souliss.net
Follow at @soulissteam

@veseotech

Napoli
Offline Offline
Sr. Member
****
Karma: 7
Posts: 356
Post fata resurgo
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

E' disponibile la release A2.1 su SourceForge http://sourceforge.net/projects/veseo-souliss/, i contenuti sono invariati ma sono stati risolti alcuni bug.
Logged

Souliss - Open-source Distributed Home Automation with Arduino and Android

http://www.souliss.net
Follow at @soulissteam

@veseotech

Pages: 1 2 [3] 4 5 ... 7   Go Up
Jump to: