L'entità filter di Home Assistant - Parte 4

Qui la terza parte.

Come dicevamo, ho giocato un po' con l'arrotondamento.

Stanotte è crashato HomeAssistant (colpa mia, succede se non sai usare i cicli e mandi in loop un'automazione...), quindi non considerare la linea piatta centrale.

Ho usato window_size a 1 time_constant a 5. Come vedi ci sono due sensori filtrati: in quello rosso ho arrotondato dopo l'ultimo filtro (tsma), nel secondo ho arrotondato in entrambi i filtri (tsma prima e lowpass poi). Risultato: i due filtri sono identici.

Passando alle prestazioni, la morbidezza della curva è buona ma nulla che non avessimo già visto, mentre il picco in alto è fortemente smorzato: ballano 1.6 gradi tra l'uno e l'altro, troppi.

Stessa cosa per la potenza, i due sensori diltrati danno gli stessi valori. In questo caso ho configurato i filtri con window_size a 8, radius a 4.0 e window_size a 1. E, come vedi, non sono nulla di che: attenua solo un po' i picchi ma senza incidere più di tanto. Anche la durata di quello che ormai sono abituato a chiamare "drop" è eccessiva. 

Considerazioni

Per le temperature dovrò fare un passo indietro, se non due: i filtri combinati non mi hanno dato i risultati che speravo. Quindi devo analizzare un po' di dati e farmi ordine in testa.

Per la potenza credo che sarebbe utile arrotondare alle decine, invece che alle unità. Così dovrei ridurre di molto la varianza senza incidere sui picchi. Poi credo si tratti solo di regolare qualche parametro di fino.

L'entità filter di Home Assistant - Parte 3

Qui la seconda parte.

Orbene, ci eravamo lasciati (se ben ricordi. Se non ricordi bene, guardati le altre puntate) su altri due parametri da analizzare la precision (cioè l'arrotondamento) e la combinazione di più filtri. Il problema infatti era che pur avendo attenuato la curva fino a renderla più continua ed eliminando i picchi, restava comunque il fatto che le letture erano sempre troppo frequenti. 

Precision

Questo parametro indica semplicemente la quantità di cifre dopo la virgola. Ho applicato il filtro TSMA con precision 1 e valori di window_size a 1, 5. 30 e 60 minuti.

Solo ora mi accorgo che avevo configurato il sensore con window_size a 1 minuto con la precision era a 0. My fault...

In ogni caso, è evidente il minor numero di scritture, che è sostanzialmente identico a quello del sensore grezzo. A valori di windows_size elevati (30 e 60) è ancora minore (ma come abbiamo visto nelle puntate precedenti si perde molto dei picchi iniziali). L'errore sul window_size a 1 minuto, dove avevo impostato precision a 0, mostra chiaramente come il valore viene scritto solo se cambia di stato, il che spiega molte cose: con la precision non impostata, i filtri danno quasi sempre risultati con 2 cifre significative, il che porta ad avere valori quasi sempre differenti ad ogni lettura. Diminuendo la precision le probabilità che il valore sia simile al precedente (evitando quindi una scrittura) aumentano decisamente.

Passiamo alla potenza.

In questo caso la precision era impostata a 0. Valori di window_size  di 30 e 60 sono inutili, mentre con gli altri valori la precision non cambia la situazione: i valori in ingresso sono sempre molto aleatori, dunque basta una variazione di 1W per causare una scrittura. Si potrebbe modificare il template del sensore per diminuire la precisione alle decine invece che alle unità, ma lo trovo eccessivo.

Filtri combinati

Vediamo ora come si comportano più filtri combinati assieme. Per la temperatura ho scelto i filtri che avevano dato maggior impatto, ovvero TSMA e lowpass, rispettivamente con window_size a 10 minuti e time_constant a 10. Ho creato due sensori, invertendo i due filtri per capire se l'ordine di applicazione avesse qualche influenza sul risultato (lascia perdere il nome della card, è un errore).

Come vedi, nessuna influenza: i tracciati rosso e verde sono identici. La curva è meno precisa rispetto al solo tsma, mentre il numero di lettura è identico (ricordo che qui non ho usato precision). Ipotizzo che utilizzando valori più ridotti per i filtri ma impostandone la precision a 1, potrei ottenere il risultato ottimale.

Vediamo sulla potenza.

In questo caso l'ordine ha invece una certa incidenza: il picco infatti viene tagliato di quasi 30W se si imposta prima tmsa rispetto ad outlier. Inoltre la durata del "drop" è maggiore. Meglio quindi metterli in questo ordine. Il comportamento è comunque piuttosto buono: pur perdendosi il picco iniziale, poi il grafico è abbastanza lineare ed il "drop" è molto breve, rispetto all'applicazione di uno solo dei filtri. Anche in questo caso, non avendo impostato la precision, il numero delle scrittura è invariato. 

Ancora qualche prova

Mi sento vicino alla meta. Imposterò il filtro di temperatura con valori di window_size a 1 minuto e time_constant a 5, ma stavolta impostando anche la precision a 1. Riguardo la potenza, imposterò l'oulier  a 8/4, ma porterò il tsma a 1, regolando anche qua la precision (a 0, però).

L'entità filter di Home Assistant - Parte 2

Qui la prima parte.

Orbene, passiamo all'ultimo filtro che volevo analizzare:

Time Constant 

Il filtro ha un solo parametro window_size, espresso in tempo ("xx:xx"). Ho impostato diversi sensori filtrati con parametro a 1 minuto (rosso), 5 (arancio), 10 (verde), 30 (azzurro) e 60 (blu). La lettura grezza è in viola. Ho usato i soliti sensori dell'altra volta (uno di temperatura ed uno di potenza). Partiamo dal primo:

1 minuto è troppo poco, considerato che il sensore leggo proprio ogni 60 secondi. Come  mi sarei aspettato dalla teoria, il tracciato rosso e viola sono identici. Gli altri sono tutti utilizzabili, a seconda del grado di precisione che desideri: 5 e 10 danno un'ottima risoluzione, 30 e 60 danno comunque una buona indicazione dei valori raggiunti. 60 minuti è forse un filo eccessivo, perché la precisione con la quale segue la curva originale è un po' sfalsata nel tempo. Ma dipende dall'uso che devi farne. Personalmente credo sceglierò 10 minuti, mi sembra un buon compromesso.

Passiamo all'altro sensore.

I valori di 30 e 60 minuti sono da scartare. La potenza fantasma dopo il "drop" è eccessiva. Anche il picco iniziale è troppo moderato. 1, 5 e 10 sono utilizzabili, ma con pro e contro differenti: ad 1 minuto, il tracciato segue quasi perfettamente quello originale, moderando un poco si ai picchi che la varianza. A 10 la moderazione è molto più evidente, tanto che la linea è quasi piatta, ma al costo di tagliare via i picchi (quasi 200W in meno nei picchi più alti). Alla fine la soluzione migliore anche in questo caso è quella a metà: con 5 i picchi sono simili a 10, ma la curva segue ha meno ritardo nella risposta. 

Dunque...

Questo filtro è forse il più utile, ma ho scoperto che così com'è configurato attenua i picchi (e ci mancherebbe, è pensato per quello...) ma non agisce sul numero di scritture in modo sostanziale: la temperatura mostra una lettura ogni minuto, con qualunque impostazione, mentre la potenza circa una lettura ogni 3, indipendentemente dal valore impostato per window_size. La cosa mi lascia un po' perplesso. Ho due idee: una è che non ho impostato la precision, ovvero l'arrotondamento; l'altra è che sia necessario combinare due filtri per ottenere questo effetto. Farò altri test.

L'entità filter di Home Assistant

Si, mi sto scimmiando con la domotica, ma di questo ti parlerò un'altra volta. Oggi devo fare un riassunto su quanto ho capito sulla funzione filter, perché in tal senso la guida è piuttosto superficiale ed in giro non ho trovato granché. Sicuramente la colpa è mia che non ho mai studiato elettronica. Ma tant'è.

Il problema è: "moderare" un segnale che viene da un sensore per tagliare picchi e valori "sballati" ed avere un andamento del grafico il più possibile attinente con la realtà. I sensori mandano letture ogni 10-20 secondi, a volte 1-5-10 minuti, e pur essendo utile per poter fare determinate azioni nell'immediato, salvare tutti quei dati nel DB non è utile per tre motivi:

1. i grafici che si generano sono brutti e poco utili
2. c'è un continuo accesso al disco (non fa bene né al disco né alla bolletta...)
3. il DB con ancora pochi sensori ed uno storico di 15 giorni è già diventato di 12GB.

I filtri principali che intendo usare sono:

• LOW-PASS
• OUTLIER
• TIME SIMPLE MOVING AVERAGE

Utilizzando i valori indicati nella guida e facendo qualche prova non sono riuscito ad ottenere il comportamento che mi aspettavo, quindi dopo un po' di giorni inconcludenti ho deciso di tagliare la testa al toro dopo averlo preso per le corna: ho creato un po' di sensori filtrati, variando un parametro alla volta, per vedere come cambiava l'output.

Ho deciso di usare due sensori: uno che legge una potenza (in W), perché varia molto velocemente e di valori molto diversi (0W come 500) ed ha letture ravvicinate (ogni 20 secondi circa); l'altro è invece un sensore di temperatura che al contrario ha letture più lente (ogni minuto) e variazioni molto più moderate.

Per ora ho analizzato separatamente un filtro LOW-PASS ed uno OUTLIER, variandone un solo parametro alla volta. Mi sono così trovato 26 sensori, li ho composti in 6 grafici e questo è il risultato.

Lowpass 

Il sensore di temperatura è stato filtrato impostando il parametro time_constant sui valori 5 (rosso), 10 (arancio), 30 (verde), 60 (azzurro), 120 (blu). In viola il sensore non filtrato. Come puoi vedere, con 120 e 60 le linee sono un po' troppo attenuate per dare un valore realistico: il grafico "si perde" quasi un grado di temperatura massima e minima. A 30 va meglio, ma preferisco valori tra 5 e 10 (forse si potrebbe arrivare a 15...). Di seguito un grafico con solo questi valori:

10 va più che bene...

Da questi grafici deduco che per un sensore come quello di temperatura (o umidità, pressione, ecc... cioé quelli con variazioni più graduali e non improvvise) il filtro lowpass lavora bene: con un time_constant di 10 su letture di 1 minuto il grafico è molto lineare ma senza tagliare troppo i picchi.

Passando al sensore di potenza le cose sono più complicate:

Tranne con 5 e 10, gli altri tagliano il grosso picco iniziale, che non sarebbe un problema (in fondo è un picco davvero molto breve) se non fosse per il comportamento che si ha quando la potenza cala bruscamente a zero (il condizionatore si è spento): il sensore filtrato continua a mostrare una lettura di potenza anche per molte ore dopo che la lettura dovrebbe essere zero. Valori superiori a 10 in questo caso sono inutili. Vediamo a 5 e 10:

La durata del "drop" è minima, ma anche il taglio dei picchi è poco marcato. 

Il "drop" in questo caso dura qualche ora, ma in compenso i picchi sono molto più ridotti.

Il filtro lowpass su questo tipo di sensore non lavora bene, per lo meno non da solo. L'unico valore accettabile per time_constant è 5, anzi, forse anche meno. Ma a questo punto l'incidenza sul grafico sarebbequasi nulla.

Andiamo avanti.

Outlier

Il filtro oulier è più complicato, perché ha due valori configurabili. Ho quindi creato 8 sensori filtrati per ogni sensore: nei primi 4 ho variato windows_size lasciando fisso radius (con valori di 2/4, 8/4, 16/4 e 32/4), negli altri 4 ho fatto il contrario (usando dunque 4/2, 4/4, 4/8 e 4/12). Vediamo com'è andata:

No, nessun errore: variando il filtro oulier sul sensore di temperatura, anche con valori alti, non porta ad alcuna variazione. Il grafico è identico per tutti i valori. Nulla da vedere, qui, circolare.

Ho messo visibile solo uno dei filtri perché quello degli altri era identico (e questo era più visibile). In sostanza c'è un leggero taglio dei picchi, ma nulla di granché incisivo. Anche dopo il comportamento dopo il "drop" è sostanzialmente indistinguibile. In sostanza, un filtro poco utile anche in questo caso.

Ok, finalmente qualcosa si muove: con 2/4 la situazione è identica a quanto visto sopra (poco taglio dei picchi, andamento quasi identico ai valori non filtrati). Con 32/4 al contrario c'è un taglio estremo dei picchi (che andrebbe anche bene) ma un "drop" che dura troppo. 

Riguardo i valori centrali, 8/4 taglia poco i picchi ma in compenso il "drop" dura quasi zero, mentre con 16/4 è più lungo (circa 10 minuti) ma in compenso la linearità è quasi perfetta.

Il filtro outlier dunque, con sensori a letture distanziate e poca varianza è inutile, con sensori a letture più ravvicinate e con alta varianza è utile a moderare i picchi (con valori tra 8/4 e 16/4) ma probabilmente necessita di essere associato ad altri filtri.

Riassumendo

Cosa posso dirti su questi filtri?

Prima cosa, fondamentale: da soli non servono a risolvere i problemi di carico sul DB: il numero di letture ed il numero di dati salvati rimane lo stesso. Sul grafico invece ci sono netti miglioramenti nella visualizzazione, perlomeno in alcuni casi.

Un filtro lowpass su sensori con poca varianza e letture saltuarie, se ben tarato, traccia grafici lineari e ben leggibili, anche da solo.

Al contrario per sensori ad alta varianza e con letture frequenti è necessario molto più lavoro: sia i filtri lowpass che outlier devono essere configurati su valori molto bassi per non causare una durata del "drop" esagerata, tanto da rendere l'incidenza dei filtri molto poco visibile. Forse un lowpass a 5 ed un outlier 8/4 potrebbero mitigare un po' l'andamento.

Ecco, per ora è tutto, farò dei test con il filtro time simple moving average, poi dovrò cominciare a combinare i vari filtri e vedere quel che viene fuori.

Spero di esserti stato utile.