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ò).
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.
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:
i grafici che si generano sono brutti e poco utili
c'è un continuo accesso al disco (non fa bene né al disco né alla bolletta...)
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.
Funzionano decentemente, non sono granché integrabili e si usano solo dall'app Mi Home. Ma la risoluzione è buona, la copertura dell'illuminazione IR notturna decente e sono abbastanza stabili (per lo meno 2 su 3). Saltuariamente si trovano in offerta a circa 25€, quindi ne ho fatto incetta.
A lavoro nessun problema, ho configurato un'utenza dedicata sul NAS e la cam vi riversa quello che registra (occhio che serve comunque una microSD).
A casa invece, non c'era verso di configurarle perché salvassero sul NAS casalingo su base Ubuntu.
In sostanza non riesce a negoziare un protocollo con il client.
Sul web consigliano di settare il protocollo minimo alla versione 1 di Samba, inserendo nel file di configurazione /etc/samba/smb.conf la riga:
client min protocol = NT1
Però non funziona. Provo anche con il valore "CORE" al posto di NT1 (anche se in realtà sono la stessa cosa). Poi ravano nell'help di Samba e trovo anche altri valori relativi al protocollo minimo. In particolare questo:
server min protocol = NT1
Bingo!
Ora va. Devo solo creare un'utenza dedicata:
sudo useradd cam
sudo passwd cam
sudo smbpasswd -a cam
e poi aggiungere lo share al file smb.conf:
[Cam]
comment = Share per le CAMs
path = /Path/Cam
valid users = cam
public = no
writable = yes
create mask = 0644
directory mask = 0755
; if you set this, all files get written as this user
Quando un NAS smette di funzionare non è mail una buona notizia.
Soprattutto quando è un NAS proprietario, vecchio, su CPU Spark su cui nessuno vuole metterci le mani.
TRANNE TE
Quindi bando alle ciance e vediamo di recuperare qualcosa.
Il modello è Netgear ReadyNAS Duo (V1), con due dischi in mirror (RAID 1) da 500GB. Monta un OS linux-based, con l'ultimo firmware beta reperito sul forum netgear (4.1.18 T9, se non ricordo male). Dirai che è vecchio e che mi merito tutti i mali del mondo... beh, forse hai ragione.
Riassumendo la situazione: probabilmente in seguito ad una mancanza di alimentazione, il NAS si accende (è già una cosa buona), i dischi girano (ancora meglio) ma non è raggiungibile ne da frontend ne da SSH/telnet (molto pessima).
Provo con qualche riavvio, scollego uno e poi entrambi i dischi, ma nulla da fare. Si avvia ma è inutilizzabile. Non mi arrischio al reset, perché non vorrei perdere le varie configurazioni o, peggio, rischiare di perdere i dati.
La priorità è ovviamente verificare che siano ancora lì.
Telnet (o SSH) sull'IP del NAS con username=root e pswd=infr8ntdebug
Monto la partizione
/bin/start_raid.sh
mount /dev/hdc1 /sysroot
Vado su /sysroot e vedo che tutti i dati ci sono... fiuu!
Sollevato dalla buona notizia devo cercare il modo di metterli in salvo. Netgear ha fatto le cose per bene (meh...), quindi monto uno dei dischi su un PC linux (Ubuntu) e provo a montarlo. Nada.
Scartabello un po sulla rete e scopro che usa LVM (che non conosco). Trovo una guida che parrebbe fare al caso mio, ma non funziona. Dopo un po' di prove, per fortuna, riesco. Ecco come:
Come prima cosa mi copio le cose importanti sul disco di sistema, così posso usarlo come NAS temporaneo nel mentre che smanetto su quello reale. Fin qui tutto bene (relativamente parlando).
Purtroppo per lo scatolotto c'è ben poco da fare. Provo a skippare il check dei volumi, a svuotare la partizione di sistema dai log, a riflashare il firmware con un OS reinstall. Niente da fare.
Mi rassegno a resettare del tutto il NAS: in effetti ho fatto bene a non farlo alla cieca, perché avrei formattato i dischi e tanti saluti ai miei dati.
Dopo il reset completo finalmente il NAS si rianima: lo riconfiguro, ricreo le condivisioni e ci ricarico i dati prendendoli dal disco montato come di cui sopra (tramite rsync).
Dopo mille peripezie sono riuscito a settare a dovere Samba sul NAS (Ubuntu 20.04). Provando ad accedere da un client Ubuntu 16.04 sembrava funzionare tutto, poi dopo qualche giorno non sono più riuscito a navigare sul server da Nautilus (l'interfaccia grafica per la gestione dei file).
Da altri client (LibreELEC, VLC, Android, Windows 10) invece continuava a funzionare. Molto strano.
Gira che ti rigira installo "smbclient" sul cliente non funzionante e dopo averlo avviato ricevo questo errore:
Inizio a googlare questo errore ed arrivo a questa pagina, dove comprendo che dovrebbe essere un problema di versione del protocollo. Inserendo infatti il parametro "-m smb3" in smbclient, il tutto funziona. Per risolvere consigliano di inserire alcuni parametri:
client min protocol = smb2
client max protocol = smb3
nel file di configurazione di Samba del server:
sudo nano /etc/samba/smb.conf
e, nello specifico, nella sezione [Global], per poi riavviare il servizio:
sudo service smbd restart
Eseguo ma, come puoi ben immaginare, non funziona una cippa. Mi accerto tramite un trick di star editando il file di configurazione corretto (modifico il nome del file di log e riavvio il servizio, trovando il log con il nuovo nome ho la conferma che il file di configurazione che sto editando è quello corretto).
In altre pagine trovo le medesime indicazioni, ma il tutto continua a non funzionare. Arrivo infine qui dove capisco che il file di configurazione di Samba è sia sul server che sul client.
Bingo.
Edito il file smb.conf sul client, inserendo dopo alcune prove questi parametri nella sezione [Global]:
client min protocol = SMB2
client max protocol = SMB3
min protocol = SMB2
max protocol = SMB3
Riavvio il servizio sul client e testo con smbclient.
Funziona.
Provo con Nautilus.
Funziona.
Parafrasando Elio e la sua "Puzza edition" de "La Terra dei Cachi", facciamo due conti. Perché mi sono comprato un'auto elettrica e, tra le varie motivazioni che mi hanno spinto a questa scelta, una non poteva che essere economica. Non l'unica, stai attento, perché per il 99% del tempo la comodità di un'auto elettrica (di seguito EV) è inarrivabile è per un'auto a combustione interna (ICE). Ma di questo ne parleremo un'altra volta.
Le auto elettriche costano, inutile negarlo. Solo la batteria incide per diverse migliaia di euro, senza contare il motore (quasi altrettanto), il caricabatterie interno, il controller, ecc... Certo, il sistema è molto più semplice, non ci sono le migliaia di pezzi che compongono un motore a scoppio, ma l'economia di scala è ancora ai livelli iniziali. Quindi si, le auto elettriche costano.
Ma è altresì vero che la gestione quotidiana è molto più economica. Considerato che molto (troppo) spesso mi sono trovato a rispondere alla fatidica affermazione, preferisco scrivere qui i miei conti, così da non doverlo rifare ogni volta. Questo blog è o non è un repository della mia mente?
Riavvolgiamo di qualche mese. La vecchia Mazda 2 di quasi 10 anni e 130.000km, con impianto a GPL è una buona auto, sufficientemente comoda e parsimoniosa (grazie al gas), ma complice il crescere dei bambini e i primi acciacchi meccanici, giungiamo alla decisione di doverla cambiare. Pensiamo dunque ad un'auto del segmento C, ovvero una media con un bagagliaio sufficientemente ampio, bassi consumi (soprattutto in città) e abbastanza comoda. Per "colpa sua", scopro che il mercato dell'usato per le auto elettriche (mio pallino già da diversi anni) è già discretamente florido di offerte, con prezzi abbordabili anche per le mie tasche. Osservando i vari modelli, riduco la scelta tra BMW i3 e la Nissan Leaf, preferendo poi la seconda per via della migliore abitabilità e spazio di carico. Scorrendo tra le offerte trovo un'auto semi-nuova (1 anno e mezzo di età, 25.000km, batteria al 96%) a 19.000€.
Ottimo, mi dico, ci posso arrivare, con qualche sacrificio. Ma prima, meglio fare due conti.
Un'auto della stessa categoria (segmento C) con la stessa età, pari chilometraggio e impianto a GPL (es. Ford B-Max 1.4 90 CV GPL Plus, più grande ma meno potente e meno accessoriata) costa circa 13.000€. La differenza, dunque, è di 6.000€. Vediamo però quanto una EV permette di risparmiare.
Le maggiori fonti di spesa per un'auto sono:
Carburante
Assicurazione
Bollo
Manutenzione (tagliandi)
Carburante
Noi percorriamo circa 13.000km l'anno. Parlando di consumi reali (e non di quelli dichiarati, che ovviamente sono irrealistici), la Leaf usa circa 1857kWh di energia per quella percorrenza, ovvero 390€ alle tariffe casalinghe. La ICE di cui sopra fa circa 12km/l, ovvero 730€ alle tariffe GPL attuali (a benzina le ICE consumano meno ma il carburante costa di più). Questo significa un risparmio netto di 340€ l'anno.
Assicurazione
A parità di condizioni, assicurare la Leaf del 2016 costa 180€ l'anno (ITAS Assicurazioni con convenzione Cooperativa Insieme). Una ICE di pari categoria 535€ (prezzo più basso scovato sui comparatori online). Altri 355€ di risparmio annuali.
Bollo
La Nissan, come tutte le EV, non paga il bollo per 5 anni (ovvero per altri tre anni, visto che è del 2016). Successivamente pagherà il 25% di quanto teoricamente dovuto, ovvero 56€. Una ICE di pari potenza (88kW) invece paga fin da subito 227€. Quindi un risparmio di 227€ per tre anni, successivamente di 171€.
Manutenzione
Il tagliando annuale per una Leaf (quasi obbligatorio, visto che è necessario per poter usufruire della garanzia di 8 anni sulla batteria), varia tra i 60 e gli 80€ (dipende dalle officine). Per una ICE di pari categoria, siamo intorno ai 250€ (per lo meno i primi due tagliandi). Il risparmio in questo caso è di 180€ circa.
Riguardo alla manutenzione, però, c'è da considerare che le auto elettriche non consumano le pastiglie (50€ ogni 2 o 3 anni, in media), non devono fare cambi olio (altri 50€ circa, sempre ogni 3 anni, almeno) e neppure revisioni dell'impianto GPL (circa 45€ dopo i primi 4 anni e poi ogni 2). Questi costi sono dunque, ammontano dopo 6 anni a 290€.
Questo senza considerare eventuali guasti, che non sono preventivabili (anche se l'esperienza dice che le EV sono molto meno propense ai guasti rispetto alle ICE).
Tiriamo le somme.
Il risparmio annuale, considerate le voci di cui sopra, ammonta a 1102€ per i primi 3 anni. Aggiungendo i costi di manutenzione ed i bolli ridotti, dopo 6 anni con una EV risparmio 6734€. Se ricordi, la differenza nel prezzo di acquisto era 6000€. Questo significa che in 5 anni si annulla la forbice tra i prezzi di acquisto iniziali.
A questi si dovrebbero aggiungere eventuali risparmi bonus (molte colonnine sono gratuite, mentre distributori che regalano benzina non ne ho mai visti, le soste gratuite su strisce blu, l'accesso alle ZTL, ecc...), ma questi sono vantaggi aleatori, che oggi ci sono e domani potrebbero scomparire. Inoltre sono poco valutabili a priori, non mi sembrava giusto inserirli in questi calcoli.
Ripeto: ho fatto i conti cercando di mantenere il più possibile le stesse condizioni (auto della stessa categoria, stessa potenza, stessa età e chilometraggio, allestimenti simili, ecc...), anche se confronti al 100% uguali non sono possibili. Ma sarebbe anche inutile confrontare una Leaf da 19.000€ con una Panda da 5.000€. O con una Golf del 2010.
Sono conteggi teorici però, e seppur verosimili, sono suscettibili a variazioni. E valgono per l'usato, anche se in linea di massima si possono fare calcoli simili anche per il nuovo. Ma il senso rimane. Oggi è possibile, con qualche sacrificio iniziale, acquistare un'auto elettrica e rientrare dell'investimento iniziale in un ridotto numero di anni. Quindi trova altri motivi per non passare all'elettrico.