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

Infatti.

Ho un nodo speciale (il router openwrt o altra amenita' simile) su cui gira il software applicito domotico, e ci gira in varie forme, dalla applicazioni web che sono scirtte in python alle backdoor di apache verso applicativi binari scritti in C. Questi ultimi sono compilati con supporto di rete e fanno abbondante uso sia di tcp/ip che di udp/ip. Volendo sono anche capaci di loggare su fliesystem e di altre operazioni notificate poi alla applicazione web tramite feedback sulla backdoor di apache.

Questa soluzione non e' la migliore, piace a me perche' conosco poco i linguaggi web e mi torna piu' comodo usare python (o ruby) solo per tenere su l'nterfaccia web. La vera parte computazionale e' scritta in C. Posso anche usare altre interfacce non necessariamente web. Per esempio interfacce scritte in QT che "parlano" con la parte computazionale.

I nodi domotici (arduino nano) invece sono "dummy", non hanno sistema operativo eseguono tutto il codice in un unico while(1) diverse volte al secondo facendo anche abbondante uso di interrupt, il tutto pero' limitandosi ad interfacciare sensore ed attuatori. Interfacciare sensori significa anche condizionarne il segnale, filtrare, adattare, validare, ecc ecc.

La mia interfaccia domotica, il mio modo di percepirla passa attraverso il web, una paginetta web su cui vedo degli oggetti con cui iteragisco, ma come ho detto nulla vieta che io possa usare uno smartphone su cui l'interfaccia invece che essere una paginetta web sia una applicazione QT. Tanto sotto si tratta di mandare e ricevere pacchetti di rete, l'interfaccia e' solo un modo per presentare i dati ed iteragire con essi.

Ho poi nodi domotici che fanno da tramite verso altre apparecchiature che parlano nativamente modbus tramite seriale. Questo e' essenziale perche' ci sono molti oggetti gia' fatti che parlano modbus. Il protocollo modbus non si tocca, bisogna adattarsi e gestirlo integrandolo nella rete.


Il punto resta lo stesso: ridurre tutto all'essenziale. Niente http nei nodi "dummy".
Logged

Napoli
Offline Offline
Sr. Member
****
Karma: 5
Posts: 349
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

Offline Offline
God Member
*****
Karma: 5
Posts: 873
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


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.


Io invece parto dal conceto che le funzionalita' debbano essere isolate e ben confinate. Ma tu hai vorresti farmi credere che vuoi davvero una melassa di nodi supportati potenzialmente dallo stesso codice e che poi vai a differenziare solo per necessita' ? Brrrrrr anche perche' alla fine proporre un nodo concentratore per ogni agglomerato sensato di oggetti domotici non e' poi sto gran malaccio rispetto alla quantita' di capelli che ti devi strappare tu sviluppatore per far funzionare la melassa di cui sopra.

Lo sappiamo tutti  quanto costano gli oggetti domotici che vende per esempio biticino: costano troppo!
Se parliamo di costi non credo che un nodo concentratore in piu' o in meno (per una differenza attuale di una ventina di euro) faccia la grossa differenza.

La farebbe se tu volessi riprogettare anche gli oggetti domotii. Io mi limito ad integrarli giocando su tempi di integrazione rapidi. Per capirci costa di piu' una mia ora di lavoro persa per debuggare di un concentratore.

Se si guarda a come è scritto Souliss, le funzionalità possono essere sovrapposte, ma su ogni nodo viene caricato solo il codice effettivamente necessario.

Si ma e' bruttissimo da gestire per quanto riguarda il profiling del codice: meno codice c'e'  piu' e' isoltato (ed isolato nel suo contesto) meglio e' ! L'esperienza sul campo mi insegna che piu' #ifdef ci sono piu' aumenta la % di potenziale deadcode, e piu' if ci sono piu' aumenta la complessita' cicolmatica e piu' diventa complesso, lento, fastidioso fare debugging. Se il cliente ti paga ad ore l'esperienza mi insegna che e' meglio lavorare per comparti stagni, fare oggetti strettamente dedicati e  curarli, studiarli da soli, testarli per bene da soli, e poi metterli assieme.

Dividi e comanda, no ?

Tu invece tendi ad una system integration, cosa che fa tanto figo in USA ma che va bene solo quando gli svluppatori sono tanti. Io sono da solo, al piu' c'e' il mio collega, ma fare integration in due e' altamente controproducente.

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).

Mah ... teoricamente, a fatti quante volte premi l'interruttore della luce generando un evento ? Quante volte apri il cancelletto, fai scendere le tapparelle, o i sensori di pioggia azionano i motorini elettrii delle tende ? Quante volte la stufa a pellet parla con la centralina di casa per segnalarle la temperatura e i sensori limitrovi di temperatuara calcolano il gradiente termico di casa per capire un attimo se e' il caso di regolare la fiamma o la portata d'aria il tutto per risparmiare pellet e corrente ? Quante volte al giorno la lavatrice in lavanderei ti comunica ovunque tu sia in casa, anche sul terrazzo, che ha finito il lavaggio ed e' passata alla asciugatura e ti sta gentilemente invitando di scendere a svuotare il cestello e di andare al supermercato a comprarle il detersivo perche' senno col cavolo che ti fara' il prossimo bucato ?

Va sempre applicata la teoria delle code, la stessa che tiene in piedi le centrali del telefono: ti pare logico che una entalina con N canali veri effettivi si faccia porplemi a supportare sulla carta il doppio degli utenti abbonati ? Se tutti gli abbonati alzassero contemporaneamente la cornetta per telefonare la centralina andrebbe in crisi,  ma i fatti mostrano che nella prosaicita' del reale si deve sempre usare un approccio probabilistico! La probailita' che qualcosa accada, commisurata con la legge di Murphy, ma giusto per sapere quanto la sfiga potrebbe colpire duro =P

In questo caso ho valutato le possibilita' di congestione. Per assurdo il tcp/ip ha un meccanismo di gestione congestione ma per assurdo dopo la softstart quando inizia a valutare la larghezza ottimale delle finestra ecco che se si usa uno stack tcp/ip limitato cio' potrebbe sensibilmente contribuire ad aumentare proprio la congestione col risultato che nessun nodo parla con nessuno. In altre parole se un nodo impazzisce e il codice non "fallisce in modo sicuro", dato che le implementazioni parziali assumo che cio' non possa succedere, se invece succede (e la probabilita' c'e') ecco che tutta la rete smette di funzionare.

Il tcp/ip e' frutto di un sacco di accorgimenti maturati col tempo, quando li rimuovi ti vai a mettere nei guai da solo. Ecco perche' preferisco avere il tcp/ip su linux.

Nella tecnologia Arpanet (la mamma di internet) e' successo diverse volte e leggendo tcp/ip illustrated vol1,2,3 ci si puo' deliziare di queste perle di storia informatica.
Logged

Offline Offline
God Member
*****
Karma: 5
Posts: 873
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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 smiley

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
Logged

Napoli
Offline Offline
Sr. Member
****
Karma: 5
Posts: 349
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

Offline Offline
God Member
*****
Karma: 5
Posts: 873
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

OK tutto chiaro. Pero' mannaggia si, questo e' nata come commessa di lavoro a cui sto partecipando. A dirla tutta io volevo fare il masterista, quantomeno affiancare la tizia che c'era in modo da imparare, e in questa cosa ci sono entrato per fare appunto i circuiti stampati, invece mi hanno imbrogliato: lei l'hanno spedita altrove, i pcb li fanno fare e saldare fuori e a me han rifilato il firmware e il testing da fare. Che poi vabbe c'e' anche da dire che mi avevano promesso qualche aiutino e invece sto facendo tutto io anche se poi il mio commerciale quando parla con i clienti usa il plurale lasciando intendere che dietro allo sviluppo ci sia chissa' quale vasto team. Questo impatta parecchio sulle scelte che faccio per lo sviluppo. Se sono da solo e con tempi stretta cambia parecchio.

In ogni caso sono, specialmente per "provare sul campo", sono proprio legato ai prodotti commerciali domotici gia' esistenti che ho al lavoro e qualuno me lo sono anche comprato e portato a casa e fatto installare, e li c'e' poco da fare non si toccano si cerca di integrarli e come dici tu - il testarli - e' una cosa lunga e fastidiosa. Pero' e' lavoro e ti porta a casa la pagnotta e nell'hobbistico l'elettricista o lo stesso impiantista si rifiuta di installarti cose artigianali che non sono certificate. Insomma i miei progettinini domotici per ora me li devo pure installare da solo.

Per ora sono riuscito nell'impresa di automatizzare le tende da sole, cosa pensata per mia madre che tende a lasciare tirate anche quando c'e' il vento con il nefato risultato che le tende fanno vela stortando poi il telaio. Ho messo un piccolo anemometro comprato da futura e collegato ad un nodo arduin-nano che dice alla rete quando vento c'e' in quella direzione e da che parte arriva. Il nodo dice la cosa (via modbus su udp/ip) al router dove gira l'app domotica e questa vede di decidere se mandare indietro il comando per azionare i motori elettrici che ritirano le tende oppure lasciarle come sono. Fa la stessa cosa se nevica (lo fa per temperature eccessivamente basse, e lo fara' meglio quando integrero' i servizi meteo presi da internet) ritrae le tende. I sensori di pioggia invece lavorano al contrario: stendono le tende quando piove per fare in modo che l'acqua non arrivi ai vetri.

L'istallazione dei motori elettrici delle tende me la sono fatta io, tanto le tende e il loro telaio e meccanismo erano gia' fuori garanzia. Per i cavi ho sfuttato una gia' esistente canalina. Mi e' andata non di fortuna molto ma molto di piu'.

Oh, detto questo ti dico, come avrai ormai intuito, che in parallelo sto sviluppando anche per somatizzare il pacco che mi han tirato al lavoro. Diciamo che traggo soddisfazione recuperando parte di quel lavoro (almeno le idee) per la domotia hobbista dei fatti miei. Niente clienti e commerciali paccari, insomma, e in questo caso con cose piu' sempliciotte tipo un router econodmico come la fonera2 e nodi arduino nano con su ENC. Quando vedi citati i nodi arm L2448 (e prima avevo i pic24) quelli sono per lavoro e hanno su addirittura un kernel che schedula task. A me non piace mi complica il debugging, ne posso anche fare a meno, pero' l'ha espressamente voluto il cliente e fortemente sponsorizzato il commerciale (della serie piu' stronz*** riescono a mettere fra le features piu' sembra che il prodotto sia vincente) contento lui pace sua.

Questo per dirti: io se vuoi metto il tuo software sull'hw della versione piu' economica (via tutto il superfluo, andiamo all'essenziale, cpu, ram, chip di rete, serialina e basta) di quei nodi arm. Li faccio fare in cina e mi costeranno una 20na di euro (credo). Oppure sugli arduino nano. Boh, se ha senso e hai bisogno di nodi un po' carrozzati ma comunque economici si fa.

Piuttosto mi chiedo come fai a testare sul serio la tua rete ? Voglio dire apparati domotici cosa usi ?

E qui potremmo pensare di vedere di realizzarne alcuni. Con arduino o altro. Come per le tende da sole, per capirci.


Comunque Apache sulla fonera2 io ormai ci sono affezzionato, specialmente quando schlera, ma approposito del mio approccio rispetto al tuo: proprio perche' ho una fonera mi capita di parlarne in freenode e ieri sera i ragazzi in fonoshera (quelli che sponsorizzano fonera) si sono messi a ridere perche' conoscono benissimo il mio problema con Apache tanto che hanno sviluppato un server httpd leggero che si manga in partenza solo 900Kbyte contro i 6Mbyte di" A-patch" (questo il nome originale di Apache) restando poi scarico. Mi dicevano che una volta A-patch era esattamente quello che indica il suono: una pezza. A cosa ? Ad un primitivo abbozzo di server http, e la pezza era leggera leggera, nemmeno la sentivi in ram, oggi invece e' una mattonata. Gli stessi ragazzi mi hanno pero' anche detto che rispetto ai server httpd light la differenza rispetto ad Apache la senti solo caricando parecchio il server. Apache regge bene grossi carichi, la pezza e' cresciuta ed e' cresciuta proprio in questa direzione. Si, ma chi lo carica un server httpd su una centralina domotia ? Chi fara' mai 1.000.000 di accessi http ? Loro ridevano di gusto perche e' vero ed e' proprio li che Apache mostra i muscoli, altrove e' solo un elefantico giocattolone, quindi effettivamente hanno ragione.
« Last Edit: January 12, 2012, 04:44:58 am by legacy » Logged

Offline Offline
God Member
*****
Karma: 5
Posts: 873
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

p.ssss se mai dovessi interfacciarti con oggetti commerciali che parlano modbus su seriale

Questo l'ho scritto e usato su pic24 e portato ovunque proprio per non dover usare le tabelle nel calcolo del crc modbus. Ne ho anche versione iterativa che si calcola il crc per passi, byte dopo byte. Nota he consuma poche risorse in termini di variabili locali da allocare. Puoi integrarlo se ti fa comodo in modo da poter parlare modbus con il suo crc uffiiale.

Code:
/* crc_module: crc is computated (no lookup table required) */

uint16_t modbus_crc16_computated_with_algo_get(uint8_t message[], uint16_t message_len)
     {
     uint16_t crc;
     uint16_t crc_approx;
     uint16_t i,j;
     uint16_t carry_flag;

     crc=0xffff;
     for (i=0 ; i<message_len ; i++)
         {
         crc = crc ^ message[i];
         for (j=0 ; j<8 ; j++)
             {
             crc_approx = crc;
             carry_flag = crc_approx & 0x0001;
             crc = crc >> 1;
             if (carry_flag == 1)
                {
                crc = crc ^ 0xa001;
                }
             }
         }
     return crc;
     }

« Last Edit: January 12, 2012, 07:00:29 am by legacy » Logged

Napoli
Offline Offline
Sr. Member
****
Karma: 5
Posts: 349
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: 5
Posts: 349
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
Online Online
Faraday Member
**
Karma: 38
Posts: 5605
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] IDE1.x - Nuove Funzioni - Sketch Standalone - Bootloader - VirtualBoard
http://arduino.cc/forum/index.php/topic,88546.0.html
- [LIBRERIA] ST7032i LCD I2C Controller Library
http://arduino.cc/forum/index.php/topic,96163.0.html

Napoli
Offline Offline
Sr. Member
****
Karma: 5
Posts: 349
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: 5
Posts: 349
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: 5
Posts: 349
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

Offline Offline
God Member
*****
Karma: 5
Posts: 873
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Grazie, seguo il tuo lavoro =)
Logged

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