Rendere smart una TV dumb: H96 Mini V8 modding

 Ovvero come farsi del male spendendo poco e tribolando molto.

In casa ho diverse TV, una per ogni stanza, ma solo quella della sala (un TCL C70 da 65") è "smart". Come ben saprai, al giorno d'oggi se non sei smart non sei un boomer. Volevo quindi rendere smart anche la TV della camera. In realtà volevo solo che ci girasse Kodi per vedere i miei film e le mie serie TV.

Ho quindi installato OpenELEC su un vecchio portatile con uscita HDMI, configurato Kodi come Dio comanda ed è finita lì. Il problema è che il vecchio portatile è davvero vecchio: un Core 2 Duo da 2,3GHz che regge bene fino al FullHD (anche in x265), ma già con i 60FPS fatica.

Poi ha la ventola piuttosto rumorosa (non così tanto, ok) e comunque consuma 65W, un'esagerazione.

Ho colto quindi al volo un'offerta per accaparrarmi un TV Box con supporto 4K e Android 10, l'H96 Mini V8.

Una foto rubata su internet

Quad-core a 1,2GHz, con decodifica H265 in hardware, 2GB di RAM, 16GB di storage, WiFi, LAN, HDMI 2.0, e chi più ne ha più ne metta.

Avrei pure potuto vedere YouTube o Prime Video, anche in 4K HDR 60 fps Turbo Iniezione.

O almeno così sarebbe dovuto essere

In pratica l'interfaccia è inutilizzabile, qualunque cosa sopra il FHD (1080p) a 30fps droppava frame (sia in wifi che in LAN che da file locale), con qualunque app (Kodi, VLC, YouTube...).

CPU Prime Benchmark mi dava valori oscillanti tra 4500 e 5000: non male, in effetti. Ma in fin dei conti "tanta" potenza serviva a ben poco.

Perdona la qualità del video, era solo una prova del reato...

Ho aperto un ticket col venditore che me l'ha rimborsato (e comunque erano nemmeno 20€, eh...).

Dopo qualche mese ho pensato di metterci mano: "magari aggiornando il firmware migliora" ho pensato.

Questa è la pagina ufficiale dove scaricare i file necessari.

Oltre a questi è necessario un cavo USB-A maschio-maschio, non proprio comunissimo. Fortuna ne avevo di avanzo uno da un vecchio HD esterno.

Il video di istruzioni che forniscono è molto chiaro ed esplicativo.

Peccato sia sbagliato

Dopo innumerevoli prove sono riuscito, dovresti seguire questa procedura (è sostanzialmente simile a quella del video, ma ci sono alcune importanti differenze ed alcune cose non chiare):

1. Scarica driver, firmware ed applicazione per l'aggiornamento (FactoryTool)
2. Installa i driver
3. Avvia Factory Tool
4. Seleziona la lingua inglese (guardate il video di cui sopra)
5. Seleziona il firmware
6. Seleziona "Restore" (e non "Upgrade")
7. Clicca su "Run"
8. Prendi il box e scollegalo da tutto
9. Collega il cavo USB-A al PC
10. Con un ago (perché lo stuzzicadenti è troppo grosso) premi il piccolo pulsante dentro il foro chiamato REC (prima o poi ci spiegheranno a cosa si riferisce questo "REC")
11. Mentre tieni premuto, inserisci l'altro capo del cavo USB-A nella presa USB 2 (non la 1 come detto nel video)
12. A questo punto il box è collegato tramite USB solo al PC che quindi lo sta alimentando
13. L'aggiornamento dovrebbe partire in automatico
14. Aspetta che termini (nella colonna di destra apparirà una riga verde)
15. A quel punto puoi scollegarlo dal PC e vedere come è andata

Con il nuovo firmware la situazione è migliorata: la fluidità e stabilità dell'interfaccia è nettamente aumentata, i video anche in FHD@60fps sono fluidi. Il sistema è più reattivo (ora riesco anche ad entrare nella configurazioni di Android, pensa un po'). Purtroppo il 4K ancora nada: per un po' regge, poi comincia a droppare frame.

Purtroppo questo non mi basta

Si, perché ho notato che nei video 4K la CPU arriva facilmente a 99° C e gli scatti coincidono con il drop della frequenza (che da 1200 scende a 800 per qualche secondo), causata dal thermal throttling. 

Guardo fuori della finestra: "E' un bel giorno per un po' di modding."

Prendo gli attrezzi e lo smonto: nella parte inferiore c'è una freccia, da li con un piccolo strumento affilato (ho usato un plettro) si può far leva per sollevare delicatamente il coperchio, facendo tutto il giro della base.

Occhio alla freccia

Tre piccole viti reggono la minuscola scheda madre

Ecco il dissipatore, davvero molto essenziale, retto solo da un pad termico adesivo

E questo il dissipatore rimosso

Lo spazio è poco, sia sulla mobo che in altezza. Ma non sarà questo a fermarci, non credi?

Ho testato la scheda "naked" (senza il coperchio): la temperatura è scesa di almeno 20 gradi, non superando gli 85° C nemmeno sotto diversi test. CPU Prime Benchmark non scende mai sotto i 6000, anche dopo 6-7 test consecutivi.

Come primo step, quindi, ho pensato di moddare il piccolo case. 

La cover originale

Un piccolo progetto

Qui sotto le grinfie del laser a CO2

Ed ecco il risultato: una griglia di areazione come se fosse uscita così di fabbrica (lo so, hai ragione, l'adesivo blu è un po' annerito sui bordi del taglio, ma dal vivo sembra quasi voluto).

Foto non rubata da internet

Rimonto tutto in quattro e quattr'otto e lo vediamo come va: la temperatura è scesa di almeno 10-15°, forse di più. Infatti la CPU non scala più la frequenza, che rimane fissa a 1200Mhz. Sotto stress-test la temperatura arriva intorno agli 80°, mentre nella riproduzione video 4K arriva a 85-88°.

Purtroppo le prestazioni in questo frangente non cambiano molto: a seconda della quantità di bitrate del flusso video, si perde da 1 pacchetto al minuto a qualche decina: non va bene.

Il risultato era anche degno di nota. Peccato che l'estetica non basti a riprodurre i 4K.

Andiamoci giù pesante

Il dissipatore originale, fissato da un termalpad, è di semplice alluminio, con una base sottile e poche e spesse alette. Non il massimo della vita, considerato anche che è fanless. E' vero, ora la CPU non deve scalare in frequenza per via della temperatura, ma non ho molto altro su cui lavorare.

Recupero quindi un vecchio dissipatore in rame, pesa uno sproposito ma poco male. Ne taglio un  pezzo delle stesse misure del dissipatore originale (di cui uso anche il pad, per ora) e lo rimonto: temperature crollate di 20°!

Devo ulteriormente moddare anche il case, perché a questo punto l'altezza non è sufficiente, quindi armato di dremel e sega a disco lo adatto al nuovo dissipatore.

Il risultato è negativo: le temperature più basse non aiutano, i 4K sono sempre più un miraggio.

Pensiero laterale

Pur permanendo il dubbio che possa trattarsi di un problema hardware (AKA: come spesso accade, per lo meno nel settore HW, i cinesi mentono), provo ad indagare sul lato software: verifico che la cache di KODI sia configurata correttamente (lo è) ed anche se i dati disponibili sono più che sufficienti, i pacchetti vengono comunque persi. Abbasso la velocità di scaricamento del buffer, per evitare troppo overhead sulla CPU, ma cambia poco.

Smanetto anche con il "skiploopfilter", ma non sembra avere effetti.

Provo con altri player, ovvero l'immancabile VLC: 

Alla fine non mi resta che giocarmi l'ultima carta.

OVERCLOCK!

Quasi ogni cosa passata sotto le mie mani è stata in un qualche modo overclockata. Davvero. A partire dal mio primo 486 DX 2 (passato da 66 a 80MHz!) fino agli ultimi due NUC che sono diventati il mio PC principale.

Ma non ho mai occato Android: in teoria dovrebbe essere fattibile senza grosse difficoltà via software; il problema più grosso è "rootare" il box, che essendo sostanzialmente un no-brand rende le cose un filo più difficili (soprattutto per me che ho esperienza Android piuttosto limitata). Non credo di poter risolvere in questo modo il problema, ma le migliorate prestazioni termiche (che possono essere ulteriormente migliorate sostituendo il pad con la pasta e, in ultima istanza, aggiungendo una piccola ventola) lasciano ancora qualche piccolo spiraglio. 

Elettrico si, elettrico no.... e quei famosi conti?

Domenica abbiamo celebrato i 3 anni assieme a EvE, la nostra Nissan Leaf del 2016 con batteria da 30 kWh.

Prima di acquistarla, usata nel 2018, feci alcuni calcoli, oggi ho molti dati sui quali ragionare per capire se avevo ragione o meno. Andiamo a vederli.

Nel corso degli anni ho accuratamente tenuto traccia dei consumi e dell'assorbimento, dapprima in modo relativamente spannometrico (assorbimento orario per durata di ricarica) poi in modo sempre più preciso con misuratori sulla linea utilizzata per la ricarica. Ho ovviamente segnato anche tutte le (rare) ricariche alla rete pubblica, comprese quelle gratuite. Naturalmente ho anche raccolto tutte le varie spese avute in questi anni per bollo (zero...), assicurazione, tagliandi, guasti (zero...) ecc..

Eccoli.

Ho percorso esattamente 44.739 km con la Leaf, poco meno di 15.000 l'anno, consumando un totale di 6,838 MWh (fa specie scrivere MEGAWATTORA), per un consumo medio di 6,52 km/kWh. Non so dire con precisione quanti di questi km siano stati effettuati in autostrada, ma in base al tipo di ricariche (uso le Fast solo quando viaggio) posso ipotizzare che equivalgano a circa 3.000 km, ovvero il 7% del totale.

Il costo medio (comprese ricariche casalinghe, fast, accelerate e gratuite) è di 0,155 €/kWh, il che ha comportato una spesa complessiva per l'energia a 1062,30€, ovvero 0,024 €/km.

L'assicurazione, grazie a Coop Insieme e ITAS Mutua, mi è costata COMPLESSIVAMENTE 686€, mentre l'unica revisione fin qui effettuata è costata 64,70 €. 

I tagliandi annuali, senza alcun intervento particolare se non i normali controlli, sono costati 320€. Due i richiami effettuati, entrambi gratuiti: il primo per un aggiornamento software (che ho dovuto penare parecchio per far applicare), l'altro per una staffa (se non ricordo male) che era comunque preventivo (l'auto era ok).

All'acquisto l'SoH (lo "stato di salute" della batteria, ovvero la capacità di carica rispetto al teorico valore da nuova), ovvero dopo un anno e mezzo di vita dell'auto, era pari al 98% circa (quello indicato da LeafSpy era 95, ma era inficiato dal problema software summenzionato. Quello "reale" era infatti più alto), mentre dopo 3 anni (ovvero 5 anni e mezzo di vita) è oggi pari al'83%, con un degrado del 15%, ovvero il 5% annuo.

Di seguito un grafico sull'andamento dell'SoH nel tempo, la media calcolata (piuttosto lineare):

Se l'andamento dovesse rimanere simile all'attuale, dovrei scendere sotto il 66% di SOC tra circa 3 anni e mezzo, circa 1 mese prima della scadenza della garanzia... direi che Nissan ha fatto bene i suoi conti.  :-D 

Ma come ho ricaricato? Bene, quasi sempre da casa e di conseguenza quasi sempre a 2.3 kW (con l'IC-CPD standard): su un totale di 567 ricariche, ben 497 sono effettuate in questo modo (88%), 24 quelle a colonnine AC (4%) e 30 Fast in DC (5%). Ci sono poi circa 15 ricariche alla wallbox che possiedo (3 kW), ma sono state solo brevi prove (è scomoda da usare perché prevede di passare la card... lasciamo perdere).

Da notare che ho effettuato solo 118 ricariche complete: solitamente interrompo la ricarica all'80% (prima tramite calcoli approssimativi usando la programmazione oraria, poi con un sistema più avanzato di domotica che controlla la spina dell'IC-CPD). Come detto gran parte della percorrenza è cittadina (di sicuro superiore al 90% del totale di chilometri percorsi).

Vediamo ora di paragonare previsioni e dati reali.

Sul consumo ero stato leggermente pessimista, ipotizzando 7 km/kWh, mentre quello reale è stato di 6,52. Considerati i km percorsi (ben superiori a quelli stimati), il risparmio è stato di 495€ l'anno (contro i 340 stimati).

Riguardo l'assicurazione le cose sono andate meno bene, in quanto stimavo 180€ annuali, mentre sono stati circa 228 in media. Posso quindi ipotizzare un risparmio di "soli" 307€ contro i 355€ previsti.

Ancora non ho pagato il bollo, essendo l'auto a zero emissioni, ma prevedo di doverlo pagare la prima volta quest'anno (o il prossimo, non ho ancora capito). Fatto sta che il risparmio è stato ovviamente come quello preventivato: 227€ annui.

Anche i tagliandi sono stati un po' più costosi del previsto: poco più di 100€ contro i 70 previsti. Il che ha comportato una riduzione del risparmio dai 180€ ipotizzati ai 144€ reali.

Non ho avuto guasti o interventi di altro tipo, ma come detto nel post iniziale, non sarebbe mai stato possibile preventivarli (per ovvie ragioni). Devo quindi tener fede ai costi di manutenzione ipotizzati per una eventuale ICE, circa 48€ l'anno.

Riassumendo, in media ho risparmiato circa 1220€ all'anno, contro i 1100 che pensavo prima ancora di acquistare l'auto: in sostanza i calcoli erano sostanzialmente giusti. Questo significa che pur acquistando un'auto usata senza incentivi tra circa 2 anni comincerò a risparmiare rispetto al caso in cui avessi acquistato un'auto a GPL di pari categoria. 

Bando ai freddi numeri, passiamo alle considerazioni personali: guidare una EV continua ad essere comodo ed appagante. La diminuita autonomia si palesa solo in autostrada, ma la vistosa crescita delle fast rende possibile andare praticamente ovunque aggiungendo solo una sosta o due al percorso rispetto ai primi tempi: per me non è un problema perché i lunghi viaggi sono solo "di piacere" e trovo divertente programmare le varie soste e calcolare i tragitti. Certo, con 40-50-60 kWh delle auto odierne il problema non si porrebbe nemmeno, ma tant'è.

Nei miei piuttosto limitati viaggi ho riscontrato problemi con le colonnine solo 2 volte, ma non sono mai rimasto a piedi: ho solo dovuto ripiegare sul piano B, ma senza troppi patemi (in sostanza ho solo dovuto attendere un po' ad una colonnina AC).

Non ho mai riscontrato problemi di funzionamento o manutenzione, se non la divertente scenetta di quando alla revisione cercavano di capire come misurare i fumi di scarico. :-D

Certo, il degrado della batteria è un po' superiore a quanto pensavo di poter ottenere, ed è in effetti piuttosto alto nonostante l'estrema attenzione con cui ho effettuato le ricariche (quasi sempre nel range 40-80% ad eccezione dei lunghi viaggi dove di solito mi spingo al 10-100%, ma come detto sono piuttosto rari). La famiglia è sempre entusiasta dell'auto, come spazi e comodità, e non ho ricevuto mai grosse lamentele per la durata dei viaggi: doversi fermare ogni 130-150km rende il viaggio meno monotono.

A parte il degrado l'unico appunto che posso fare a Nissan è l'aver voluto eliminare la localizzazione GPS dell'auto, che mi dava qualche sicurezza in più. Ma nulla di trascendentale. Un po' più noioso è invece il funzionamento dell'app, spesso instabile e comunque sempre lenta: me ne rendo conto da quando uso il sistema di domotica che si appoggia all'infrastruttura Nissan per ottenere i dati di carica dall'auto. diciamo che il 90% delle volte va, seppure piano. Sotto questo punto di vista Nissan non ha mai voluto investire granché (o forse investe le risorse solo per i nuovi modelli, chissà...).

In ogni caso, avviare la climatizzazione dell'auto da remoto, o addirittura farlo in automatico quando esco da lavoro o poco prima di partire la mattina (sempre grazie alla domotica), è impagabile. Posso anche avviare o stoppare la ricarica ad una data ora o ad una data percentuale di carica, avviare l'A/C anche ad auto scollegata per più dei 15 minuti concessi da Nissan, e tante altre cose (ma qui sto andando OT).

Tornando all'auto, sono poche le modifiche apportate, nonostante le molte idee iniziali: ho colorato di nero (con vernice rimovibile) la calandra anteriore, che gli ha donato un look molto più aggressivo, e spostato leggermente la targa. 

Ho poi installato un dongle bluetooth sulla presa OBD, per far comunicare l'auto con LeafSpy e Power Cruise Control. Ho installato una dashcam (di qualità infima), un caricatore USB da 4 porte e due classici portacellulari. Alla dotazione standard per la ricarica (IC-CPD con spina Shuko e cavo Tipo 1->Tipo 2) ho aggiunto adattatori vari per prese tripolari, industriali a 16A blu e rosse, una Tipo 2->Tipo 1 (per colonnine con cavo Tipo 2 integrato) e un Tipo 3A->Shuko (che probabilmente non funziona...). In realtà tutti questi adattatori non li ho mai usati, ma visto l'esiguo investimento valeva la pena tenerli in auto. Le gomme sono ancora quelle originali, ormai un po' alla frutta: mai montate le invernali, qui da me difficilmente si va sotto gli zero gradi e la neve la vedo solo col binocolo (davvero, mi basta affacciarmi dalla finestra e guardare i monti :-) ): unica noia è mettere le inutili catene nel bagagliaio nei periodi indicati dalle norme...

Come detto uso spesso LeafSpy (quasi quotidianamente) anche se è strettamente necessario (sono molto nerd). Nei lunghi viaggi devo ringraziare PCC, perché ha aperto la strada ma, complice l'assenza della versione per iOS, sono migrato all'uso di ABRP (A Better Route Planner), vista anche l'ottima integrazione con la versione web: durante la guida è di sicuro meno immediato nell'utilizzo, ma è estremamente più comodo avere un cellulare e non dover smanettare tra navigatore che scatta, hotspot che perde la connessione, bluetooth che va in blocco e così via. L'infotainment dell'auto è fortemente limitato, ma mi basta avere il bluetooth per riprodurre l'audio del telefono e sono a posto. 

Infine un calcolo che lascia il tempo che trova: utilizzando solo 

Ho voluto inziare questa avventura perché sono un "early-adopter", anche se non tanto "early" quanto tanti altri, ma non posso che essere soddisfatto della scelta.

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.

Xiaomi IMILAB Mijia CMSXJ16A e Samba non vanno d'accordo

 Ho preso alcune camere wifi come queste:

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.

Ravano nei log e trovo:

[2020/10/23 12:26:03.706346,  3] ../../source3/smbd/negprot.c:757(reply_negprot)

  reply_negprot: No protocol supported !

[2020/10/23 12:26:03.706480,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)

  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

[2020/10/23 12:26:03.706529,  5] ../../libcli/security/security_token.c:53(security_token_debug)

  Security token: (NULL)

[2020/10/23 12:26:03.706576,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)

  UNIX token of user 0

  Primary group is 0 and contains 0 supplementary groups

[2020/10/23 12:26:03.706648,  5] ../../source3/smbd/uid.c:503(smbd_change_to_root_user)

  change_to_root_user: now uid=(0,0) gid=(0,0)

[2020/10/23 12:26:03.706697,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)

  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

[2020/10/23 12:26:03.706736,  5] ../../libcli/security/security_token.c:53(security_token_debug)

  Security token: (NULL)

[2020/10/23 12:26:03.706778,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)

  UNIX token of user 0

  Primary group is 0 and contains 0 supplementary groups

[2020/10/23 12:26:03.706839,  5] ../../source3/smbd/uid.c:503(smbd_change_to_root_user)

  change_to_root_user: now uid=(0,0) gid=(0,0)

[2020/10/23 12:26:03.706887,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)

  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

[2020/10/23 12:26:03.706926,  5] ../../libcli/security/security_token.c:53(security_token_debug)

  Security token: (NULL)

[2020/10/23 12:26:03.706968,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)

  UNIX token of user 0

  Primary group is 0 and contains 0 supplementary groups

[2020/10/23 12:26:03.707038,  5] ../../source3/smbd/uid.c:503(smbd_change_to_root_user)

  change_to_root_user: now uid=(0,0) gid=(0,0)

[2020/10/23 12:26:03.707105,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)

  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

[2020/10/23 12:26:03.707152,  5] ../../libcli/security/security_token.c:53(security_token_debug)

  Security token: (NULL)

[2020/10/23 12:26:03.707197,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)

  UNIX token of user 0

  Primary group is 0 and contains 0 supplementary groups

[2020/10/23 12:26:03.707265,  5] ../../source3/smbd/uid.c:503(smbd_change_to_root_user)

  change_to_root_user: now uid=(0,0) gid=(0,0)

[2020/10/23 12:26:03.707322,  4] ../../source3/smbd/sec_ctx.c:319(set_sec_ctx_internal)

  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0

[2020/10/23 12:26:03.707367,  5] ../../libcli/security/security_token.c:53(security_token_debug)

  Security token: (NULL)

[2020/10/23 12:26:03.707412,  5] ../../source3/auth/token_util.c:873(debug_unix_user_token)

  UNIX token of user 0

  Primary group is 0 and contains 0 supplementary groups

[2020/10/23 12:26:03.707479,  5] ../../source3/smbd/uid.c:503(smbd_change_to_root_user)

  change_to_root_user: now uid=(0,0) gid=(0,0)

[2020/10/23 12:26:03.707877,  3] ../../source3/smbd/server_exit.c:243(exit_server_common)

  Server exit (no protocol supported

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

   force user = cam

Infine ricarico la configurazione di Samba:

sudo smbcontrol all reload-config

Fatto.