I DATI IN TEMPO REALE

Visualizzare i dati di consumo (e temperatura) su un client in tempo reale

Per visualizzare i dati raccolti dal broker ho utilizzato una schermata di pygame già esistente nel mio Raspilight(la scelta è obbligata perché è una GI che permette di visualizzare facilmente al suo interno finestre web che mi servono per altri scopi).
Attraverso uno script in python mi collego al broker e scarico i dati dei topic sulla finestra in pygame. Ottengo così la visualizzazione della:
- temperatura cabina caldaia (che controlla la temperatura all’interno di detta cabina perché non scenda sotto zero)
- la temperatura esterna (che ho chiamato North per distinguerla da altri sensori eventuali)
- il contatore giornaliero del gas.
Utilizzo, come protocollo, Json per impacchettare i dati e farli inviare da MQTT. Come da informazioni sul web, Json è leggero, affidabile, permette l’invio di dati numerici ed è utile in caso di invio contemporaneo di più dati insieme.
Qui di seguito la parte essenziale del codice:


Nel ciclo principale, successivo al blocco sopra, si vede, all’inizio, un controllo da me ideato per ricevere un avviso nel caso di blocco del publisher.

Se il broker si spegne o cade c’è già un avviso di MQTT che gestisce l’errore: on_disconnect.

C'è poi una funzione, "keepalive" che controlla che un client sia attivo (a livello di connessione TCP) e, se cade, il broker manda un messaggio agli altri client con scritto quello che si vuole (my last will). Inoltre nel mio caso con un publisher ed un broker insieme, questa funzione non ha senso.

Se però a bloccarsi è il publisher a livello di programma, pur rimanendo attiva la connessione, questo non viene rilevato da MQTT che continua a pubblicare l’ultimo topic. Per ovviare a ciò, ho creato un topic, “time_pub”, che pubblica il Time del publisher, in modo da tenere una "sincronizzazione".
Nel ciclo riportato più sotto rilevo nel subscriber il tempo time_now (togliendo secondi e microsecondi) e, sulla base di questo, identifico altre due variabili, time_now_p1 e time_now_m1, rispettivamente il tempo più un minuto e meno un minuto.
Se il tempo del publisher è uguale al tempo del subscriber o lo stesso più un minuto o meno un minuto, procedo con il programma. La scelta di utilizzare un intervallo è dettata da esperienze che hanno mostrato che può esserci uno sfasamento di alcuni secondi che creerebbe falsi errori.
In caso di differenza, il programma prima riprova la connessione e se fallisce nuovamente da errore sullo schermo.

C’è poi un ulteriore controllo: se il topic “alerts” non è ok. L’alert è relativo alla temperatura nel box caldaia che se va sotto zero (pericolo di rottura della caldaia) mi manda una mail.
Oltre alla mail compare anche nel topic un messaggio che viene quindi visualizzato sullo schermo. Questo if, visibile sotto, fa dunque questo lavoro.

In realtà il messaggio sarà di complemento ad una funzione che vorrei realizzare in uno dei due modi seguenti. Potrei mettere una elettrovalvola su un tubo dell’acqua sanitaria che, una volta rilevata la temperatura a rischio gelo, aprirà l’acqua calda per mettere in moto la caldaia.
Questa soluzione però deve essere a prova di errore perché c’è il rischio che se qualcosa non funziona rimane aperta l’elettrovalvola.
Un’altra soluzione è quella di utilizzare IFTTT e innescare un riscaldamento in una stanza in caso di temperatura esterna pericolosamente bassa. Ne parlo a parte.


Ecco il ciclo while:



Nell'immagine sotto vedete uno screenshot del monitor che presenta questi dati (incluso un grafico ad anello per il consumo giornaliero). La temperatura sala non è collegata perchè si tratta del raspi che uso per il test.