InfluxDB plugin per Freedomotic

Una delle feature indispensabili per qualsiasi framework IoT è costituita dalla persistenza dei dati. Ciò consente di tenere traccia delle varie attività svolte e di raccogliere le misurazioni dei sensori per successive elaborazioni. Pensate ad esempio all’analisi dei consumi energetici o ad applicazioni di machine learning in cui il sistema apprende le abitudini degli utenti: temperatura preferita in ciascuna stanza, tempi di entrata/uscita dalla casa e via dicendo.

Anche per Freedomotic ci siamo posti questo problema.

Inizialmente è stato sviluppato il plugin Harvester per raccogliere gli eventi generati dal sistema ma ben presto ci siamo accorti che una soluzione del genere non poteva appoggiarsi ad un database relazionale per due motivi principali (che sono poi gli stessi che hanno portato allo sviluppo dei database NoSQL): la mole di dati da gestire e la mancanza di uno schema fisso per gli eventi.

Infatti gli eventi gestiti dal sistema tendono a crescere esponenzialmente in quanto non solo riguardano le misurazioni dei sensori ma anche il cambio di stato degli oggetti e tutte le interazioni degli utenti attraverso dispositivi fisici o comandi “virtuali” impartiti via software.

Inoltre ciascun evento presenta diverse proprietà quindi è estremamente difficile cristallizzare il tutto in uno schema rigido come quello dei database relazionali.

Quindi la scelta è ricaduta su database Cassandra intorno al quale abbiamo creato un plugin specifico.

Allo stesso tempo abbiamo pensato ad una alternativa più soft da utilizzare esclusivamente per lo stoccaggio dei dati relativi ai sensori e allo stato dei device elettrici in modo da poter creare facilmente dei grafici e fare delle analisi delle serie temporali.

In questo caso ci siamo affidati a InfluxDB per le sue caratteristiche, la sua diffusione e la disponibilità di un client per Java.

Chi volesse può approfondire leggendo questo post.

Attualmente il plugin utilizza il seguente meccanismo che richiede di impostare una semplice automazione:
[quando un oggetto cambia il suo stato (ad esempio la temperatura)] -> [salva i dati].

Nel momento in cui il device fisico invia la misura, se questa è differente da quella corrente viene generato un evento che è catturato dal trigger e porta al salvataggio dei dati.
C’è quindi una sincronizzazione tra l’acquisizione da remoto e lo storage. Non bisogna impostare nessun intervallo in quanto ci si regola con quello dei sensori.
Se però la misura corrente non è diversa da quella già associata all’oggetto non viene effettuato alcun salvataggio.
In sostanza se immaginiamo che un termometro mandi una misura ogni 2 minuti ci aspetteremmo 30 registrazioni nell’arco di un’ora. Ma se la temperatura è costante per un certo lasso di tempo avremo un numero di registrazioni inferiore o al limite 1 sola se la misura non cambia per tutto l’intervallo di tempo o addirittura nessuna, ipotizzando che non ci sia alcuna variazione.
Chiaramente è un caso limite ma va comunque considerato.
Tra parentesi si può anche decidere se acquisire solo particolari sensori (filtrando il nome) o un’intera categoria (solo thermometer o anche light se vogliamo sapere quando vengono accese/spente).

Va detto che non è ancora implementata la parte di recupero dei dati dal db anche se questa non è necessaria se i grafici vengono fatti con altri tool come grafana.

Sono in corso dei test su larga scala e lunga durata per evidenziare possibili malfunzionamenti. Potete seguire la relativa discussione sul nostro Google group.

Come sempre il codice è a disposizione di chiunque volesse consultarlo sul nostro repository GitHub.

Lascia una risposta

L'indirizzo email non verrà pubblicato. I campi obbligatori sono contrassegnati *

Utilizzando il sito, accetti l'invio dei cookies da parte nostra. Maggiori informazioni

Questo sito utilizza i cookies per fornire la migliore esperienza di navigazione possibile. Continuando ad utilizzarlo senza modificare le impostazioni o cliccando su "Accetta" acconsenti al loro utilizzo.

Chiudi