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.
Secondo me la differenza economica fra arduino+netshield e fonera2 (o altro router similare) non e' poi cos' marcata. Commisurando il tutto ai tempi di sviluppo e alle potenzialita' direi che non ne vale quasi la candela seguire altri approcci, perche' ho molte piu' possibilita', molta piu' liberta', molta piu' semplicita' nell'usare cio' che e' giusto usare: una macchina server linux nata per fare il server, anche il server web, con ghiotte possibilita' wifi, blueT, ecc.
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.
Se usi quei chip sei legato. E' una tua scelta.
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.
La prima implementazione dell'algoritmo CRC-modbus usava delle tabelle che richiedono flash/epromrom per essere stoccate, ma io riesco benissimo a calcolare il crc modbus senza fare uso di quelle tabelle. Il mio consumo di risorse e' di una manciata di byte per le variabili locali della function, una pipe globale profonda 3 per mantenere l'ultimo il penultimo e quello ancora prima valore di CRC. Non mi occorre altro. Non mi pare questo gran risparmio, dunque. Al limite pesa computazionalmente, ma parliamoci chiaro pesa un nullesimo per un mostro come il 328.
Poi considera che se devo interfacciare gli oggetti domotici di biticino queti parlano modbus su seriale e pretendono che io abbia lo stesso crc che usano loro. Oppure molto semplicemente ci inviamo un paio di byte, capiscono che non so stare dietro al loro crc, o che lo faccio diversamente, e finisce con me non ci vogliono piu' parlare.
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.
Questo assolutamente si. Non mi cambia la vita cambiare le politiche di connect per supportare gli eventi. La select e i mux ci sono apposta per quello, oltre che per essere usate per scrivere programmi come le chat dove tutto sta in piedi proprio grazie alle select. In ogni caso e' impensabile non introdurre concentratri ogni tot sensori. Io conto di avere al piu' (caso peggiore) un concentratore in ogni locale perche' ogni locale mi rappresenta a spanne uno scenario logico aggregato, ma in ogni caso in uno scenario reale parliamo di una media di una 20na di oggetti domotici connessi al concentratore.
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.
Non e' una rete real time, non ha senso. Oppure, fammi un esempio pratico di 2 oggetti domotici per i quali il tempo di risposta e' cosi' critico. I mei RTT sono piu' che accettabili e compatibili con lo scenario reale.
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.
Io uso varie amenita' linux per fare routing. Lo fa solo il nodo concentratore che ha la neceessita' di "girare" pacchetti domotici o ad un altro collega "nodo concentratore" (posto anche in internet) o ad una interfaccia domotica. Non lo devo inventare io, e' gia' fatto e collaudato e assodato per come funzionano i router (e in generale l'internet working).
Tu vnet lo devi sviluppare, testare, validare, e considera quanto renda il tuo lavoro ancora piu' complicato e difficile da seguire. Ti consiglio ora che scrivi la doc di spiegarlo per bene, ti giuro che si fa fatica a pensare che sia utile (almeno io ne faccio).
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.
Appunto il W5100, giusto per parlare di portabilita': sei legato a quel chip! Io non lo uso, ho ENC e un C8900 e mi pesa e scoccia parecchio dover avere lo stack TCP/IP.
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).
Sai quanto pesa quella parte in tutto lo stack tcp/ip ? Abbastanza poco per pensare di implemetare solo questa feature senza dover avere tutto il pacchettone.
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.
Appunto: ma per me e' la sola scelta logica, la piu' comoda e sensata per come la vedo io.
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.
Lo sviluppo che faccio e' piu' facile del tuo, dovrei farti i complimenti per la quantita' di lavoro e tempo che dedichi al tuo progetto, e' notevole, specialmente per le piattaforme che intendi usare, pero' bada che anche mia piattaforma non costa poi' cosi' tanto in piu'.
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.
Questo si, non c'e' dubbio: JSON e' una figata! Anzi, lo voglio!
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.
Ecco per dirla tutta ... se ti dovessi invidiare qualcosa direi che tu non combatti con l'efanticita' di apache. Per fortuna non lo usi ! Perche' lo sa solo lui quanta ram fagocita, anzi lo so anche io: 6Mb appena lo lanci e per non fare assolutamente niente, cosa ci mettera' mai dentro ? Mah
Comunque tu non usando apache non hai le backdoor verso i binari, cosa che ha il suo fasciono e che oltre al fascino (tipo matrix) mi ha sempre intrigato abbastanza perche' e' di un comodo incredibile.
Ovviamente io tiro l'acqua al mio mulino
No, io un mulino ad acqua per fare la farina l'ho visto e lo vorrei anche comprare. E' che mi chiedono troppi soldi. Mi accontendo di tirare stream nella mia rete =P
| Arduino Forum :: International :: Italiano :: Megatopic (Moderator: leo72) :: Souliss, Domotica e IoT