Souliss, Domotica e IoT basata su Arduino ed Android

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.

Stupendo, vaseo stai facendo un ottimo lavoro davvero, complimenti !

bel lavoro davvero, appena mi arriva un w5100 farò delle prove :smiley:

Grazie ad entrambi.

Saluti,
Dario.

innanzitutto complimenti per il lavoro.

Io, come molti altri facenti parte della categoria "poveri", abbiamo comprato la ethernet shield appositamente prodotta per noi, quella con chip non wiz, questa http://www.nuelectronics.com/estore/index.php?main_page=project_eth

e' molto famosa in quanto costa poco. e' supportata dal tuo progetto ? oppure se hai interesse nel supportarla potrei fare da test.
Un'altro punto a suo favore e' che e' costruibile con integrati DIP (ENC28J60), quindi ottimo per standalone, mentre con il wiz non e' possibile

scusa il consuma poco era un errore, corretto in COSTA POCO

resta il fatto che e' costruibile con integrati dip e che dopo il wiz5100 credo che il ENC28J60 sia il piu' usato.

veseo:
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.

Vaseo ho provato a dare un'occhiata ma no ci ho capito na sega! Io ho già un impianto Arduino Based co Ethernet shield, collegati tramite Switch PoE.

Non riesco a comprendere come potrei usare il tuo software.

Essendo un Tecnico elettronico più che un Softwerista, saresti in grado di fornirmi uno schema elettrico e come implementare il tuo software dentro gli Arduino?

Thanks