Database per Freedomotic

[Mauro Cicolella]

Nelle ultime discussioni è emersa la necessità di gettare le basi per un sistema di storage adeguato a supportare una serie di attività: dall'analisi dello storico al supporto per il machine learning.
In realtà abbiamo già un prototipo molto primordiale denominato Harvester plugin di cui potete leggere maggiori dettagli all'indirizzo http://freedomotic.com/content/plugins/harvester
Si tratta di un primo esperimento che abbiamo messo per un attimo in stand-by in quanto si è presentata l'esigenza di decidere se non sia meglio ricorrere ad una soluzione no-sql vista la quantità di dati da trattare, il fatto che questi possono avere una struttura variabile non compatibile con gli schemi rigidi del modello relazionale oltre a questioni riguardanti le performance, il bilanciamento del carico, la replica ecc.

Quindi in primo luogo occorrerebbe decidere se optare per un db relazionale o nosql o per una combinazione dei due e per quali finalità.

Abbiamo parlato della possibilità di far girare FD su sistemi embedded che utilizzano delle sd card sicuramente non adatte per un uso intensivo da parte di database. Ci sono delle schede come Udoo che permettono di connettere un hd sata esterno. In alternativa utilizzare un dispositivo ad-hoc solo per lo storage o ancora ricorrere al cloud anche se questo renderebbe il sistema dipendente dalla presenza di connettività Internet.

Poi bisognerebbe decidere cosa memorizzare.
Sicuramente i valori rilevati dai sensori in forma di eventi che consentono di avere un timestamp ma anche i comandi eseguiti tracciando sia l'utente che la modalità (in automatico, tramite web, ecc).

Ci sarebbe molto altro da dire ma penso che si possa partire da questi primi punti da analizzare in dettaglio. Il resto verrà di conseguenza.

A voi la parola per ulteriori commenti

Mauro

[mauro cicolella]

Ciao

giusto un reply al volo perchè ho notato che il post non è visibile sul gruppo.

Scherzi di Google!

Il giorno 24 febbraio 2016 08:11, alberto mengoli <amen...@gmail.com> ha scritto:

Ciao,

Il problema della memoria di massa sembra relativamente semplice da risolvere; basta aggiungere un hard disk esterno USB al raspi http://www.vemp.org/raspberrypi/collegare-hard-disk-esterno/  con alcune semplici precauzioni: autoalimentato, file system no NTFS e no FAT32, gestione dei permessi abilitata. NTFS sarebbe abbastanza logico, ma il driver per raspberry e' lentino; FAT32 e' abbastanza universale ma con limiti di 4Gb di lunghezza per i file. Come diceva giustamente Mauro i db no-sql escono dalla logica di controllo dell'integrita' referenziale tipica dei relazionali, ma in compenso sono molto flessibili nella gestione del tipo di dati e non hanno quasi limite alla quantita', cose che li renderebbero quasi ideali per quello che vogliamo fare. Personalmente ho visto le caratteristiche di Mongo db e sembra molto interessante; oltre a tutto quanto di cui sopra, memorizza i dati in formato JSON.

Se fossimo d'accordo sul mezzo da utilizzare, (sql, no-sql o entrambi), si potrebbe cominciare a fare un elenco descrittivo completo degli eventi/dati da memorizzare; e qui, bisognerebbe essere piuttosto precisi sul come, dove e quando se vogliamo mettere insieme uno straccio di modello.

Ciao, Alberto

--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Freedomotic - IoT and Smart Spaces Framework" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a freedomotic-i...@googlegroups.com.
Per postare in questo gruppo, invia un'email a freedom...@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/ab1b9df1-1fe4-4ac0-bc4d-5b03c0073153%40googlegroups.com.
Per altre opzioni visita https://groups.google.com/d/optout.

--

Freedomotic Open IoT Framework

www.freedomotic.com

www.emmecilab.net

[alberto mengoli]

Ciao,

Il problema della memoria di massa sembra relativamente semplice da risolvere; basta aggiungere un hard disk esterno USB al raspi http://www.vemp.org/raspberrypi/collegare-hard-disk-esterno/  con alcune semplici precauzioni: autoalimentato, file system no NTFS e no FAT32, gestione dei permessi abilitata. NTFS sarebbe abbastanza logico, ma il driver per raspberry e' lentino; FAT32 e' abbastanza universale ma con limiti di 4Gb di lunghezza per i file. Come diceva giustamente Mauro i db no-sql escono dalla logica di controllo dell'integrita' referenziale tipica dei relazionali, ma in compenso sono molto flessibili nella gestione del tipo di dati e non hanno quasi limite alla quantita', cose che li renderebbero quasi ideali per quello che vogliamo fare. Personalmente ho visto le caratteristiche di Mongo db e sembra molto interessante; oltre a tutto quanto di cui sopra, memorizza i dati in formato JSON.

Se fossimo d'accordo sul mezzo da utilizzare, (sql, no-sql o entrambi), si potrebbe cominciare a fare un elenco descrittivo completo degli eventi/dati da memorizzare; e qui, bisognerebbe essere piuttosto precisi sul come, dove e quando se vogliamo mettere insieme uno straccio di modello.

Ciao, Alberto

Il giorno 23 febbraio 2016 19:17, Mauro Cicolella <mauro.c...@gmail.com> ha scritto:

--

[Mauro Cicolella]

Aggiungo qualche altra nota.

Finora la persistenza dei dati relativi alla configurazione del sistema (ambienti, oggetti, comandi, trigger, automazioni) è stata gestita tramite file xml modificabili in buona parte tramite l'interfaccia grafica.

Questo approccio può avere pro e contro. Si può aggiungere o modificare al volo uno di questi file con un semplice editor ma in questo modo non ci sono controlli sintattici fino all'esecuzione di Freedomotic.

L'utilizzo di un database permetterebbe una gestione guidata richiedendo delle interfacce ad hoc ma ovviamente non sarebbe più possibile intervenire "a mano".

Quindi andrebbe valutato anche questo aspetto. In una precedente discussione interna si era prospettato l'utilizzo di un db relazionale per questo scopo e di ricorrere al nosql per gestire lo storico. In particolare si parlava di Cassandra DB.

Tornando ai dati da memorizzare direi che per quanto riguarda i sensori (temperatura, luminosità, presenza, ecc) non ci sono particolari problemi: timestamp, valore letto, riferimento all'oggetto sono tutti presenti all'interno dei vari eventi.

Diverso il discorso per gli elettrodomestici: come fare a stabilire quando il televisore, il forno, la lavatrice vengono accesi o spenti? Le aziende hanno cominciato ad immettere sul mercato dispositivi smart ma quanti sono ancora privi di queste funzionalità? Una possibile soluzione sarebbe quella di connetterli a prese comandate che si possano accendere o spegnere in remoto (ma servirebbe anche un pulsante fisico o no?) e che comunichino tramite wifi o zwave il loro stato. Oppure utilizzare delle schede relè a cui collegare le prese, ma già questo richiederebbe l'intervento di un installatore. Altre idee?

Analogo discorso per i comandi: come tracciarli? Naturalmente se il comando viene inviato tramite client (web, app ecc) è possibile conoscere l'utente che ha effettuato l'operazione perchè deve essere loggato, ma se premo un interruttore fisico questo non è possibile. 

Probabilmente può non essere rilevante, ma se voglio che il sistema analizzi il comportamento degli utenti per proporre dei "suggerimenti", come fa Amazon quando ci indica i prodotti simili acquistati da altri utenti, devo tenerne conto.

Che ne pensate?

Mauro

[alberto mengoli]

ciao,

scusate l'inciso, ma ho visto che Cassandra db gestisce diverse centinaia di terabytes di dati attraverso strutture organizzate in datacenter, nodi e cluster. Abbiamo davvero bisogno di una tale potenza? ;) Buona serata, Alberto

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "Freedomotic - IoT and Smart Spaces Framework" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a freedomotic-i...@googlegroups.com.
Per postare in questo gruppo, invia un'email a freedom...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/98d3a396-4fcc-41eb-9cf4-73456ac93a00%40googlegroups.com.

[Mauro Cicolella]

Il punto non è valutare la potenza in base alla quantità di dati da gestire. Evidentemente è difficile che una casa possa produrre terabyte di dati e comunque altri db come mongodb sono in grado di gestire volumi simili.

Secondo me occorre considerare le diverse caratteristiche e scegliere in base alle esigenze.

Per esempio Cassandra è giudicato in molti studi come il più veloce nelle scritture, quindi ottimo sul fronte del logging.

Ha una architettura distribuita per cui ogni nodo può svolgere ogni compito e questo lo rende molto efficiente per gestire le repliche. Se non sbaglio mongodb usa un approccio master/slave in cui c'è una copia principale su cui si scrive e poi questi dati vengono replicati sugli slave.

In Cassandra tutto funziona un po' come i raid più evoluti: si può decidere di dare l'ok alla scrittura quando almeno un tot di nodi hanno scritto lo stesso dato e questo garantisce una maggiore sicurezza in caso di fault.

Poi è scritto in Java e quindi ben integrabile con applicazioni scritte in questo linguaggio.

Dall'altra parte mongodb usa json (o meglio bson) come formato per i dati e secondo alcuni è più semplice ed efficiente per le query (basate su un javascript query language). Senza però dimenticare che Cassandra usa CQL, una specie di SQL rivisto, che rende meno traumatico il passaggio per chi è abituato a lavorare con i db relazionali.

Questo è naturalmente il mio punto di vista che spero possa essere integrato con le esperienze che altri di voi hanno (avuto) in merito. 

Mauro

Il giorno martedì 23 febbraio 2016 19:17:43 UTC+1, Mauro Cicolella ha scritto:

[alberto mengoli]

Ciao Mauro,

sempre puntuale e preciso come al solito; grazie. Ora e' tutto molto piu' chiaro. E' possibile andare un po' di piu' sullo specifico e creare un modello? Tipo diagramma di flusso; almeno per quanto riguarda la fase di immagazzinamento dati. Soprattutto per quello che riguarda il cosa e il come e su cosa conviene immagazzinare. Ciao, Alberto

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "Freedomotic - IoT and Smart Spaces Framework" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a freedomotic-i...@googlegroups.com.
Per postare in questo gruppo, invia un'email a freedom...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/835ffe29-cb3e-4e31-b397-6f4fbac14154%40googlegroups.com.

[Mauro Cicolella]

Prima di procedere andrebbe fatta un'ulteriore considerazione che apparentemente può sembrare in contrasto con tutto il discorso fatto finora ma che è necessaria per avere un quadro completo.
E' realmente necessario ricorrere ai db nosql oppure può bastare un approccio relazionale?
Una delle motivazioni che ha portato allo sviluppo del nosql (uso questo termine per indicare tutti i db di questo genere) è stato il volume di traffico da gestire da parte di colossi come Amazon, Google, Facebook ecc.
I database relazionali hanno per decenni gestito (e continuano a farlo perchè non sono morti) grandi volumi di dati, basti pensare alle banche, alla PA ecc. Con i social network, i motori di ricerca, i siti di e-commerce la quantità di dati è cresciuta di vari ordini di grandezza.
Questi dati devono essere accessibili da milioni di utenti contemporaneamente e da località geografiche molto diverse, quindi diventa fondamentale il supporto al load balancing, alla sicurezza, alla scalabilità.
Prima domanda: un sistema di home/building automation ha davvero bisogno di tutto questo? Ipotizzando di produrre un milione di record (uso questo termine) al giorno (tantissimi direi) ne avremmo 365 mln all'anno, un valore molto lontato dalle decine di miliardi prodotti dal miliardo di utenti di Facebook o dai circa 400 mln di Twitter.
Quanti possono essere gli utenti di questi sistemi? Alcune decine se ipotizziamo la gestione di un ufficio o di un edificio, meno di 10 per una casa.
Da dove accedono? Contemporaneamente dai 5 continenti? Molto improbabile.
Non potrebbe bastare un db relazionale con un opportuno sistema di replica?

Quindi arriviamo all'altro motivo che ha portato al nosql: la rimozione della rigida struttura dei db relazionali. Questa forma di "libertà" è in un certo senso un potenziale difetto nel senso che manca uno standard nel mondo nosql a differenza di quello relazionale.
Il risultato è che l'Harvester plugin che ho citato inizialmente può funzionare con mysql, sql server, h2, oracle ecc.
Con una soluzione nosql non è detto che si possa giungere ad una medesima interoperabilità: presa una strada è difficile tornare indietro.
Ovvero se optiamo per Cassandra è poi possibile passare a mongodb o ad altro (e viceversa) senza che questo abbia un grosso impatto sull'architettura del sw?
Non essendo aggiornatissimo al riguardo non saprei dire quale sia il livello di supporto di JPA con nosql.

Infine c'è da considerare l'aspetto "machine learning" e la necessità o meno di scegliere l'uno o l'altro approccio.

Come giustamente faceva notare Alberto "c'è bisogno di tanta potenza?" riferendosi a Cassandra in confronto ad altri db.
Io direi che bisognerebbe ulteriormente riflettere sui pro/contro del nosql rispetto al modello relazionale.

In ultima analisi torniamo alla domanda iniziale ma con più elementi: estendere e migliorare il plugin che già abbiamo o pensare ad una soluzione ex novo con nosql?

Mauro  

PS: tutta la questione sarebbe un ottimo argomento per una o più tesi di laurea

Il giorno martedì  23 febbraio 2016 19:17:43 UTC+1, Mauro Cicolella ha scritto:

[Matteo Mazzoni]

Ciao a tutti,

effettivamente introdurre il db avrebbe diversi vantaggi, principalmente riconducibili al log di eventi:

a) tracciare la storia di cosa è accaduto

b) analizzare i consumi (in base al periodo di accensione di un dispositivo e alla sua potenza nota o stimata)

c) analizzare, attraverso algoritmi di AI, il comportamento abituale per:

 - riprodurlo (es simulare la presenza)

 - anticiparlo (es. se ogni volta che entro in casa accendo la luce, il sistema potrebbe compiere l'azione in automatico quando apro la porta di ingresso...)

 - vigilare su eventuali anomalie di comportamento e generare alert (utile nall'ambito dell'Ambient Assisted Living: anziani in case intelligenti)

Secondo me si tratterebbe di una serie di feature davvero interessante ed innovativa.

A chi piacerebbe?

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "Freedomotic - IoT and Smart Spaces Framework" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a freedomotic-i...@googlegroups.com.
Per postare in questo gruppo, invia un'email a freedom...@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/18a0079b-6fb8-4227-9a56-c81a8ebcbf37%40googlegroups.com.

[alberto mengoli]

ciao,

@Matteo 1) sql oppure no-sql? 2) eventualmente avresti gia' in mente un modello con gli elementi essenziali da memorizzare?

ciao, Alberto

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/CABbWV0ufeZrQWJD65OVoL8u%2B5UG_cDqG%3D2EzrCynMjfC2mD0%2Bw%40mail.gmail.com.

[Matteo Mazzoni]

1) Decisamente no-sql, ma non per il fatto che 'fa figo', semplicemente perchè se andiamo a stoccare gli eventi, questi hanno una struttura diversa a seconda del tipo, quindi ci torna utile la versatilità del db documentale.

2) Direi che si possono memorizzare tutti gli eventi, facendo una scrematura di quelli legati allo scorrere del tempo (es. eviterei i tick emessi ogni secondo dallo scheduler, perchè non contengono informazioni utili)

In questa ottica i cambiamenti notevoli rispetto all'attuale approccio HARVESTER sarebbbero diversi:

a) il driver risulterebbe notevolmente semplificato perchè di fatto non dobbiamo gestire una miriade di possibili motori db

b) la quantità di informazioni registrate sarà nettamente superiore

c) potremmo prevedere delle apposite API per l'analisi dei dati (Machine Learning o controllo consumi, per dirne alcune).

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/CAOci-dTPKS3PyaV8zjwvywT49Y%3DvF3PZA7FW%3D7os%2BcTGq6L8Jg%40mail.gmail.com.

[alberto mengoli]

ciao,

@Mauro, concordi? A me sembra un punto molto interessante; tenete conto che la mia esperienza in paleoinformatica o oramai necroinformatica perche' quasi tutte le tecnologie dell'epoca sono morte, si limita ai database relazionali, quindi non ho elementi di giudizio.

@Matteo bellissima la strip!!! :))

Passando ad altro, questo e' l'approccio ai problemi che preferisco: diagramma di flusso decisionale; porta sempre a buoni risultati.

Ammesso che diamo per buono il punto precedente: 1) mongo db 2) cassandra; 

se non ho capito male differiscono molto anche nel modo di memorizzare le informazioni; JSON per mongo altro per cassandra, che peraltro sarebbe piu' biocompatibile con il framework se passiamo sopra al fatto che comunque parliamo di archivi. Ciao, A.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/CABbWV0s8t9c%3DMwFHHizwSY80e6_HdWFiewo%2BXQKw9YifgVdv3g%40mail.gmail.com.

[Mauro Cicolella]

Ciao a tutti

riprendo questa discussione un po' datata in quanto negli ultimi tempi ci sono state delle novità grazie al contributo del nostro nuovo e molto attivo collaboratore Ubaldo.

E' possibile seguire gli sviluppi direttamente su Github (https://github.com/freedomotic/freedomotic/issues/227).

Chiunque volesse partecipare proponendo suggerimenti può scrivere qui oppure commentare la issue.

Mauro

Il giorno martedì 23 febbraio 2016 19:17:43 UTC+1, Mauro Cicolella ha scritto:

[U. P.]

Ciao Mauro, ciao tutti!

Sì, ho cominciato a lavorare a questa issue implementando un layer di persistenza basato su Cassandra 3.9.

La mia idea è quella di persistere gli eventi (e i comandi) in maniera serializzata (pensavo di usare Avro) in modo da rendere il salvataggio indipendente da eventuali tabelle "relazionali" (CQL).
Come driver Java per comunicare con Cassandra sto usando la versione 3.1 del driver core di Datastax.

In questo momento il plugin è ancora in una fase embrionale di sviluppo e ovviamente sono ben accetti consigli e critiche :)

Il plugin contiene anche l'implementazione di integration test con un'immagine Docker di Cassandra (purtroppo avendo una macchina a 32bit mi sono dovuto scrivere una versione personalizzata dell'immagine).

Per qualsiasi dubbio mi trovate qui o su Github, ciao!

U.

[Mauro Cicolella]

Ciao Ubaldo

concordo con te nel senso che dovremmo riuscire ad ottenere un primo prototipo funzionante rimandando ad una seconda versione eventuali ottimizzazioni.

Non conosco Avro ma nel documentarmi mi sono imbattuto in questo articolo (parte di una serie) http://aseigneurin.github.io/2016/03/04/kafka-spark-avro-producing-and-consuming-avro-messages.html

Mi sembra di capire che sia comunque necessaria la definizione di uno schema da utilizzare anche in fase di decodifica dei messaggi. E' corretto?

Grazie

Mauro

Il giorno martedì 23 febbraio 2016 19:17:43 UTC+1, Mauro Cicolella ha scritto:

[U. P.]

Ciao Mauro,

esatto: serve una definizione di schema, che indicativamente va persistita insieme all'evento stesso.

In questo modo, in fase di deserializzazione dell'oggetto, si riesce a capire anche la versione dello schema di partenza, in modo da poter costruire opportunamente l'oggetto secondo la versione in cui esso è stato salvato (utile anche se si vuole dare la base dati in pasto ad un servizio esterno, e.g.: Spark Streaming).

Con una soluzione di questo tipo si riesce a garantire un comportamento robusto della deserializzazione anche a fronte di eventuali variazioni degli eventi da persistire.

La mia idea è quella di creare delle tabelle così composte:

id, evento_serializzato, schema_corrente, timestamp_di_salvataggio

Cosa ne pensate?

Colgo l'occasione per chiedere anche un'altra cosa: adesso sto sviluppando il meccanismo di persistenza come un plugin, quindi i dati verranno salvati solo se triggerati mediante un comando (e.g.: "SAVE_DATA").

Non potrebbe essere utile, magari in una versione successiva, di invocare la persistenza dei dati ad ogni chiamata di notifyEvent (cioè quando gli eventi vengono mandati ad ActiveMQ)?

Grazie per chiarire i miei dubbi e buona settimana :)

[Mauro Cicolella]

Ciao Ubaldo,

grazie per il chiarimento!

Immagino che tu stia seguendo l'approccio adottato dal plugin Harvester in cui il salvataggio è legato all'esecuzione del comando "SAVE_DATA".

Concordo con te circa la necessità di salvare tutti gli eventi notificati (e in seguito anche i comandi eseguiti).

Tuttavia potrebbe avere senso specificare il livello di granularità come avviene per i log in modo da "salvare" solo alcuni eventi. Mi riferisco ad esempio a quelli "temporali" utilizzati per la schedulazione di comandi e di cui si parla in questa issue https://github.com/freedomotic/freedomotic/issues/139

In pratica viene inviato un evento ad intervalli regolari e questo serve a far scattare trigger del tipo "ogni 10 secondi", "ogni minuto" e via dicendo.

Non credo siano rilevanti. Cosa ne pensi?

Riguardo alla soluzione in corso di sviluppo, premesso che il db Cassandra è stato un nostro suggerimento, resta aperta la porta all'utilizzo di altri db nosql ? 

Grazie mille e buona settimana anche a te!

Mauro

Il giorno martedì 23 febbraio 2016 19:17:43 UTC+1, Mauro Cicolella ha scritto:

[U. P.]

Ciao Mauro,

esattamente. Il salvataggio del mio plugin è legato al comando "SAVE_DATA": non avendo conoscenza approfondita del meccanismo del bus di eventi e comandi preferirei attenermi a questa soluzione.

Per quanto riguarda la persistenza -per adesso- il solo database gestito dal plugin è Cassandra (che è, probabilmente, una tra le migliori soluzioni per la persistenza di time series).

Puoi dare uno sguardo al mio fork su come sto impostando la cosa.

La descrivo brevemente anche qui:

- all'avvio del plugin viene inizializzata l'istanza per la gestione del Cluster Cassandra;

- il Cluster verifica se esistono già il keyspace e le relative "tabelle" per la memorizzazione di eventi/comandi. In caso negativo si preoccupa di crearle;

- alla ricezione del comando "SAVE_DATA" i dati ricevuti verranno salvati attraverso la chiamata ad un DAO di persistenza, che si preoccupa di serializzare il messaggio con Avro e di salvarlo opportunamente sul DB.

Cosa ne pensate?

U.

[Mauro Cicolella]

Ciao Ubaldo,

direi che usando questo approccio per ora possiamo già filtrare gli eventi che ci interessano rimandando ad una seconda fase il resto delle questioni accennate.

Riguardo al meccanismo di gestione del bus eventi e comandi, a parte il codice stesso che dovrebbe essere abbastanza autoesplicativo, stiamo lavorando alla documentazione per gli sviluppatori in modo da fornire una guida più chiara a chi voglia cimentarsi con il framework.

L'indirizzo è http://freedomotic-developer-manual.readthedocs.io/en/latest/ e chiaramente ogni critica/suggerimento è ben accetto.

Grazie mille

Mauro

Il giorno martedì 23 febbraio 2016 19:17:43 UTC+1, Mauro Cicolella ha scritto:

[alberto mengoli]

ciao a tutti,

sicuramente qui si sta creando qualcosa di estremamente interessante; non ho familiarita' con i database nosql, ma andando oltre la fase di storage dei dati, mi chiedevo se in prospettiva, per il recupero degli stessi ed opportuna loro manipolazione, non convenisse prevedere di integrare nella base dati alcune informazioni che a prima vista potrebbero sembrare ridondanti, come userid e password di chi ha effettuato il log, la data e l'ora di log e l'ora dell'evento da memorizzare; per quello che riguarda userid e password, si possono considerare superflui solo se il nostro modello prevedesse un persistence plugin per una sola istanza di freedomotic che gira su una macchina, ma dato che e' previsto un p2p, e quindi piu' istanze di freedomotic con relativi plugin, identificare un userid e una password equivale ad identificare a quale plugin di quale istanza appartengono i dati, a patto che non sia possibile far girare 2 istanze di freedomotic in p2p che abbiano stesso userid e stessa password (cosa direi auspicabile). Altrimenti bisogna identificare un campo univoco che contraddistingui una istanza e quindi un archivio da usare come chiave di ricerca. Inoltre @Ubaldo sarei curioso di sapere se della gestione dei dati memorizzati hai gia' in mente di chi se ne debba occupare (persistence stesso, automations editor, altro?). Grazie per il fantastico lavoro, buona serata, Alberto 

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "Freedomotic - IoT and Smart Spaces Framework" di Google Gruppi.

Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a freedomotic-it+unsubscribe@googlegroups.com.
Per postare in questo gruppo, invia un'email a freedomotic-it@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/0c2ef669-39f6-4955-adc3-10d67cdb099f%40googlegroups.com.

[fdf]

@Alberto non sono convinto che sia opportuno storicizzare le password degli utenti su qualsiasi db. Da un punto di vista di sicurezza costituirebbe una vulnerabilità di progettazione particolarmente rilevante e difficilmente risolvibile senza rimettere pesantemente mano al codice.

 Non vorrei aver interpretato male il tuo post, ma:

-Per gestire le autenticazioni degli utenti non è necessario memorizzare le password sul DB. Sarebbe in realtà auspicabile integrare il sistema con qualche servizio oauth (es. di google) anche solo per evitare agli utenti di  dover ricordare una nuova password.

-Per gestire eventuali necessità di ajutenticazione "application to application", forse è meglio usare meccanismi di autenticazione basati su chiavi asimmetriche (Rsa...) gestendo a runtime lo sbocco della componente privata.

Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a freedomotic-i...@googlegroups.com.
Per postare in questo gruppo, invia un'email a freedom...@googlegroups.com.

[U. P.]

 Ciao Alberto,

sono d'accordo con quanto scritto da fdf, cioè di non memorizzare la password insieme agli eventi. Invece, come da te suggerito, è sicuramente interessante l'idea di salvare, insieme all'evento, l'identificativo dell'utente/componente che lo ha generato.
Quest'informazione, infatti, risulterà importantissima in ottica di analisi dei dati, al fine di profilare più dettagliatamente il comportamento di singoli utenti.

Per quanto riguarda i timestamp ne prevedo due:

1. timestamp di persistenza a database
2. timestamp di generazione dell'evento

Sulla gestione dei dati persistiti, invece, penso che possa essere demandata ad altri componenti: il plugin Persistence si limiterà a salvare i dati su una istanza Cassandra residente su localhost (o su altre macchine remote, previa configurazione).

La mia idea per l'analisi dei dati salvati a database, quindi, è quella di prevedere dei processi batch, che leggano i dati da Cassandra per farne profilazione/analisi dati (e.g.: dei job Spark/Hadoop che lavorino autonomamente per analizzare i dati raccolti).


Cosa ne pensate?

Ciao e buona serata!

U.

Il giorno martedì 29 novembre 2016 23:51:29 UTC+1, alberto mengoli ha scritto:

Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a freedomotic-i...@googlegroups.com.
Per postare in questo gruppo, invia un'email a freedom...@googlegroups.com.

[alberto mengoli]

ciao a tutti,

Scusatemi, mi sono espresso un po' bovinamente ;) naturalmente non intendevo esporre in chiaro il campo password, ma pensavo ad un campo identificativo univoco, un po' come l'uuid per gli oggetti che fungesse da sicura chiave di ricerca/attribuzione dati visto che la problematica che si potrebbe porre in fase di elaborazione sarebbe distinguere anche dati di diverse istanze di freedomotic in p2p sulla stessa macchina e quindi autenticate dallo stesso utente (anche ammesso e non concesso che fosse possibile autenticare due istanze con stesso userid e password, ma questo sarebbe un altro problema).

@Ubaldo mi confermi che l'analisi dei dati avverrebbe in un secondo momento su Cassandra che si presume ogni archivio sia relativo alla singola istanza; ma poi che succede? Gli archivi vengono analizzati singolarmente o si ha prima una fase di aggregazione dati e poi si effettua lo studio?

Quello che avevo in mente era qualcosa tipo [Pinco] [uuid1] archivio istanza 1 di Pinco diverso da [Pinco] [uuid2] archivio istanza 2 di Pinco che disambigui un generico archivio di [Pinco]; dato il tipo di architettura si potrebbe anche demandare a Cassandra di rendere univoco l'archivio, ma farlo in fase di log penso che sarebbe meglio.

@fdf mi trovi d'accordo su tutto anche su oauth, nonostante mi pare di ricordare che a questo proposito siano state mosse critiche riguardo la sicurezza considerata bassa a livello di social networks e quindi indatta a gestire un programma che attiva l'allarme di casa; ma qui ritorneremmo alle mitiche considerazioni che all'epoca vennero fuori riguardo al livello di sicurezza stratosferico del web server bticino ed il cerchio si chiude

Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a freedomotic-it+unsubscribe@googlegroups.com.
Per postare in questo gruppo, invia un'email a freedomotic-it@googlegroups.com.
Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/c4710fbd-7c2e-4b8a-a7c3-d5789e531f78%40googlegroups.com.

[Mauro Cicolella]

Ciao a tutti

concordo con l'approccio proposto da Ubaldo.

Il plugin dovrebbe essere destinato alla raccolta dati che poi andrebbero analizzati in separata sede.

Tenete conto che Freedomotic può girare anche su sistemi embedded come Raspberry Pi e Udoo ma l'analisi dei dati è un task abbastanza pesante dal punto di vista computazionale quindi andrebbe gestito con risorse adeguate: un pc localmente o addirittura il cloud. Qualcosa di diverso da Freedomotic sebbene in grado di interfacciarsi per "suggerire" trigger o modificare la configurazione.

Personalmente diffido un po' di quelle soluzioni all-in-one in cui uno scatolotto fa tutto dalla raccolta dati, alla gestione dei device, all'intelligenza artificiale. Forse può andar bene per compiti semplici ma se cominci ad analizzare file di diversi GB e oltre ....

In effetti penso che anche lo stoccaggio dei dati non si possa affidare ad una scheda SD ma serva qualcosa di più robusto.  Come dicevo Freedomotic può girare benissimo sulle schede embedded ma l'attività di persistenza va fatta su hd disk sia per la capacità richiesta che per affidabilità e prestazioni.

La vostra opinione?

Mauro

Il giorno martedì 23 febbraio 2016 19:17:43 UTC+1, Mauro Cicolella ha scritto:

[alberto mengoli]

ciao,

@Mauro concordo; Ubaldo sta facendo un grandissimo lavoro e l'architettura e' robusta. Questa e' la sede piu' adatta per dargli una mano come umile contributo di idee e mi sembra si stia generando un brainstorming utile. Per la questione stoccaggio dati sui sistemi embedded mi verrebbe da dire di istinto che bisogna mettere tra i requisiti minimi di sistema inteso come impianto, almeno una intranet con dispositivo esterno tipo NAS o hard disk di rete se non si vuole rischiare di andare in presa diretta su cloud. Magari potrebbe essere utile specificare sul manifest file il percorso per indirizzare il plugin al database di persisitenza. Ciao, A.

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "Freedomotic - IoT and Smart Spaces Framework" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a freedomotic-it+unsubscribe@googlegroups.com.
Per postare in questo gruppo, invia un'email a freedomotic-it@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/fe6a494a-b45c-4c11-b758-8879ff414d17%40googlegroups.com.

[Mauro Cicolella]

Riguardo ai servizi di autenticazione di terze parti (tipo OpenID o OAuth) vi rimando ad una discussione già aperta su Github (https://github.com/freedomotic/freedomotic/issues/153)

Mauro

Il giorno martedì 23 febbraio 2016 19:17:43 UTC+1, Mauro Cicolella ha scritto:

[Mauro Cicolella]

Ciao a tutti

grazie al grandioso lavoro di Ubaldo il primo prototipo del plugin è pronto.

Potete trovare tutti i dettagli direttamente nella PR https://github.com/freedomotic/freedomotic/pull/243

Ogni suggerimento è ben accetto.

Grazie @Ubaldo, quanto prima faremo dei test. Se vuoi aggiungere qualche dettaglio in merito alla configurazione richiesta ... 

[U. P.]

Buongiorno a tutti,

come segnalato da Mauro ho preparato una prima Pull Request di un prototipo funzionante per il plugin di persistenza su Cassandra (versione 3.9).

Di default il plugin si aspetta di lavorare con una installazione locale di Cassandra, che risponde su localhost:7000, ma ovviamente mediante il file di configurazione è possibile specificare in dettaglio l'effettivo riferimento al Database e le relative strategy di replicazione (di default Singolo nodo, SimpleStrategy).

Ad oggi Persistence è stato testato solo con degli integration test per verificare la corretta serializzazione e persistenza di eventi su una immagine Docker di Cassandra.

La serializzazione viene eseguita con AVRO 1.8.1 e, sul database, per ogni evento, viene memorizzato il seguente contenuto:

uuid dell'evento, evento_serializzato, schema_di_serializzazione, timestamp_di_persistenza

In questo modo, per ciascuna entry memorizzata, sarà possibile ricostruire l'esatto contenuto dell'evento anche se, in futuro, si dovesse decidere di modificare il tipo di informazioni da memorizzare per ogni evento: lo schema della tabella Cassandra potrà rimanere immutato nel tempo mentre quello di AVRO potrà essere modificato secondo le effettive esigenze (e.g.: aggiungere o togliere campi agli oggetti che modellano gli eventi).

Il plugin che ho preparato si preoccupa di salvare eventi alla ricezione del comando "SAVE_DATA", così come lavora Harvester. Si veda qui per i dettagli.

Inoltre, nel DAO che esegue l'operazione di salvataggio, ho anche aggiunto un metodo di read di tutti i dati attualmente persistiti. La SELECT che recupera i dati si preoccupa di restituirli come una List<SerializedEvent>, così da consentire ai lettori a database di poter lavorare con i dati recuperati a proprio piacimento.

Per poter testare il plugin è sufficiente disporre di una installazione di Docker sulla propria macchina e lanciare il seguente goal Maven:

mvn verify

Questo comando fa partire un'immagine Docker di Cassandra 3.9 (a 32 bit) ed esegue una serie di test per:

 

 salvare eventi, 

 caricare eventi,

 deserializzare eventi

Fatemi sapere se avete dubbi o suggerimenti!

Intanto grazie,

U.

[Mauro Cicolella]

Ciao Ubaldo

sto cercando di testare il plugin. 

Nel mio caso ho bisogno di utilizzare un'istanza di Cassandra su piattaforma a 64 bit. Ho però notato che la compilazione del plugin fallisce in quanto come ultimo goal prova ad attivare docker localmente.

L'errore riportato è il seguente

Failed to execute goal io.fabric8:docker-maven-plugin:0.18.1:start (start) on project persistence: Execution start of goal io.fabric8:docker-maven-plugin:0.18.1:start failed: No <dockerHost> given, no DOCKER_HOST environment variable, no read/writable '/var/run/docker.sock' or '//./pipe/docker_engine' and no external provider like Docker machine configured -> [Help 1]

Come posso risolvere?

Grazie

[Mauro Cicolella]

In realtà dovrei usare un'istanza di Cassandra in esecuzione su un VPS (Debian) online anche se al momento questo non sta funzionando per qualche strano motivo.

[U. P.]

Ciao Mauro,

la versione contenuta nel pom.xml fa girare il container utilizzando la modalità host, quindi l'immagine dovrebbe prendere lo stesso IP della macchina ospite. Se hai bisogno di cambiarla devi modificare, nel pom.xml, la property:

<network> <mode>host</mode> </network>

In ogni caso ti giro un link alla documentazione del plugin Maven per Docker, in cui è specificato come modificare le varie property per eseguire l'immagine:

https://dmp.fabric8.io/

Fammi sapere se riesci a farlo partire!

Ubaldo

[U. P.]

Ciao Mauro,

che immagine docker stai usando?

Nel pom.xml del plugin c'è un goal di Maven in cui è definita la property CASSANDRA_ADDR. Dovresti aggiungerne una con il nome della variabile (e il relativo valore) come atteso dalla tua immagine Docker di Cassandra.

Fammi sapere se così riesci!

Ciao,

Ubaldo

[Mauro Cicolella]

Ciao Ubaldo,
per ora ho escluso i test e compilato il plugin senza problemi.
Sto utilizzando un'immagine docker di cassandra su un mio VPS online e riesco a collegarmi e creare il keyspace "freedomotic" dopo aver impostato l'ip del server nel file cassandra-config.xml.

[alberto mengoli]

ciao,

se puo' essere utile... confronto tra architetture database nosql sintetico ma esaustivo. Ciao, A.

--

Hai ricevuto questo messaggio perché sei iscritto al gruppo "Freedomotic - IoT and Smart Spaces Framework" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più le sue email, invia un'email a freedomotic-it+unsubscribe@googlegroups.com.
Per postare in questo gruppo, invia un'email a freedomotic-it@googlegroups.com.

Per visualizzare questa discussione sul Web, visita https://groups.google.com/d/msgid/freedomotic-it/1f4d39eb-5d68-4298-81de-84d473e99796%40googlegroups.com.

[U. P.]

Ciao Mauro, ciao tutti!

Bene, quindi adesso anche tu sei riuscito ad integrare il Plugin sul tuo ambiente. La configurazione è risultata facile?

Durante i test è emersa però una problematica che avrei piacere a discutere con voi tutti.

In questo momento, per lo sviluppo del plugin di persistenza, mi sono ispirato a quanto fatto precedentemente nel plugin Harvester, cioè la memorizzazione di eventi che hanno uno specifico set di properties:

"event.object.uuid"

"event.object.name"

"event.object.protocol"

"event.object.address"

e una serie di property per i timestamp:

"event.date.year"

"event.date.month"

"event.date.day"

"event.time.hour"

"event.time.minute"

"event.time.second"

Tali properties vengono lette dalle informazioni contenute nell'oggetto Command ("SAVE_DATA") e opportunamente deserializzate per essere poi salvate su Cassandra.

Da alcuni test sembra che parte degli eventi generati da automations non contengano tutte le properties di cui sopra, quindi il plugin non riesce a salvare correttamente tali eventi (e.g.: nel caso di timestamp mancanti lancia una NPE).

Cosa ne pensate se, a fronte della ricezione di eventi, essi vengano persistiti senza deserializzazione?

Ad esempio: l'oggetto Command contiene un set di properties al proprio interno e pensavo di recuperare tali properties come una stringa e salvarle direttamente.

Oppure si possono prevedere dei casi di default in cui per properties non esistenti vengono salvati eventi con dei valori messi a "null" (o a eventuali default).

Spero di essere stato abbastanza chiaro! :D

Fatemi sapere se per voi una delle due proposte può andare oppure se avete altri suggerimenti a riguardo.

Grazie e buona settimana,

Ubaldo

[Mauro Cicolella]

Ciao Ubaldo
come ti dicevo ho dovuto escludere i test per compilare in quando non sono riuscito ad effettuare correttamente la configurazione con la mia istanza.

Tuttavia il plugin funziona correttamente, ho dovuto solo sostituire a 127.0.0.1 l'ip del mio vps.

Riguardo al problema sollevato penso che in primo luogo bisognerebbe indagare circa l'assenza delle properties di cui dicevi per escludere del tutto eventuali bug.
Qualora alcune properties non ci fossero non credo sia necessario aggiungere dei valori di default a meno che questi non siano indispensabili, ad esempio il timestamp. In questo caso se non fosse reperibile dall'evento andrebbe comunque andrebbe aggiunto a partire dall'ora di sistema.
 
Le properties possono variare da evento ad evento e da command a command e questo è uno dei motivi che ci ha spinto ad adottare una soluzione nosql in cui il db non ha uno schema fisso.

Naturalmente è la mia opinione quindi lascio agli altri eventuali osservazioni.

Grazie mille

[U. P.]

Ciao Mauro,

grazie per i chiarimenti.

Vista la struttura dinamica degli eventi, forse è meglio creare la tabella su Cassandra come qualcosa del tipo:

UUID uuid, Date timestamp, Lista di attributi di base, Stringa serializzata di tutto l'evento

Così riusciamo a memorizzare una struttura dati che, allo stesso tempo, ci consentirà di raccogliere sia la versione deserializzata delle property che esistono nell'evento sia di lasciarle a null in caso di eventi senza di esse.

L'attributo Stringa serializzata di tutto l'evento, invece, conterrà la versione serializzata dell'evento, che in fase di analisi dei dati potrà essere usata in caso di fallback laddove gli attributi di base dovessero essere vuoti.

Cosa ne pensate?

Ciao e buona giornata,

Ubaldo

[Mauro Cicolella]

Ciao Ubaldo
penso che potrebbe essere una buona soluzione per salvare capra e cavoli.

[Mauro Cicolella]

Rieccoci,

dopo alcuni mesi di lavoro il nostro grande Ubaldo ha pubblicato la prima versione del plugin.

Trovate maggiori dettagli su http://freedomotic-user-manual.readthedocs.io/en/latest/plugins/persistence.html

Tuttavia se avete domande e/o suggerimenti commentate pure.

In questa fase abbiamo bisogno di fare dei test su larga scala per tarare il tutto e rimuovere eventuali bug che dovessero presentarsi.

Anche in questo caso il lavoro non è concluso ma si procede per step.

Si tratta di un plugin un po' più avanzato rispetto agli altri e quindi un buon argomento di base a livello accademico (per tesi di laurea) e scolastico in generale (tesine per la maturità). Ma come sempre è ben accetto il contributo di tutti.

Ancora un ringraziamento ad Ubaldo per il prezioso supporto.