Souliss, Domotica e IoT basata su Arduino ed Android

[AGGIORNAMENTO]

Il progetto in quest'ulitmo anno ha subito diverse modifiche ed alcuni aspetti sono diversi da quanto ipotizzato nella prima parte di questo topic, maggiori informazioni sono disponibili a fine topic oppure sul sito del progetto.

[/AGGIORNAMENTO]

Buongiorno,

vi presento la prima parte di un lavoro iniziato alcuni mesi fa, si tratta di una collezione di librerie orientate alla Domotica. E' un framework composto da tre librerie (Souliss, MaCaco, vNet) con lo scopo di astrarre e rendere semplice lo sviluppo di applicazioni domotiche.

Le librerie sono fornite di alcuni semplici esempi, come la gesitone luci da due Arduino separati o l'implementazione di nodi "monitor" che ricevono lo stato degli altri dispositivi (stato luci, porte, serramenti, ...)

Il framework è stato sviluppato secondo i seguenti obiettivi:

  • Versatilità nella struttura della rete di nodi,
  • Comunicazione in P2P con esecuzione della logica localmente al modulo (non centralizzata),
  • Generalizzazione del concetto di nodo, un nodo può essere un dispositivo Arduino, Android un PC ...

Il primo obiettivo è raggiunto con la libreria vNet, astrae il mezzo di comunicazione e fornisce automaticamente funzionalità di bridging e routing. Non è necessario modificare l'applicazione che utilizza vNet in base al mezzo utilizzato.

Attualmente vNet supporta Freakduino/Chibiduino ed Arduino Ethernet (o Ethernet Shield), nel primo caso è utilizzata la libreria Chibiduino ripulita da alcuni bug; nel secondo caso è utilizzata una nuova libreria basata sulla classica Ethernet.
La differenza principale con Ethernet è nella gestione delle socket, per ottenere una comunicazione P2P si utilizzano due socket contemporaneamente, una Client in scrittura e l'altra Server in ricezione. La connessione resta aperta per il solo tempo di trasmissione, richiesta e risposta utilizzano due connessioni separate, quindi si riesce ad ottenere comunicazioni multiple pur essendo le socket del W5100 disponibili solo 4.

Le operazioni di routing e bridging sono effettuate solo dai SuperNode, si basano sull'indirizzamento (con subnet) e possono essere corredate da tabelle dinamiche per path non risolvibili a partire dal solo indirizzo.

Il secondo obiettivo è ottenuto con la libreria MaCaco, un protocollo simile al Modbus ma con due differenze principali: è un protocollo P2P, supporta il subscribing dei dati. Il subscribing consiste nel registrare in un nodo sorgente la richiesta di dati, sarà cura del nodo sorgente inviare gli stessi solo quando ci sono variazioni, ottenendo una maggiore prontezza e minore traffico su rete (quindi minore carico CPU).

La terza libreria, Souliss, utilizza le due precedenti per fornite logiche "tipiche" come gestione luci e serramenti. Fornisce inoltre metodi per la gestione semplificata dell'I/O locale e di quello remotizzato.

Attualmente il codice è disponibile per Arduino, ma è mia intenzione portare il framework su Android. L'idea è rendere un dispositivo Android nodo della rete, al pari degli altri nodi potrà ricevere gli stati o forzarli, rendendolo di fatto un'interfaccia utente.
Lo stesso può essere applicato per qualsiasi altro dispositivo, ad esempio un PC.

A mio avviso, un limite degli attuali sistemi domotici è l'integrazione. Avere un framework comune può semplificare l'integrazione di dispositivi di diversa natura.

Il codice è disponibile al link Google Code Archive - Long-term storage for Google Code Project Hosting. e rappresenta solo un primo sviluppo, idealmente il programma da seguire per le successive revisioni sarebbe:

  • Portare il framework su Android,
  • Ridurre l'impatto in RAM (su Arduino) specialmente per vNet,
  • Migliorare il supporto broadcast per vNet,
  • Supporto RFM22B vNet,
  • Documentazione,
  • Ampliare la collezione di tipici in Souliss,
  • Realizzare una UI Android basata sul framework, con "viste" e personalizzazioni,
  • Portare il framework su Windows ed altri sistemi operativi
  • Proporre una scheda elettronica dedicata alle applicazioni domotiche (wireless 434/900Mhz con RFM22B, 24V, 16DI isolati, 8 DO, relé off-board).

Ovviamente il vero livello di sviluppo dipenderà dal gradimento di tale framework e dalle eventuali collaborazioni.

Cercherò nel tempo di fornire un minimo di documentazione iniziale, il codice è comunque sufficientemente commentato.

Sono graditi commenti e suggerimenti e sopratutto collaboratori (principalmente lato Android), onestamente, un sistema domotico non può prescindere da una gestione remota su cellulare, tablet o PC.

Saluti,
Dario.

Non sono interessato al progetto però... complimenti. Ho dato un'occhiata al codice, è un bel lavoro :wink:

Ovviamente il vero livello di sviluppo dipenderà dal gradimento di tale framework e dalle eventuali collaborazioni.

Cercherò nel tempo di fornire un minimo di documentazione iniziale, il codice è comunque sufficientemente commentato.

Sono graditi commenti e suggerimenti e sopratutto collaboratori (principalmente lato Android), onestamente, un sistema domotico non può prescindere da una gestione remota su cellulare, tablet o PC.

Saluti,
Dario.

Io posso fare poco, ma anche un'ora la sera posso dedicarla. Purtroppo però ho zero denari da investire per domotizzare la mia casa, quindi la collaborazione che posso darti non è pratica. Ho visto che il codice è documentato per doxygen o simili, posso collaborare su Makefile, script bash, paccchetti rpm.

Per chi fosse interessato all'argomento e ha sufficienti risorse vi prego non ignorate questo post.

+FF
Ciao.

Davvero interessante. Mi piace l'approccio perchè (finalmente!) superiamo lo scoglio che ha rallentato terribilmente il proseguire della stimolante discussione dell'anno scorso sul vecchio forum (l'hai letta?), cui ho attivamente partecipato.

Da allora ho proseguito i ragionamenti e sono arrivato alla realizzazione di un sistema completo basato su arduino (e simili) e su nodi linux.

Proprio alla luce della oramai completa installazione (quasi 200 relè per il controllo di luce e riscaldamento di alcune decine di ambienti) nelle ultime settimane sto maturando la convinzione rimettere mano pesantemente alla logica di funzionamento del sistema, per impostare un modello simile a qaunto proponi: un peer to peer agnostico dell'hardware, inevitabilmente con diversi livelli di implementazione di un protocollo di fondo, comunque basato su TCP/IP (ora l'approccio è quasi completamente client-server, più per completare rapidamente sviluppo ed implementazione che per seria riflessione sulla questione).

Nei prossimi giorni studierò il tuo sistema e ti dico se possono esserci ambiti di interazione: io credo di si.

Sei già riuscito a realizzare un prototipo del sistema completo?

Per quanto riguarda il discorso dell'hardware Arduino dedicato, sfondi una porta aperta: è da secoli che ci penso, tanto che avevo anche aperto un forum per portarne avanti lo sviluppo

http://domoduino.org

Purtroppo il sito è stato sommerso dallo spam ed io dal lavoro, per cui tutto langue da mesi. Hai voglia di aiutarmi a riattivare l'iniziativa?

Considera che io sono un valido programmatore, e me la cavo anche con l'elettronica, anche se il mio ambito di specializzazione resta il software. Sono in grado però anche di progettare la parte hardware, salvo che serve l'aiuto di un esperto elettronico per evitare problemi tipo quelli delle interferenze elettromagnitiche che mi hanno mandato in palla durante la realizzazione del prototipo di cui sopra...

MauroTec:
Io posso fare poco, ma anche un'ora la sera posso dedicarla. Purtroppo però ho zero denari da investire per domotizzare la mia casa, quindi la collaborazione che posso darti non è pratica. Ho visto che il codice è documentato per doxygen o simili, posso collaborare su Makefile, script bash, paccchetti rpm.

Per chi fosse interessato all'argomento e ha sufficienti risorse vi prego non ignorate questo post.

+FF
Ciao.

Ciao Mauro,

ogni contributo è benvenuto. Anche io in termini di tempo riesco a dedicare solo poche ore la sera (lavoro permettendo) e lo sviluppo è partito a giugno, un'enormità se si considera la quantità di codice tutto sommato limitata.

Relativamente all'hardware, allo stadio attuale non è necessario domotizzare la propria casa. E' sufficiente avere qualche arduino ethernet o chibiduino per contribuire, ad esempio portando il framework su altre piattaforme, in quel caso è sufficiente far comunicare due dispositivi.

Attualmente non è partita alcuna attività di documentazione del codice, ma ho iniziato solo a scrivere della documentazione utente, quindi un supporto in tal senso sarebbe davvero utile.

Saluti,
Dario.

Ciao Enrico,

prima di iniziare lo sviluppo mi ero imbatuttto nella discussione del vecchio forum, come hai notato l'approccio impostato è differente da quanto proposto in quella discussione.

Le mie idee di sviluppo sono:

  • Comunicaizone P2P con gestione del protocollo in hardware, preferibilmente comunicazione wireless con bridge verso ethernet per la connettività con dispositivi mobili o PC,
  • Struttura distribuita, di base non devono essere necessari nodi "centrali",
  • Integrazione spinta, portare il framework su diverse piattaforme (sia hardware, sia software) può portare ad integrare un pulsante hardware con il PC, il media center o qualsiasi altra cosa.

Attualmente questi principi sono rispettati, il software funziona, si tratta di estenderlo su più piattaforme e spingere l'integrazione.
L'integrazione deve essere tale da poter schiacciare il pulsante vicino al letto e spegnere la luce di lettura, il media center, inserire l'allarme o qualsiasi altra cosa venga in mente. Alla fine non è poi così difficile se alla base c'è un framework condiviso e disponibile su diverse piattaforme. Se per un generico nodo con capacità di connettività c'è il framework, il resto viene da se.

Sarei felice di poter collaborare nel progetto di una scheda hardware dedicata, però vorrei puntare le priorità sul software. Attualmente, se si ha voglia di "sbariare" è possibile realizzare quanto serve con dell'hardware esterno collegato ad un Arduino (o simile) con connettività Ethernet o Wireless, avere del software funzionale (e funzionante) a mio avviso è il volano che può spingere verso la realizzazione dell'hardware.

Fammi sapere se ci sono dei margini per integrare il codice con quanto da te sviluppato.

La realizzazione attuale non è effettivamente installata, le schede sono raccolte su un piano d'appoggio e non attuano direttamente la 200V.

Saluti,
Dario.

Attualmente non è partita alcuna attività di documentazione del codice, ma ho iniziato solo a scrivere della documentazione utente, quindi un supporto in tal senso sarebbe davvero utile.

Cosa vuol dire?

Io vedo il codice di MaCaco documentato, non integralmente e in modo dettagliato ma c'è già un'inizio.

Ora penso che tu abbia usato un IDE (quale?) e questo probabilmente di inserisce già i tag /*! document */ e probabilmente si tratta di eclipse.
Comunque il codice così commentato è pronto per essere passato a doxygen che ne estrae la doc e la trasforma in html o altro.
Per la doc utente, si può fare anche con doxygen creando dei file .dox, ma se vuoi tenerla separata ti capisco.

Dunque sono tre librerie che su arduino dovranno essere statiche, corregimi se sbaglio. Il programma utente in sviluppo dovrà linkare con la libreria di arduino, con MaCaco e le altre. Sempre che si decida di creare tre moduli statici, in alternativa si può creare un libreria contenente i moduli oggeto ricavati dalla compilazione.

Io non ho visto alcun Makefile, come compili il tutto?

Ciao.

MauroTec:
Cosa vuol dire?

Io vedo il codice di MaCaco documentato, non integralmente e in modo dettagliato ma c'è già un'inizio.

Ora penso che tu abbia usato un IDE (quale?) e questo probabilmente di inserisce già i tag /*! document */ e probabilmente si tratta di eclipse.
Comunque il codice così commentato è pronto per essere passato a doxygen che ne estrae la doc e la trasforma in html o altro.
Per la doc utente, si può fare anche con doxygen creando dei file .dox, ma se vuoi tenerla separata ti capisco.

Dunque sono tre librerie che su arduino dovranno essere statiche, corregimi se sbaglio. Il programma utente in sviluppo dovrà linkare con la libreria di arduino, con MaCaco e le altre. Sempre che si decida di creare tre moduli statici, in alternativa si può creare un libreria contenente i moduli oggeto ricavati dalla compilazione.

Io non ho visto alcun Makefile, come compili il tutto?

Ciao.

Intendo dire che i commenti non sono dettagliati. Il risultato di una documentazione con doxygen non sarebbe sufficiente per rendere veramente comprensibile quanto fatto, sopratutto perché una persona terza che rivede il codice ed i commenti può rendere il risultato migliore.

Per la compilazione, ho le cartelle nella libreria della IDE di Arduino (da cui compilo) ed ogni libreria richiama l'altra, perché sono tre layer sovrapposti. Le librerie non possono essere statiche, il codice compilato dipende dalla configurazione, ad esempio se hai un Chibiduino senza Ethernet Shield non compili la libreria per il W5100.

Se hai consigli per distribuire meglio il codice, sono i benvenuti.

Saluti,
Dario.

ciao, non ho avuto occasione di guardare il codice ma dici che non è un sistema "centralizzato".

il che significa che ogni nodo deve avere un suo eth shield?

in tal caso la spesa diventerebbe piuttosto estesa.

comunque il mio consiglio è non fermarti al software, potresti sviluppare tutto un sistema anche hardware:
schede wireless con relè, sensori ecc che si collegano wia wireless a una scheda centrale che le gastisce ed esce in ethernet.

gli schemi alla fine li puoi scopiazzare un po in giro, ti prendi quello di arduino più quello della eth shield ed hai fatto il sistema integrato di comunicazione eth, poi prendi dal chibiduino e ti viene anche il wireless relativamente a basso costo.

poi vedi quanta gente vuole avere questo sistema e in base a quello vi mettete d'accordo sui prezzi (fate stampare i pcb da un service e uno prende i componenti per tutti poi si inviano a tutti) e chi vuole sviluppa il software :wink:

secondo me alla fine risulta un sistema modulare poco costoso, affidabile e completo!

superlol:
ciao, non ho avuto occasione di guardare il codice ma dici che non è un sistema "centralizzato".

il che significa che ogni nodo deve avere un suo eth shield?

in tal caso la spesa diventerebbe piuttosto estesa.

Ciao,

un sistema è centralizzato se esiste un nodo che cura la gestione delle logiche e la comunicazione, molti sistemi domotici sono centralizzati. Ciò significa che i moduli possono solo trasferire lo stato degli ingressi ed attuare le uscite, come e quando attuarle è gestito dal modulo centrale.

Un sistema distribuito non ha un nodo centrale, ma nodi con ruoli diversi ma in linea generale autonomi. Ad esempio un modulo termoregolatore richiede direttamente i dati ai termometri sparsi per la casa ed effettua la regolazione, un modulo che gestisce l'illuminazione comunica direttamente con i pulsanti remoti.

In entrambi i casi, ogni modulo deve avere la possibilità di comunicare con gli altri, che sia il solo modulo centrale o tutti i nodi della rete.

Nel caso particolare di Souliss, la libreria vNet crea un'astrazione, quindi le funzionalità e la configurazione del modulo non dipendono dal mezzo di comunicazione. Ad oggi sono supportati W5100 e Chibiduino, altri in futuro.

superlol:
comunque il mio consiglio è non fermarti al software, potresti sviluppare tutto un sistema anche hardware:
schede wireless con relè, sensori ecc che si collegano wia wireless a una scheda centrale che le gastisce ed esce in ethernet.

Attualmente Souliss già fornisce queste funzionalità.

superlol:
gli schemi alla fine li puoi scopiazzare un po in giro, ti prendi quello di arduino più quello della eth shield ed hai fatto il sistema integrato di comunicazione eth, poi prendi dal chibiduino e ti viene anche il wireless relativamente a basso costo.

poi vedi quanta gente vuole avere questo sistema e in base a quello vi mettete d'accordo sui prezzi (fate stampare i pcb da un service e uno prende i componenti per tutti poi si inviano a tutti) e chi vuole sviluppa il software :wink:

secondo me alla fine risulta un sistema modulare poco costoso, affidabile e completo!

Il punto è non mettere troppa carne al fuoco, lo sviluppo è solo agli inizi e sopratutto il software si cambia in modo relativamente facile, l'hardware no.

L'evolversi delle cose dipenderà sopratutto dalle collaborazioni al progetto, da solo non ho tempo per sviluppare il tutto in tempi ragionevoli.

Saluti,
Dario.

Intendo dire che i commenti non sono dettagliati. Il risultato di una documentazione con doxygen non sarebbe sufficiente per rendere veramente comprensibile quanto fatto, sopratutto perché una persona terza che rivede il codice ed i commenti può rendere il risultato migliore.

Ok, già una linea guida c'è per documentare le funzioni, quindi un primo passo base lo hai fatto, su questo si lavora per scendere nel dettaglio. Posso usare quello che c'è scritto nel formum come ducumentazione del framework integrando con con immagini e contenuti derivati dalla sperimentazione diretta.

Per la compilazione, ho le cartelle nella libreria della IDE di Arduino (da cui compilo) ed ogni libreria richiama l'altra, perché sono tre layer sovrapposti. Le librerie non possono essere statiche, il codice compilato dipende dalla configurazione, ad esempio se hai un Chibiduino senza Ethernet Shield non compili la libreria per il W5100.

Già non avevo considerato ciò. Se tutto è stato sviluppato con l'ide non serve un makefile e non c'è necessità di modificare l'organizzazione del codice che risulta perfetta. Comunque il makefile potrebbe essere un qualcosa in più, ma non sarebbe sfruttabile con l'ide di arduino in quanto creerebbe una libreria statica.

Nel file vNetDriver_eth.h alla linea 36 c'è da cambiare il nome del file da W5100.h a w5100.h.

Ciao.

MauroTec:
...

Ok :%

Vista l'assenza di una guida utente, riporto brevemente una descrizione di Souliss utile a comprendere come è stato sviluppato il software.

Ogni nodo ha un'area dati (un array da 30 byte) suddiviso in tre gruppi:

  • Tipici,
  • Input,
  • Output

Il primo gruppo, Tipici, contiene un codice identificativo della logica implementata nel nodo. Può essere utilizzato da applicazioni precompilate (ad esempio l'UI Android) per capire come interpretare o comandare i dati provenienti da nodo.

Il secondo gruppo, Input, è uno spazio dedicato agli ingressi sia hardware sia software. Analogamente il terzo gruppo è per gli output.

Per default l'area di memoria è indirizzata per slot, il cui numero è attualmente 8. Uno slot è composto da tre byte, uno per ogni gruppo. Tutti i metodi implemetati in Souliss sono indirizzati per slot.

Prendendo l'esempio 1 allegato alla libreria. Si tratta della gestione di un digital output (ad esempio un relé) con comandi locali e remoti.

Il codice, a meno degli indirizzamenti e selezione dei pin è il seguente:

		// Execute the code every 2 time_base		
		if (!(phase % 2))
		{
			// Use Pin2 as ON command, Pin3 as OFF command
			Souliss_DigIn(2, Souliss_T01_OnCmd, memory_map, 0);
			Souliss_DigIn(3, Souliss_T01_OffCmd, memory_map, 0);			
			
			// Execute the logic
			Souliss_T1(memory_map, 0, &data_changed);

			// Use Pin9 as output on the electrical load
			Souliss_DigOut(9, Souliss_T01_Coil, memory_map, 0);	
		}

Il codice viene eseguito ogni due time_base del codice (100 ms) La funzione Souliss_DigIn() associa ad un pin della scheda una funzione ed il relativo slot, ad esempio

Souliss_DigIn(2, Souliss_T01_OnCmd, memory_map, 0);

Dichiara il pin 2 (precedentemente impostato come input) come OnCmd (On Command) e lo associa allo slot 0 della memory_map

Souliss_T1(memory_map, 0, &data_changed);

Esegue la logica T1 (tipico 1) sullo slot 0, quindi usa lo slot 0 di input per leggere i dati e lo stesso per gli output. La variabile data_changed viene usata come trig per l'invio dei dati.

Infine, Souliss_DigOut() prende lo slot 0 di output e lo lega al pin 9.

		// Execute the code every 5 time_base		  
		if (!(phase % 5))
		{   
			// Retreive data from the communication channel
				Souliss_SerialData(memory_map, &data_changed);
		}

		// Execute the code every 10 time_base		  
		if (!(phase % 10))
		{   
		// Open a communication channel, check channel status
		Souliss_SerialChannel(network_address_2, memory_map, 0, 0, 1, 0, &healty, &count);
		}

La funzione Serial_Data recupera i dati dalla comunicazione seriale (ethernet, chibiduino, ...) in base alle configurazione di vNet.

Il dispositivo ha ingressi hardwired alla scheda, volendo introdurre un modulo remoto si può dichiarare un canale di comunicazione con Souliss_SerialChannel() dove 0, 0, 1, 0 sta per slot ingresso, slot uscita, numero byte, canale di comunicazione.

Lo slot di ingresso è quello relativo alla propria memory_map, i dati provenienti da questo canale di comunicazione sono inseriti nello slot 0 degli input.
Lo slot di uscita è quello da cui leggere, viene letto lo slot 0 degli output del dispositivo di rete con indirizzo network_address_2.

Il canale di comunicazione è un indice interno, può variare da 0 a 10 e non può essere ripetuto all'interno dello stesso dispositivo.

Per realizzare un pannello con pulsanti remoti, che quindi agiscono su un dispositivo di rete diverso, in particolare quello a cui è fisicamente collegato il relé

		if (!(phase % 2))
		{
			// Use Pin2 as ON command, Pin3 as OFF command	
			Souliss_DigIn(2, Souliss_T01_OnCmd, memory_map, 0);
			Souliss_DigIn(3, Souliss_T01_OffCmd, memory_map, 0);	
			
			// Make the input slot 0 a remote input
			Souliss_LinkIO(memory_map, 0, 0, &data_changed);
		} 
		
		// Execute the code every 5 time_base		  
		if (!(phase % 5))
		{ 
  			// Retreive data from the communication channel
			Souliss_SerialData(memory_map, &data_changed);
			
			// If Souliss_LinkIO is used, a reset is required
			if(data_changed == MaCaco_NODATACHANGED)
				Souliss_ResetOutput(memory_map, 0);
		}

Il codice è estremamente simile al precedente, la differenza è che non viene eseguita nessuna logica. Gli input sono riportati in output direttamente tramite la funzione Souliss_LinkIO() in modo che possano essere letti dall'altro modulo.

Saluti,
Dario.

Ieri sera ho inserito una guida utente per la libreria vNet, è disponibile al link http://sourceforge.net/projects/veseo-souliss/files/User%20Guide/

Saluti,
Dario.

Ieri sera ho inserito una guida utente per la libreria vNet, è disponibile al link http://sourceforge.net/projects/veseo-souliss/files/User%20Guide/

Si ho visto e letto una volta, oggi e domani volevo fare alcuni test ed inserire la doc pdf in doxygen, ma mi si sono rotti gli occhiali da vista e praticamente sono cieco (quasi).

Comunque, io non uso l'ide, quindi sono stato costretto ad importare il progetto in modo da gestirlo con QtCreator. Lo sviluppo con questo ide è tipico di tutti gli ide. Quindi ho dovuto generare delle librerie statiche. Ho deciso per semplicità di dividerlo in due lib, libMaCaco.a e libvNet.a ho compilato il tutto con successo dopo un paio di modifiche al codice di tipo non funzionale.

Ci sono alcune #include con dentro specificato il file .cpp anziché .h, è un errore o e necessario. Ho dovuto modificare l'estensione del file chb_cmd.c in .cpp perchè dentro c'è una chiamata a codice C++ ed il compilatore C non sa come risolvere il link ad una funzione metodo.

Probabilmente il preprocessore di arduino ide, sistema le cose.

Appena ho un paio di occhiali nuovi riprendo la sperimentazione.

Ciao.

MauroTec:
Si ho visto e letto una volta, oggi e domani volevo fare alcuni test ed inserire la doc pdf in doxygen, ma mi si sono rotti gli occhiali da vista e praticamente sono cieco (quasi).

Comunque, io non uso l'ide, quindi sono stato costretto ad importare il progetto in modo da gestirlo con QtCreator. Lo sviluppo con questo ide è tipico di tutti gli ide. Quindi ho dovuto generare delle librerie statiche. Ho deciso per semplicità di dividerlo in due lib, libMaCaco.a e libvNet.a ho compilato il tutto con successo dopo un paio di modifiche al codice di tipo non funzionale.

Ci sono alcune #include con dentro specificato il file .cpp anziché .h, è un errore o e necessario. Ho dovuto modificare l'estensione del file chb_cmd.c in .cpp perchè dentro c'è una chiamata a codice C++ ed il compilatore C non sa come risolvere il link ad una funzione metodo.

Probabilmente il preprocessore di arduino ide, sistema le cose.

Appena ho un paio di occhiali nuovi riprendo la sperimentazione.

Ciao.

Si, tranquillo non c'è fretta. Era una guida preparata un poco di tempo fa, per dare un'idea di come lavorare con gli indirizzamenti.

Relativamente alle librerie, ci sono alcune forzature dovute all'IDE. In pratica non riuscivo a far riconoscere i file all'interno delle sottocartelle, trovava il .h ma non il corrispondente .c/.cpp. Per ovviare, nel file principale viene incluso direttamente il codice e non il solo header. Mi aspetto che con altre IDE il problema non si riproponga.

Relativamente a chibi_cmd.c è una libreria derivante da Chibiduino, se non sbaglio nel codice viene incluso direttamente il contentuto del file .c e per questo motivo l'IDE non si accorgeva dell'errore.
La libreria gestisce il parse dei comandi derivanti dalla linea seriale, nella prossima release eliminerò direttamente il file, attualmente non è usato ed a mio avviso non dovrebbbe far parte di Souliss ma al limite di una libreria esterna.

Saluti,
Dario.

Ho inserito una guida utente per Souliss, spero semplifichi la comprensione di tale libreria. E' disponibile al seguente link https://sourceforge.net/projects/veseo-souliss/files/User%20Guide/

Saluti,
Dario.

Per rendere più chiare le funzionalità di Souliss ho documentato uno degli esempi proposti nella libreria “Example 5 – Garage Door”.

https://sourceforge.net/projects/veseo-souliss/files/Examples%20Guidelines/

Questo esempio usa il tipico no. 3, la gestione di un dispositivo a quattro stati con un unico pulsante di comando. Un dispositivo è a quattro stati se ha due linee di attuazione, ad esempio la serranda di un garage ha una linea di attuazione per l'apertura e l'altra per la chiusura. In totale gli stati possibili sono quattro, anche se in realtà solo tre sono usati : apri, chiudi, fermo.

La logica implementa ne più, ne meno, quanto fatto da una classica centralina per la gestione delle serrande. Ad ogni pressione sul pulsate di comando, corrisponde un cambio di stato.
Premendo il pulsante con la serranda aperta, la serranda si chiude e viceversa. Premendolo durante la chiusura o l'apertura si la serranda si ferma ed inverte la marcia alla successiva pressione del pulsante.

Questa semplice logica (implementata in Souliss come tipico 3, T03) utilizzata in unione alle librerie MaCaco e vNet offre un sistema di controllo remoto.
Nell'esempio proposto, il pulsate di comando è hardwired ad un modulo wireless (Freakduino Chibi) mentre il comando ai relé di attuazione del motore sono su un modulo Arduino Ethernet. In mezzo c'è un bridge (Freakduino con Ethernet Shield).

Inoltre, un ulteriore Freakduino Chibi è utilizzato come monitor seriale. Acquisisce lo stato direttamente dal modulo Ethernet agente sui relé, e li visualizza sullo schermo del PC. E' inoltre possibile inviare i comandi dal PC, con la stessa funzionalità del pulsante hardwired.
Ad ogni cambio di stato, il modulo Arduino Ethernet invia i dati al monitor seriale (publishing/subscribing).

Saluti,
Dario.

Nei giorni dal primo rilascio di Souliss ho avuto modo di rivedere il programma di sviluppo del progetto, ponendo maggiore attenzione all'interfaccia grafica ed alla documentazione.

La prima interfaccia grafica disponibile (di cui è disponibile un'immagine di seguito) è basata su AJAX/JSON, riprende parzialmente TinyWebServer con la particolarità di non utilizzare le schede Arduino come fonte della pagina web, ma dei soli contenuti.
Come illustrato qui, il browser (in questo caso Firefox o Chrome) è utilizzato come ambiente di esecuzione, la pagina web è caricata localmente sul PC o dispositivo mobile e periodicamente richiede dati al nodo Arduino, il quale risponde in JSON.
E' strutturata come un semplice menu a tendina, lo stato attivo (ricevuto via JSON) viene evidenziato con un colore del fondo blu.

Questa soluzione (diversa da quanto ipotizzato al primo rilascio) prevede un nodo collettore dei dati, il quale riporterà lo stato dei dispositivi controllati via JSON. Lo stesso nodo cura la gestione dei comandi dall'interfaccia grafica verso i dispositivi della rete. In pratica, la rete continua ad essere distribuita, ma l'interfaccia utente è basata su due entità (arduino+browser) e non su una.

La soluzione di portare il framework su diversi OS (tra i quali Android) rimane, ma è stata data maggiore priorità ad una soluzione web-based per ridurre i tempi necessari ad avere un'interfaccia utente.

Dunque, il nodo Arduino (necessariamente basato su Ethernet Shield o Arduino Ethernet) colletterà i dati via MaCaco e riporterà via HTTP all'interfaccia grafica.
Ovviamente possono essere raggiunti sia nodi basati su Ethernet, sia nodi basati su Chibiduino, la libreria vNet cura le operazioni di bridging e routing all'interno della rete di nodi in modo trasparente all'interfaccia.

Il rilascio è previsto per fine gennaio 2012, insieme ad un arrichimento delle logiche "tipiche" incluse in Souliss, nel frattempo chi volesse iniziare a sperimentare l'interfaccia come Alpha-tester è il benvenuto.

Sullo stesso principio possono essere sviluppate anche interfacce non web-based, una per iPhone è in lavorazione da parte di BoomTakZaag.

Le seguenti modifiche sono state apportate,

Souliss Rev A2:

  • Supporto in vNet della libreria Ethernet standard per garantire compatibilità con altre librerie,
  • Aggiunta di una libreria per il supporto HTTP

Saluti,
Dario.

Video

Nota: Basato su jQuery Tabbed Interface / Tabbed Structure Menu Tutorial

Su SourceForge ho rilasciato la revisione A2 di Souliss, la modifica principale è nel supporto contemporaneo di vNet Ethernet (modalità P2P) e la classe Ethernet nativa (modalità Server, Client) di Arduino. Sfruttando questa modifica sono stati aggiunti metodi per la gestione di un server JSON ed un interfaccia HTML da avviare localmente ad un dispositivo con browser Firefox e Chrome.

Altre modifiche hanno riguardato l'aggiunta di nuovi tipici (logiche pronte all'uso orientate alla domotica).

Sulla base di queste modifiche, tutti gli esempi sono stati riscritti, molti di essi dispongono anche di un'interfaccia pronta all'uso.

http://sourceforge.net/projects/veseo-souliss/

Saluti,
Dario.