@ 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
Saluti,
Dario.