L’angolo del cialtrone

Domenica mattina, piove. Dalla sala da pranzo si leva, disperato, l’urlo dei familiari in preda al dolore: “non funziona internet”. Tralasciamo la semantica della frase.
Attendo qualche minuto, sperando in un down temporaneo del gestore e poi decido di andare in soffitta a riavviare il router esterno, una operazione davvero semplice, basta scollegare il POE.

Una volta in soffitta noto con stupore che entra acqua dal lucernaio, pertanto sarà necessario intervenire appena il tetto sarà asciutto per rimettere il silicone. Mi avvicino al POE e noto, con disperazione, che esce acqua dal cavo di rete. Non mi era MAI capitato prima. L’allagamento del cavo ha messo in corto il POE che è (fortunatamente) andato in protezione.

Ok, e adesso? Piano A, aspettare lunedì e la fine del monsone per andare sul tetto e capire cosa cavolo sia successo. Piano B, andare subito sul tetto per sistemare l’accesso alla rete internet e ripristinare la pace famigliare. Vada per il piano B. In cantina trovo una matassa di cavo UTP cat 5e da esterno e vado sul tetto con la giacca cerata da montagna, sotto la pioggia. Cambio al volo il cavo, perdo almeno 30 minuti per farlo rientrare in casa dal foro sulla parete (non sono riuscito a fare uno sfila-infila). Riconnetto e tutto riparte.

Cosa è successo? Il cavo che ho installato 6 anni fa, era da interno e non protetto da guaina. La solita cosa “metto un cavo volante poi con calma faccio le cose per bene”. Ecco, ancora sto aspettando di farle “per bene”. Con il sole la guaina del cavo si è irrigidita e spaccata, facendo entrare copiosa acqua piovana. Questa seguendo il principio dei vasi comunicanti e grazie alla capillarità dei cavetti AWG24 è riuscita a trovare una facile strada per entrare in casa ed allagare il POE che è appeso ad una parete.

Una cialtronata. Finita bene

Lo stereo

Del mio “impianto stereo” ho già parlato in un vecchio articolo, in cui ho descritto quello che, per tanti anni, mi ha fatto compagnia musicalmente.
Finalmente, mi sono deciso a ricomperare un nuovo lettore CD. Ho impiegato almeno tre mesi per decidere cosa prendere, quanto spendere e dove acquistare.

Primo dilemma: nuovo o vintage? Sicuramente un impianto vintage è interessante, un bel cd anni 80/90 basato sul convertitore TDA1541, del quale si parla su una marea di siti diversi ( Dutchadioclassic, lampizator, Oldstore, AudioScience, DiyAudio). In prima battuta mi ero quindi convinto ad acquistare un CD880 della Philips, trovato a circa 400 euro su un mercatino. Poi mi sono messo a leggere e, tale acquisto, avrebbe richiesto non pochi hack: ricappare tutto, cambiare i caps del DA, modificare l’oversampling, modificare l’alimentatore etc. In pratica soldi extra per avere un prodotto molto vecchio e un po’ smaneggiato. Senza contare che il tempo di mettere a posto non lo ho.

Lettore nuovo. Attualmente, acquistare un CD player dignitoso è un dilemma. Ci sono i mostri sacri, ma devono essere inseriti in impianti degni di questo nome, e costano un occhio della testa. Spesso si tratta di meccaniche con DA separato, complessi anche da posizionare. Io non voglio spendere tanti soldi, visto che andrò ad inserire il lettore in un contesto molto “economico”. Tuttavia non voglio una schifezza completa, ho ancora un po’ di dignità delle orecchie. Pertanto ho fatto una serie infinita di ricerche, partendo dal Tascam 200BT (che avrebbe anche la connessione Bluetooth, ma del quale non ho letto recensioni molto buone). Ci sono poi i Marantz (soprattutto il 6007) ed altri produttori che sono interessanti, tutti nella fascia dei 500 – 800 euro. Alla fine mi sono deciso: Marantz CD6007 che ha parecchio mercato dell’usato, visto che si è venduto bene. Mi sono messo alla caccia di questo lettore e, con molta fortuna, lo ho trovato in vendita su “mercatinomusicale” ad un prezzo molto conveniente. Il precedente proprietario lo cambia per avere un componente che suoni più dolce. Detto fatto. Preso. L’acquisto del CD ha triggerato il recap e la pulizia del fido Harman Kardon HK6200, che accusava molti problemi ai potenziometri ed aveva bisogno di due nuovo condensatori di livellamento. Mi sono messo in testa di farlo in poco tempo e quindi ne ho completato la revisione in due giorni. Adesso funziona che è un amore!

Sono quindi tornato a casa con lettore CD ed amplificatore, da reinserire nella mia catena di ascolto con le fidate B&W685 (prima serie) finalmente tappate nel bass-reflex.
sono molto soddisfatto e, visto che ormai tutti sono focalizzati sul vinile, voglio fare incetta di CD su ebay, tutto di seconda mano (sperando di non prendere proprio delle schifezze), in modo da risparmiare molti soldi.

Samsung ES8000 – Data REcovery

Nel 2011 ho acquistato un televisore Samsung 46 pollici, modello ES8000 (ne ho già parlato, per un problema, in questo articolo). Per potere giocare con le diverse app installate, ho montato su di esso una chiavetta USB. Nel corso degli anni abbiamo registrato su di essa diverse foto e video, fatti con la camera integrata. Ad un certo punto, il buio. Chiavetta non riconosciuta. Provo ad accedere ai dati, nulla. Non viene vista da Linux nè da Windows. Ok, mi incaponisco. Questo il risultato.

Inserendo la chiavetta in un calcolatore linux, si ottengono pochissime informazioni.
sd 4:0:0:0: [sdd] 2041856 512-byte logical blocks: (1.05 GB/997 MiB)
sd 4:0:0:0: [sdd] Write Protect is off
sd 4:0:0:0: [sdd] Mode Sense: 23 00 00 00
sd 4:0:0:0: [sdd] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 4:0:0:0: [sdd] Attached SCSI removable disk

Che sono comunque utili a determinare il funzionamento del dispositivo. In rete ho trovato la documentazione di un progetto “SamyGO“, che parla del filesystem di queste chiavette. Si tratta di un RFS, Robust File System, pensato proprio per le pendrive e supportato da Samsung “da sempre”. Rimane da capire come accedere ai dati, cosa che viene spiegata in questo articolo: in pratica si tratta di un filesystem FAT16 o FAT32, che può essere montato nativamente e con poco sforzo in linux. Il problema è, semmai, recuperare i dati della partizione.

Come già successo in passato, mi è venuto in aiuto il programma testdisk (lo avevo usato per recuperare i dati di “esse”) , in ambiente linux. Ho caricato il drive corrispondente alla mia chiavetta (/dev/sdd) ed ho provato a fare riconoscere la partizione: NULLA. Allora ho deciso di lavorare “senza partizioni” indicando un filesystem di tipo FAT16 ed eseguendo una “immagine della partizione”. Ho fatto lo stesso con il filesystem FAT32.
Una volta create le “immagini” mi sono messo a lavorare con queste.
testdisk image16.dd
selezionare “proceed” e quinti “non partitioned media”
associare un tipo fat16 ai dati

eseguire un “rebuild del boot sector”

Con l’opzione “list” è possibile vedere tutti i files che sono recuperabili (in grigio) e quelli persi per sempre (in rosso).

Con una sintassi molto fantasiosa (utilizzo di : e C) è possibile copiare i dati in una altra posizione e, finalmente, goderseli.
Una ultima nota: Samsung salva le immagini in formato ljpg, che è un jpg a tutti gli effetti. I video hanno estensione .vu, ma VLC li “digerisce” senza problemi in quanto sono MPEG.

Finalmente posso regalare a questa chiavetta, il riposo eterno che merita!

Famo a capisse

Negli ultimi giorni, sul tetto della “torre” della Facoltà di Ingegneria è comparso un “antennone”, molto appariscente. Prima che siano divulgate fake-news, fake-info o banalmente delle cavolate, leggete quello che ho da dirvi.

Perchè vi dovreste fidare? Beh, ho avuto il piacere, l’onore ed a volte l’onere di seguire il progetto dai sui esordi, la installazione delle apparecchiature. Capisco “qualche cosa” di telecomunicazioni, sono uno smanettone e su questo blog faccio divulgazione di quello che mi piace. Non ho alcun motivo di raccontare baggianate e, avendo pubblicato il mio indirizzo email, sono sempre pronto al confronto. Questo post non vuole essere troppo tecnico, vorrei che lo capisse anche chi non è addetto ai lavori. Pertanto non rompetemi se non sono rigoroso, cattedratico, accademico o melodrammatico. Soprattutto, non rompetemi se credete che io stia mentendo. Problema vostro.

Iniziamo da lontano: la maggiore parte dei servizi che ci accompagnano durante il giorno e nella nostra vita, sono erogati “via radio”. Basti pensare alla radio FM che ci fa compagnia in auto, alla television, il WiFi, lo smartphone o, semplicemente, il termometro che abbiamo appeso fuori dalla finestra e ci fa leggere la temperatura dall’interno di casa. Tutti questi servizi, per funzionare, non devono essere sovrapposti, altrimenti non potremmo fruirne. Ad ogni servizio deve essere assegnata una precisa frequenza sulla quale essere raggiunto: funziona come sulla radio della macchina, ad ogni emittente è dedicata una frequenza in modo che le trasmissioni non si sovrappongano, rendendole non intellegibili. Quanto detto mostra quanto sia necessario un coordinamento nell’uso delle frequenze e nella distribuzione dei servizi, non solo a livello nazionale ma a livello internazionale e globale. In questo modo evitiamo che in nazioni adiacenti, la stessa “risorsa” di frequenza venga assegnata a servizi molto diversi tra loro creando delle interferenze. Oppure facciamo in modo che una radio acquistata in Italia possa funzionare almeno in Francia o Germania. A livello internazionale il coordinamento nell’uso delle frequenze radio spetta alla ITU ente che ha il suo bel lavoro nell’emanare documenti e monitorare il corretto uso delle risorse. A livello nazionale ci pensa il  C.N.C.E.R. ente dal nome impronunciabile che suona come: Centro Nazionale Controllo Emissioni Radioelettriche. Nota bene, questo ente lavora in seno al MISE (Ministero Sviluppo Economico) e non ha nulla a che fare con Polizia Postale, Servizi Segreti o altro.

Il punto è questo: il CNCER deve fare in modo che le frequenze vengano utilizzate secondo quanto stabilito dal Piano Nazionale Ripartizione Frequenze, che è stato recentemente aggiornato. Se tali regole non vengono rispettate si possono avere interferenze su altri servizi. Alcuni servizi sono critici (Navigazione Aerea, Emergenza, Navigazione Nautica etc) e non devono essere interferiti. Pertanto è necessario avere delle buone “orecchie” in grado di potere verificare se le emissioni sono tutte a norma e occupano le frequenze loro assegnate. Per questo sono attive, su territorio nazionale, una serie (non ho idea di quante siano) di centri di ascolto che consentono di verificare il rispetto delle norme suddette e garantire la sicurezza dei cittadini. Sulla torre della Facoltà di Ingegneria è stato installato uno di questi centri di radio monitoraggio (che non è intercettazione, bada bene). Le antenne che si vedono sono collegate ad un RICEVITORE (da sogno, per un appassionato come me) che è in grado di sintonizzare tante frequenze con estrema precisione e di capire se una stazione è troppo potente o sta creando interferenze o disturbi.

Tutto qui, solo una bella radio che ascolta segnali per tutelare la sicurezza di tutti.

La torre con le antenne sul tetto.

Samsung EU46 serie 8000

Ieri sera (30 settembre) c’è stato un violento temporale nei dintorni di Polverigi. Improvvisamente c’è stato un fulmine che ha illuminato a giorno tutta la zona. C’è stata una micro interruzione di energia elettrica, che ha spento il televisore e molti altri dispositivi elettrici di casa.
Successivamente a questo episodio, il televisore ha iniziato a comportarsi in modo bizzarro. Si è resettato spesso, faceva spesso delle righe colorate o uno schermo verde.
Immediatamente ho pensato: il fulmine ha fatto saltare qualche componente dell’alimentatore e adesso la CPU va in protezione per via di qualche caduta di tensione.
Preso dalla rabbia e dalla disperazione dei miei famigliari, ho smontato il televisore sul mobile della sala, controllato bene la scheda di alimentazione e … nulla. Tutti gli elettrolitici sono normali, non ci sono segni di scarica o bruciatura. Un po’ disperato ho iniziato a guardare su internet alla ricerca di una soluzione ed ho trovato questo video , in cui un ragazzo spiega perfettamente quello che accade.
Il problema è sistemare il guasto a casa: ho solo un saldatore a gas, con uno stagno a base (penso) di maionese e non ho cavi adeguati. Con un po’ di fantasia, e qualche imprecazione, sono riuscito a fare un ponticello per ripristinare le funzionalità e adesso sembra che tutto funzioni regolarmente.

Connettore lato motherboard
Connettore lato PSU

Esp8266 – Low Power (parte 2)

Come promesso nel precedente articolo, ho fatto qualche (decina) di prove per cercare di ottimizzare il funzionamento del sistema ed essere sempre più parco nelle richieste energetiche.
Lo sketch di partenza è quello che ha funzionato nei precedenti tests, molto “quick and dirty” con notevoli margini di ottimizzazione.
I parametri principali rilevati sono stati:
– Corrente media: 53,3 mA
– Corrente massima: 272,1 mA
– Energia 177 uA/h

Sketch versione 1

Il primo passo di ottimizzazione ha previsto una ridefinizione del delay imposto prima della attivazione del sensore DHT. Ho fatto diverse prove ed ho trovato che 1,7s consente una ottima ripetibilità delle misure. Inoltre ho epurato alcune funzioni che erano “eccessive”. Il risultato è stato molto incoraggiante:
I parametri principali rilevati sono stati:
– Corrente media: 39,6 mA
– Corrente massima: 242,1 mA
– Energia 132 uA/h
Non male!

Sketch versione 2

Per l’ultimo test ho rimosso anche tutti i “serialprint” che avevo inserito per monitorare il funzionamento del sistema. Vero che non sono molto “costosi” in termini energetici, ma richiedono tempo per essere eseguiti. Ed il tempo è energia, soprattutto se sono usati durante il periodo di connessione di ESP.
I parametri principali rilevati sono stati:
– Corrente media: 39,5 mA
– Corrente massima: 248,4 mA
– Energia 131,8 uA/h
Visti i risultati li avrei potuti anche lasciare!

Sketch versione 3 – Minimale

Rimangono da risolvere due interrogativi:
– cosa succede inserendo il codice per la gestione di MQTT;
– quanto incide la presenza di una sensore di luminosità.

L’introduzione del codice relativo ad MQTT non ha effetti apprezzabili sul funzionamento del sistema. In fondo si tratta di un paio di funzioni che non hanno altro effetto se non quello di trasmettere qualche frame aggiuntivo alla fine dello sketch. Se la comunicazione si mantiene a rate elevato, l’impatto “energetico” è davvero modesto.

Aggiunta del codice MQTT

Con queste figure, faccio un rapido conto (nella speranza che sia giusto, altrimenti, accetto critiche e correzioni che siano sensate): 0.130 uA/h sono l’energia di un singolo processo di acquisizione e notifica. Ne vorrei eseguire 6 in un’ora, con un assorbimento di 7.8mA/h. Se ipotizzo una batteria da 1500mA, vengono fuori circa 8 giorni di funzionamento (sono ben 11520 cicli di acquisizione). Non ci siamo.

NB: ho chiesto di commentare ma i commenti sono disabilitati. Non sono impazzito, basta mandarmi una mail o un WA. Non ne posso più di pubblicità di farmaci e di cancellare spam dal mio blog.

Esp8266 – LowPower

Da qualche tempo mi sono fissato per rispondere ad una sfida: realizzare un sensore di umidità, temperatura che sia alimentato a batteria, Wifi e che mi garantisca una grande durata dell’accumulatore.
Lavorare in “low-power” è interessante in quanto impone di rinunciare a “tutto il possibile”, per potere contenere il consumo di energia del sistema. Inoltre impone di lavorare con dispositivi che supportino una modalità di “deep-sleep” e che non richiedano il bacio di un principe per essere risvegliati.
Visto che tutti i miei progetti sono basati su ESP8266 e che ne ho ancora “diversi” nel cassetto, ho voluto provare con questo micro. Le informazioni di partenza per questa avventura le ho prese da questo sito, davvero chiaro.

Il prototipo lo ho costruito attorno al sistema di sviluppo basato su “breadboard” che avevo realizzato (troppi) ani fa. Qualche falso contatto da ripristinare, qualche integrato da rimuovere ma alla fine ha funzionato tutto. Ho iniziato con qualche sketch base, per riprendere mano e per fare dei test con i singoli componenti poi mi sono concentrato su alcuni aspetti specifici:
– quanto influisce il metodo di assegnazione dell’IP sul consumo?
– quanto influisce la presenza di un sensore di temperatura sul consumo?

Assegnazione degli IP e consumo.
Il processo di assegnazione di un IP ad un dispositivo IoT può avvenire in due modi: statico o tramite DHCP. Nel primo caso è necessario interagire e configurare ogni dispositivo a mano, possibilmente tenendo traccia degli indirizzi usati.
Nel secondo caso ci pensa un protocollo a configurare l’indirizzo IP, sfruttando un paradigma client server e lo scambio di 4 messaggi.
Per fare questa valutazione mi sono avvalso di un “DC Power Analyzer”, Keysight N6705B, equipaggiato con un cassetto N6762A (opzione 2uA) e N6752A. In pratica è un alimentatore da banco regolabile, estremamente preciso e controllabile da remoto, con funzioni integrate di oscilloscopio e data logger. Un bel giocattolo.
Ho compilato due sketch, uno con assegnazione statica ed uno con assegnazione dinamica dell’IP ed ho effettuato un test della durata di pochi minuti, a parità di condizioni di connessione e parametri di alimentazione.

Test con assegnazione STATICA
Lo sketch prevede la connessione all’AP, una operazione di controllo della validità della connessione, la lettura dell’ADC ed il deep sleep per 10 secondi.
Test eseguito su 5 minuti e 30 secondi, avviando il data logger e partendo dalla condizione di “sensore spento”. Il funzionamento del dispositivo è monitorato attraverso la porta seriale (file datalogdata22.edlg).

Esp8266 – No DHCP Verticale: 50mA div

La figura mostra un blocco di esecuzione del codice. Connessione, lettura del valore e spegnimento in deep-sleep del dipositivo. La maggiore parte del consumo è imputabile alla trasmissione WiFi che, anche se in modo impulsivo, richiede parecchia corrente. Le operazioni di connessione sono evidenziate dalla figura seguente, uno zoom della immagine precedente.

ESP8266 – No DHCP

Lasciando al programma della Keysight la “briga” di analizzare 5 minuti di segnale acquisito, si ottengono i seguenti parametri:
– corrente media 26,5 mA
– corrente massima 271 mA
– Energia: 2,2 mA/h
Un singolo “blocco” di esecuzione (6 secondi) richiede 98,131 uA/h per l’esecuzione.

Test con assegnazione tramite DHCP.
In questa serie di test è stato compilato uno sketch che ha le medesime funzioni del precedente ma che non prevede assegnazione statica degli indirizzi IP. Il sistema è stato analizzato in modo analogo al caso precedente (file datalogdata24.edlg). La forma d’onda del singolo trasferimento è del tutto analoga a quella vista nel caso di assegnazione manuale dell’indirizzo IP.

ESP8266 – DHCP

Lo stesso si può dire per lo zoom delle fasi iniziali della connessione, come mostrato nella figura successiva.

ESP8266 – Connessione

Analizzando il solito “blocco” di 5 minuti si ottengono i seguenti valori:
– corrente media 7,2 mA (dipende da quanti run sono stati catturati)
– corrente massima 286 mA
– Energia: 598 uA/h
Un singolo “blocco” di esecuzione (6 secondi) richiede 98,602 uA/h per l’esecuzione.

Il DHCP non ha effetto? Beh, il suo effetto non è evidente. Lo scambio di messaggi previsto dal protocollo DHCP è molto rapido, in quanto l’AP che sto usando è “scarico” (solo 5 client connessi), è molto vicino e consente al dispositivo di connettersi con un rate elevato, cosa che minimizza l’impatto dello scambio di frames dedicati al DHCP. Inoltre il traffico del DHCP è caratterizzato dal trasferimento di pochi dati, visto che è un protocollo “lightweight”, pertanto il suo effetto è pressoché trascurabile. Questo risultato è un vero sollievo in quanto nelle applicazioni IoT, potere contare sul DHCP è una vera “manna dal cielo”.

Il sensore DHT22
Uno dei sensori più usati in ambito hobbistico. Semplice da collegare, non presenta tutte le idiosincrasie di altri che usano I2C ed è solo moderatamente “energivoro”. Ha un tempo minimo di campionamento di 2 secondi e assorbe massimo 2mA in fase di misura.
Per poterne apprezzare l’impatto sul mio sistema, ho sviluppato un nuovo sketch che preveda l’uso di DHCP e che esegua le seguenti funzioni:
– controllo di connessione WiFi;
– accensione del DHT22 tramite pin del micro ESP8266;
– lettura del valore di ADC;
– lettura dei valori di temperatura ed umidità;
– spegnimento in deepsleep (10 secondi);
(file datalogdata25.edlg ).

ESP8266 con sensore DHT22.

Analizzando il solito “blocco” di 5 minuti si ottengono i seguenti valori:
– corrente media 34,1 mA (dipende da quanti run sono stati catturati)
– corrente massima 295 mA
– Energia: 2,8 mA/h
Un singolo “blocco” di esecuzione (6 secondi) richiede 98,602 uA/h per l’esecuzione.

Sketch “verosimile”
Acquisire dei dati di temperatura ed umidità con tale frequenza è davvero eccessivo. Ho aumentato la durata del deep-sleep a 60 secondi, in modo da campionare ogni minuto.

ESP8266 – Campionamento ogni minuto

Analizziamo l’intera “ora” di acquisizione (file datalogdata27.edlg): quanto costa in termini energetici?
– corrente media 9,8 mA (dipende da quanti run sono stati catturati)
– corrente massima 295 mA
– Energia: 9,8 mA/h
Con una batteria da 1500mA/h, possiamo fare circa 6 giorni, al netto della autoscarica.
Pochissimo! Occorre ottimizzare:
– ridurre il tempo di esecuzione dello sketch, “limando” al minimo i delay per l’attivazione del sensore DHT;
– ridurre la potenza di trasmissione del modulo WiFi, tanto siamo in ambiente domestico;
Non ritengo molto conveniente cambiare il sensore che “pesa” 1.5mA, a fronte del costo della trasmissione del messaggio. Nella seconda parte del post, ulteriori misure dopo avere fatto qualche esperimento di temporizzazione

Esp8266 – Un progettino easy.

Ho realizzato diversi sensori di temperatura basati su ESP8266 e DHT22, ormai ho il codice pronto, diversi alimentatori a 5V o 3.3V e posso fare un deploy molto veloce.

Partendo da un sensore che avevo “pronto” e funzionante in ufficio, ho voluto fare alcuni miglioramenti per fare un po’ di esperienza ed imparare qualche cosa. L’obbiettivo che mi sono prefissato è il seguente:
– aggiungere un display 16 x 2 collegato con I2C al micro, per visualizzare umidità e temperatura;
– implementare un client MQTT per visualizzare i dati di consumo elettrico sul display.

I classici display 16×2 sono controllabili attraverso un protocollo che prevede collegamento in parallelo di diverse linee dati. Si trovano alcune interessanti informazioni in questo link. Questo approccio era molto carino ai tempi dei PIC, dove le linee di I/O erano molte. I dispositivi ESP non hanno, a parte rare implementazioni che integrano dei moltiplicatori di I/O, tutte queste linee. Meglio ricorrere ad un convertitore I2C. Sono dispositivi a bassissimo costo che si possono facilmente reperire su Aliexpress o ebay ad un prezzo ridicolo ( da 1 a 2 euro).

Sono basati su PCF8574T, prodotto dalla NXP e catalogato come “Remote 8-bit I/O expander for I2C‑bus with interrupt”: volendone banalizzare il funzionamento, è possibile controllare e leggere lo stato della porte I/O attraverso opportuni comandi sul bus I2C.

Per farlo interagire con ESP8266, mi sono trovato molto bene con la libreria LCD_I2C, nella versione 2.3.0.
L’oggetto LCD è istanziato con poche righe di codice, ed è poi accessibile con delle funzioni per il posizionamento del cursore e la scrittura dei dati:
int lcdColumns = 16;
int lcdRows = 2;
LCD_I2C lcd(0x27, 16, 2);

L’unica seccatura è quella di dovere caricare uno sketch dedicato alla scansione del BUS I2C per trovare l’indirizzo dell’expander. In rete si trovano diversi tutorial, completi di codice.

Le funzioni per il posizionamento del cursore e la scrittura dei dati sono molto semplici:
lcd.setCursor(0, 0); // Or setting the cursor in the desired position.
lcd.print("T=");
lcd.print(tempe);

In poche parole, il collegamento del display al modulo ESP ha richiesto davvero pochissimo tempo.

La gestione di MQTT ha richiesto un minimo di attenzione in più, soprattutto per capire “come fare cosa” e gestire in modo opportuno funzioni e temporizzazioni. Il broker MQTT è residente su un server linux. Il sensore deve collegarsi al broker, iscriversi ad un canale e mostrare sul display il valore della potenza attualmente impiegata a casa. Non voglio reinventare la ruota, pertanto rimando ad una ricerca su Google il reperimento delle informazioni sul funzionamento del protocollo.
Per il corretto funzionamento della libreria, bisogna prevedere “a monte” la connessione del dispositivo alla rete, via cavo o via wireless, come mostrato da queste righe di codice:
WiFiClient WFclient;
PubSubClient client(WFclient);

Una volta istanziato l’oggetto client, occorre connettersi al broker ed essere pronti a ricevere i messaggi pubblicati sul canale di interesse. La connessione è gestita direttamente nel loop, ed occorre assicurarsi che nel loop non ci siano inutili perdite di tempo:
void loop() {
if (!client.connected()) {
reconnect();
}
client.loop();


Le funzioni accessorie sono la “reconnect”, che gestisce la connessione al broker (ampiamente documentata in rete).

Altra funzione importante la callback che si occupa della ricezione e della visualizzazione del messaggio MQTT:
void callback(char* topic, byte* payload, unsigned int length) {
Serial.print("Message arrived [");
Serial.print(topic);
lcd.setCursor(0, 1); // Or setting the cursor in the desired position.
lcd.print("P=");
Serial.print("] ");
for (int i = 0; i < length; i++) {
Serial.print((char)payload[i]);
lcd.print((char)payload[i]);
}
Serial.println();
}

Mettendo insieme ESP8266, codice, un level-shifter ed un paio di regolatori, sono riuscito a creare questo “mostro” che legge la temperatura da un sensore DHT, la mostra su un Display e, in calce a questo, mette il valore della potenza “consumata” da casa che gli arriva via MQTT. Come ogni progetto ci sono delle criticità che devo risolvere:
– il display fa schifo. Si tratta di uno dei tanti 16×2 che ho comperato alle fiere ai tempi dei PIC16F84, quando con 50.000 lire ti potevi comperare qualceh 16F84, un paio di 628 e una manciata di display per fare qualche progettino nerd. Per risparmiare prendevo sempre i “non retroilluminati”. Solo che adesso non si legge nulla. Devo mettere un nuovo 16×2 con retroilluminazione o passare ad un OLED.
– la board è alimentata da un trasformatore DIN da 8V, pertanto ho inserito un ponte, un elettrolitico ed un regolatore a 5V. Solo che il regolatore scalda e devo inserire un piccolo dissipatore per evitare che si surriscaldi. Appena lo smonto per mettere il nuovo display, faccio anche questa modifica.

Possibilità di miglioramento:
– inserire un pulsantino per gestire altre visualizzazioni: temperatura esterna, potenza assorbita dalla heat-pump, potenza prodotta dall’impianto FV etc.
– provare un display oled.

Home Assistant – Mqtt e sensori custom

Grazie alla segnalazione di alcuni studenti del corso di “Laboratorio ICT per la nautica e la domotica”, mi sono imbattuto in Home Assistant, una piattaforma per la gestione domotica molto gradevole e ben funzionante. In passato ho usato OpenHAB, ho dato una occhiata veloce a Domoticz ma HA mi è piaciuto tanto che lo eletto a base per lo sviluppo di un nuovo progetto.
Ho diversi sensori a casa, volti alla misura della temperatura in alcune stanze “critiche”, delle condizioni meteo e dei consumi elettrici. I dati raccolti da questi sensori (realizzati su base ESP8266), sono trasferiti ad un server collettore usando il metodo POST in HTTP. Sul server ci sono alcuni script PHP che raccolgono i dati, danno una prima “scremata” e li inseriscono in un database MariaDB. La fruizione dei dati avviene attraverso un terrificante sito web interno, che, attraverso delle tabelle, organizza i dati e consente di tracciare dei grafici scegliendo una diversa base dei tempi. Tutto questo “accrocco” funziona in modo decente, non ho mai perso dati, tutto è catalogato ordinato e preciso. Ci sono anche dei difetti: aggiungere delle automazioni è piuttosto complesso, la visualizzazione dei dati è poco “user friendly”, manca una APP per potere gestire tutto comodamente da SmartPhone.

Una volta conosciuto HA, ho deciso di migrare (piano piano) i dati su questa piattaforma, facendo in modo che il sistema riconosca quanto già presente in rete, ed integrando a mano tutto il resto.
Il primo step è stato installare HA in modalità completa (Home Assistant Operating System) come macchina virtuale nel server di casa. Operazione davvero banale, grazie all’uso di libvirt ed al fatto che ho già altre VM per il monitoraggio della rete dati. La piattaforma è risultata subito perfettamente funzionante ed ha “riconosciuto” alcuni dispositivi come il mio smartphone e la TV. Per integrare altri dispositivi ho seguito due strade:
– uso dei plugin custom presenti nella community di HA o su GItHUB;
– uso “massivo” di MQTT.
La prima via, ha risolto il problema dell’integrazione dello split Daikin (che mi ha fatto penare davvero tanto) e dei router MikroTik. Con la seconda strada ho “sistemato” i sensori custom, senza la necessità di doverli riprogrammare.

Ho quindi installato il broker mqtt usando “mosquitto”, in ambiente linux e modificato lo script PHP che processa i dati in ingresso al server. Questo è stato arricchito da una riga che, sfruttando mosquitto_pub, consente di pubblicare su un canale i dati ricevuti e metterli quindi a disposizione di tutti gli oggetti mqtt.
exec("mosquitto_pub -h localhost -p 1883 -t '/csensors/".escapeshellarg($name)."/temp"."'"." -m ".escapeshellarg($json_string_temp));

exec("mosquitto_pub -h localhost -p 1883 -t '/csensors/".escapeshellarg($name)."/humi"."'"." -m ".escapeshellarg($json_string_humi));

Queste due righe di codice consentono di replicare i dati di temperatura ed umidità ricevuti dai sensori remoti sul sistema MQTT.
La verifica del funzionamento è semplice, basta usare
mosquitto_sub -h localhost -p 1883 -t '#' -v
per mettersi in ascolto su tutti i canali e verificare il corretto scambio di messaggi:
/csensors/xxxx01/temp {"sensore"="xxxx01","value"="24.20"}
/csensors/xxxx01/humi {"sensore"="xxxx01","value"="49.00"}
/csensors/yyyy01/temp {"sensore"="yyyy01","value"="33.00"}
/csensors/yyyy01/humi {"sensore"="yyyy01","value"="31.50"}
/csensors/xxxx01/temp {"sensore"="xxxx01","value"="24.20"}
/csensors/xxxx01/humi {"sensore"="xxxx01","value"="49.00"}


Una volta che i dati sono disponibili sul sistema MQTT, occorre istruire HA per poterli leggere ed elaborare. Per questa operazione è necessario modificare la configurazione del sistema. Io mi sono trovato molto bene con il componente aggiuntivo “Studio Code Server“, che avevo già usato per integrare il NAS e modificare la configurazione dell’oggetto TV.

Ogni dispositivo MQTT deve essere creato appositamente, istruendo HA sul canale da sottoscrivere, il valore da leggere ed i suoi attributi. Il file ha sintassi YAML e particolare cura deve essere prestata alla indentazione.
mqtt:
sensor:
- name: "Temperatura yyyy"
state_topic: "/csensors/yyyy01/temp"
unit_of_measurement: "°C"
device_class: "temperature"
- name: "Umidita yyyy"
state_topic: "/csensors/yyyy01/humi"
unit_of_measurement: "%"
device_class: "humidity"


Terminata la redazione del file di configurazione è necessario riavviare HA per fare in modo che i dispositivi vengano integrati nelle “entità”. A questo punto è immediato aggiungerli ad uno dei tanti pannelli di controllo e visualizzazione che si possono creare.

FT-8 perchè no?

Ho già parlato della mia nuova radio, Yaesu FT-991A, collegata ad una HB9CV per i 50MHz ed ad una verticale bibanda Maldol del 1993 (un dinosauro praticamente). Appena arrivata la radio, la ho collegata al sistema di antenna e, la prima “meraviglia” è stata quella di non avere così tanti disturbi come con il TS-440S/AT. Meno disturbi implica che il rapporto segnale/rumore è più elevato ma, nel mio caso, il “segnale” è minimo, a causa della posizione pessima della mia abitazione.

Un po’ mi sono demoralizzato, poi ragionando, ho capito che non potevo pretendere di sentire segnali che non ci sono, in quanto schermati dalle colline/abitazioni/fagiani che sono intorno casa. Pertanto… perchè non buttarsi sul digitale? Con il TS440 questa operazione sarebbe stata un pochino più macchinosa, visto che avrei dovuto acquistare una interfaccia esterna (che avevo già individuato a dire il vero) ed una manciata di cavi e connettori. Il nuovo arrivato, forte dei 30 anni in meno, ha una connessione USB (se fosse stata ethernet sarebbe stato il top, ma ci ha pensato ICOM) che consente di trasportare controllo ed audio della radio, direttamente al calcolatore. Non mi dilungo su questioni che sono ampiamente documentate in rete. Vista la facilità di connessione, mi sono deciso ad usare uno dei tanti modi digitali in voga in questo momento, optando per FT8.

Prima di usare WSJT-X mi sono documentato, per non fare la figura del minchione e per cercare di entrare un po’ nella terminologia del sistema. Ho trovato alcune letture molto interessanti che mi permetto di consigliare:
– il manuale del FT-991A per capire dove agire per ottenere alcune configurazioni necessarie;
– Il manuale di WSJT-X, davvero encomiabile;
– un articolo tecnico sui modi digitali per weak-signals communications;
– la FT8 Operating Guide, fantastica!
– un articolo di IZ5PQT sui modi digitali, dedicato ad Ft-991A;
articolo simile di W6PQT, dedicato ad FT-991A;
Una volta letti questi documenti in modo critico, ho configurato Ft-991A per potere operare al meglio in FT8 e mi sono avventurato nel mondo digitale. Potenza bassa, indicatore della radio sempre su ALC, un occhio al monitor e via.

Opero solo in 50MHz per adesso, in quanto devo terminare la costruzione del mio dipolo per le HF. Commento a caldo? Che figata! Finalmente anche io che sono in una posizione sfigatissima, posso fare qualche collegamento radio con OM che siano al di fuori del mio comune. In pochi giorni di buona propagazione (il ciclo solare è in partenza), sono riuscito a lavorare diversi country europei, con una grande soddisfazione. Il vantaggio di questo sistema è che posso usare la radio di notte, mentre tutti dormono (prima lo facevo in CW) senza troppi problemi.

Waterfall di una giornata buona.
Decoding della giornata buona.

Personalmente mi piace un sacco questo sistema, richiede un po’ di malizia (che non ho) per dare buoni risultati, ma consente di fare tanto con poco, anzi pochissimo. Grazie a chi ha sviluppato il software ed il codice in quanto mi hanno consentito di rientrare nel mondo dei DX in modo silenzioso ed efficiente. Spero a breve di provare a fare altri collegamenti anche in HF ed in VHF, dove il sistema mi sembra molto promettente. Il top sarebbe riuscire a “remotizzare” la stazione come ha fatto questo OM americano, in modo da potere operare da ogni angolo della casa… e non solo!