Souliss, Domotica e IoT basata su Arduino ed Android

Nuova documentazione disponibile al seguente link http://sourceforge.net/projects/veseo-souliss/files/User%20Guide/

E' online il sito del progetto all'indirizzo www.souliss.net, continuerò ad utilizzare questo topic per riportare gli aggiornamenti.

Saluti,
Dario.

grazie :slight_smile:

E' disponibile per il download la versione A2.3, con diverse modifiche al JSON server necessarie per supportare l'applicazione Android sviluppata da shineangelic.

Dai repository è attualmente possibile scaricare sia Souliss, sia l'applicazione Android, i link per entrambi sono disponibili nella sezione download del sito di Souliss.

Saluti,
Dario.

mi chiedevo,
l'applicazione Android replica le funzioni dell'interfaccia via Browser ? Ha funzioni in piu'/meno ?

Cioe' se raggiungo il mio bel arduino Souliss tramite il browser integrato in android faccio le stesse cose che posso fare con l'applicazione ?

Testato:
Cioe' se raggiungo il mio bel arduino Souliss tramite il browser integrato in android faccio le stesse cose che posso fare con l'applicazione ?

No, perchè il client android "astrae" il modello a tipici/nodi di souliss, permettendo un'interazione più user friendly. Posto che è ancora in fase di sviluppo, l'app dispone per esempio di un database, su cui loggare la 'storia' dell'impianto domotico e su cui definire dei comportamenti ad "alto livello" (impossibile con i 2K di Arduino). Per esempio è possibile definire comandi temporizzati o geolocalizzati, in modo da poter inviare comandi a souliss a determinate ore oppure quando usciamo di casa.

O ancora, si possono definire i comandi "sensor based", ovvero trigger che si attivano quando determinati sensori raggiungono un certo valore (ad es. se l'umidità supera l'85%, accendi il condizionatore)

I tipici supportati dal client alla versione 0.7 sono le luci (11, 12 e 14) ed i sensori corrente e temperatura. Questi ultimi non sono tuttavia ancora inclusi nella distribuzione 'ufficiale'...Dario ed io ci stiamo lavorando molto, ma integrare attuatori e sensori anche banali (ad es. DHT, fotodiodi, CT sensor) in un sistema domotico distribuito non è sempre banale :slight_smile:

Inoltre il client android implementa un servizio in background che si occupa di mantenere il client aggiornato.

molto interessante, grazie della ripsosta,

se ho capito pero' questi comandi memorizzati lato android dalla tua app saranno funzionanti solo se sono online. Cioe' se spengo il telefono nessuno andra' a verificare il sensore umidita' e nessuno attuera' il relativo comando di accensione condizionatore.
Inoltre se esco di casa devo restare connesso al GPRS ed aver gestito correttamente il forward delle porte del rouoter con l'esterno.

Testato:
se ho capito pero' questi comandi memorizzati lato android dalla tua app saranno funzionanti solo se sono online. Cioe' se spengo il telefono nessuno andra' a verificare il sensore umidita' e nessuno attuera' il relativo comando di accensione condizionatore.
Inoltre se esco di casa devo restare connesso al GPRS ed aver gestito correttamente il forward delle porte del rouoter con l'esterno.

Sì, corretto. Purtroppo gestire il logging (e i trigger) a basso livello, ovvero direttamente sulla scheda, è difficoltoso per limiti di memoria. Richiederebbe di adottare schede più performanti, ma ci allontaneremmo dagli obbiettivi di economicità che per adesso rimangono primari.

Per quanto riguarda il forwarding è prevista anche la modalità VPN, che in Android è supportata nativamente ed è presente in quasi tutti i router domestici; questo naturalmente per evitare di avere una porta HTTP sempre aperta verso l'esterno.

Testato:
molto interessante, grazie della ripsosta,

se ho capito pero' questi comandi memorizzati lato android dalla tua app saranno funzionanti solo se sono online. Cioe' se spengo il telefono nessuno andra' a verificare il sensore umidita' e nessuno attuera' il relativo comando di accensione condizionatore.
Inoltre se esco di casa devo restare connesso al GPRS ed aver gestito correttamente il forward delle porte del rouoter con l'esterno.

Aggiungo un'ulteriore nota, una possibile configurazione prevede l'utilizzo di un tablet come touch screen dedicato alla gestione della casa, esistono numerosi modelli adatti a tutte le tasche. Inoltre per come è strutturato il meccanismo di interfacciamento, è possibile avere interfacce multiple allo stesso tempo.

In definitiva, un touch screen centrale con funzioni di supervisione e altri dispositivi portatili per la gestione fuori casa.

Concludo, la gestione delle sequenze a livello di client garantisce una maggiore flessibilità in termini di definizione delle sequenze stesse. Poi nulla vieta di introdurre del codice per la gestione di sequenze importanti direttamente nella scheda. Avere a disposizione il codice regala sufficiente libertà.

Saluti,
Dario.

certo,
infatti non erano critiche, era solo per capire il fumo come girava :slight_smile:

non h mai usato VPN su android, da provare assolutamente.
non so quando finisco il mio attuale progetto, ma al prossimo giro mi butto di certo su questo.
Magari collaboro nei test.
Mi raccomando di avvisare su questo topic quando sara' possibile usare l'"ethernet dei poveri" :slight_smile:

Testato:
certo,
infatti non erano critiche, era solo per capire il fumo come girava :slight_smile:

Ci mancherebbe, anche le critiche sono ben accette.

non h mai usato VPN su android, da provare assolutamente.
non so quando finisco il mio attuale progetto, ma al prossimo giro mi butto di certo su questo.
Magari collaboro nei test.
Mi raccomando di avvisare su questo topic quando sara' possibile usare l'"ethernet dei poveri" :slight_smile:

Lo sviluppo per l'ENC28J60 è già iniziato, spero di riuscire in un mesetto a fornire i primi risultati.

Saluti,
Dario.

ottima tempistica, io spero in un mesetto di chiudere questo mio attuale, cosi' iniziamo insieme sull'enc :slight_smile:

Pur se con la velocità di un bradipo, ieri sono riuscito a gestire una connessione P2P su TCP/IP tra due ENC28J60.

Ero partito utilizzando lo stack TCP/IP incluso nella classica EtherShield indicata comunemente con le shield basate su ENC28J60, impiegando circa tre settimane di lavoro per riscrivere il codice ed avere una gestione multisocket. Funzionava, ma il risultato non era convincente.

Dopo qualche giorno di riflessione ho optato per l'utilizzo di uIP, lo stack utilizzato in Contiki. Attualmente in vNet è integrata la versione 0.90, di cui è disponibile un porting per AVR ed un'implementazione su ENC28J60.
La base di partenza era di tutt'altra pasta ed in un paio di settimane e qualche lieve modifica, sono riuscito a farlo funzionare ed integrarlo in vNet.

Nei prossimi giorni includerò anche il codice per il supporto dei metodi d'interfaccia della libreria Ethernet di Arduino, in modo da rendere disponibile anche l'implementazione del JSON server per l'interfaccia verso Android.

L'interrogativo principale resta la RAM, rispetto alla versione con W5100 c'è un consumo aggiuntivo di circa 300 bytes, ed attualmente non so se tutte le possibili configurazioni attualmente supportate da Souliss saranno implementabili sulla coppia 328P+ENC28J60.

Nelle prossime settimane verrà rilasciato il codice con il supporto ENC28J60 e la nuova roadmap di Souliss, con diverse novità, sopratutto nelle soluzioni di comunicazione supportate.

Saluti,
Dario.

ottimo,
ho visto che hai partecipato anche sul forum open di emanuele con il tuo progetto, complimenti :slight_smile:

Testato:
ottimo,
ho visto che hai partecipato anche sul forum open di emanuele con il tuo progetto, complimenti :slight_smile:

Si, quella è stata una decisione presa d'impulso per migliorare la visibilità del progetto ed ha modificato notevolmente i piani, ad esempio anticipando di diversi mesi la pubblicazione del sito internet dedicato al progetto.

veseo:

BrainBooster:
qualcuno ha mai provato lo stack µTCP/IP che c'è su Conitki o TinyOS?

E' un codice molto pulito, infatti sono combattuto nell'utlizzare quello stack con la libreria dell'EN28J60. Lo stack TCP/IP fornito con le librerie dell'EN28J60 non sono il massimo della vita.

Saluti,
Dario.

Riprendo il discorso, alla fine ho optato per uIP in versione 0.9, non è la più recente ma è quella che meglio si prestava all'integrazione.

Saluti,
Dario.

Anche se con tempi molto più lunghi del previsto, è disponibile la versione A3 di Souliss, che tra le altre cose include il supporto al ENC28J60. Di fatto, l'utilizzo di ENC28J60 introduce Souliss alla prima scheda "pronta all'uso" supportata dal framework, la DINo di KMTronic.

Sul sito del progetto sono riportati maggiori dettagli sulle novità in atto e quelle future.

Saluti,
Dario.

Buongiorno e Buone Feste Forum,

dopo qualche mese di sviluppo è stata rilasciata la nuova versione (A4) di Souliss, con molte novità ed una struttura di base rinnovata e pensata per i prossimi sviluppi.

Ormai è passato più di un anno dalla prima versione di Souliss e le linee guida dello sviluppo sono parzialmente cambiate, pur rimanendo all'interno dell'idea originale.

Il passo in avanti più significativo è nell'adozione di protocolli binari per tutte le funzionalità, lasciando i protocolli ASCII ad un ruolo secondario. Fino alla versione precedente la comunicazione utilizzava un protocollo binario solo se intercorreva tra schede, non verso le interfacce utente, ora invece anche l'interfaccia Android usa MaCaco su vNet e per tutte le altre c'è Modbus in versione RTU e TCP.

Il perché di questa scelta ha dietro due aspetti, il primo era nella gestione di protocolli ASCII e contemporaneamente dello stack IP in software, pur funzionando il numero di iterazioni per processare i dati era eccessivo e le prestazioni di conseguenza non erano all'altezza, cosa che non accadeva usando lo stack IP in hardware.
L'utilizzo di protocolli binari permette di gestire tutte le informazioni senza frammentazione su diversi pacchetti, con il risultato di un'interazione immediata. Ottenendo anche una riduzione dell'uso di RAM, dovuta anche ad una nuova gestione dei buffer dati.

Ora l'interazione è immediata e ad un comando si ottiene in risposta lo stato in pochi istanti, anche se le informazioni devono passare tra più nodi, questo indipendentemente dal controller utilizzato (W5100, ENC28J60).

Un ulteriore vantaggio è nella iterazione basata su eventi, quindi lo smartphone non effettua più delle richieste periodiche a scadenze brevi, ma viene aggiornato direttamente dalla scheda solo se c'è variazione dei dati. Questo ha un impatto positivo in termini di batteria e carico.

Fino a qui, non si è fatto altro che dare vita ad idee nate da subito, ma implementate in modo graduale.

Una novità è invece nell'uso di Modbus ed in futuro di altri protocolli binari. Che Modbus non sia una novità in senso assoluto è noto, ma è un protocollo che all'inizio era stato scartato perché nato per l'automazione industriale e di conseguenza non sempre presente nelle interfacce per la domotica, sopratutto in quelle moderne.

Cosa è cambiato? Per la domotica ad oggi non esistono protocolli "liberi" e Modbus sta iniziando ad essere supportato da diversi progetti di domotica come openHAB o Freedomotic, inoltre le interfacce SCADA basate su Modbus sono tantissime.

Da oggi le schede possono essere viste come degli slave Modbus, resta sempre il concetto di aggregatore, si accede dunque ad un nodo per raccogliere i dati di tutte le schede. In pratica Modbus è un protocollo di front-end e sostituisce HTTP/JSON (che non è stato dismesso).

L'utilizzo di Modbus ha portato al supporto da parte di IntegraXor, uno SCADA basato su web e grafica sviluppata in Inkscape (SVG), quindi è possibile creare il proprio disegno di interfaccia e gestirlo come pagina web da cellullare o computer, andando ad interagire direttamente con i propri Arduino che montano Souliss.
Per ora non abbiamo ancora rilasciato un'interfaccia basata su Inkscape, ma chiunque può disegnarsi la propria.

Altre modifiche minori sono presenti, come la gestione IR e Climatizzatore; siamo passati alla IDE1 e l'applicazione Android è disponibile anche direttamente dal market Play Store.

Questo anno di lavoro credo abbia portato ad un progetto ben strutturato, con ancora margini di sviluppo, su cui è arrivato il momento di tirare le somme.
Sicuramente per l'inizio dell'anno ridurremmo il tempo speso nello sviluppo per dedicarci alla diffusione e l'uso di Souliss, provando a capire quanto sia effettivamente considerato valido. Inoltre cercheremo di impegnarci sugli aspetti di documentazione, ad oggi parziali e non sempre aggiornati.

L'appello è dunque a chi sia interessato agli argomenti della domotica ed Internet of Things, perché possa contribuire, si può partire dal semplice uso (commento e consigliando), passando per la pubblicizzazione fino ad arrivare allo sviluppo. Giusto per dare un'idea, riporto alcune attività in programma:

  • Integrazione via Modbus in sistemi di domotica per l'IoT come openHAB e di supervisione come Freedomotic;
  • Realizzazione di un'interfaccia grafica in Inkscape;
  • Introduzione di soluzioni in broadcasting;
  • Introduzione di soluzioni per l'autoconfigurazione.

Lato hardware ci stiamo muovendo su diversi fronti, il più probabile sarà quello di utilizzare l'hardware di Olimex, che attualmente offre dei blocchi funzionali da comporre per realizzare soluzioni wireless e wired.

Il prossimo anno sarà decisivo per il progretto, perché dall'uso che si determinerà andrà a dipendere come verrà supportato in futuro, se continuerà ad essere un progetto aperto o se si rinchiuderà nelle esigenze specifiche di pochi.

Buone feste.

Saluti,
Dario.

x iscrizione

Ricambio gli auguri di buone feste e mi fa piacere il progetto continui.
Mi chiedevo, visto gli investimenti che hai fatto in termini di tempo, quale è il target finale ? Intendi vendere il SW ? Vuoi fare hardware tuo ? Che licenza stai usando ?