Archivi categoria: Elettronica

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.

KNX Bus Monitoring a basso costo

Supponiamo che si voglia realizzare un monitor del bus KNX in una installazione domestica con “valore aggiunto” domotico. Le strade possibili sono diverse e variano a seconda del tipo di portafoglio e di installazione realizzata.
Per gli utenti Gewiss che hanno prodotti della serie “easy”, la funzione di monitoraggio è offerta dal software Easy Controller, che tuttavia non registra le informazioni su disco.
Per chi voglia avere un approccio generico, è possibile usare ETS5/6 in modalità “demo” in modo da non dovere pagare la costosissima licenza.
Il limite di questi software è costituito dal fatto che NON nascono per una applicazione di monitoraggio del bus, ma offrono questo servizio a supporto del “debug” delle applicazioni.

In entrambi i casi è necessario disporre di una interfaccia tra bus KNX e calcolatore, con collegamento via rete LAN, seriale o USB. Le interfacce di marche blasonate sono molto costose. Il mercato pullula di interfacce low-cost, da usare direttamente connesse alla Raspberry o che richiedono un collegamento seriale. La maggiore parte sono le tpuart, che sono ampiamente citate negli esempi trovati in rete.
Volendo fare qualche prova con la “valigia domotica Gewiss”, ho acquistato su Aliexpress, una semplice interfaccia USB/KNX (KNX Downloader) al prezzo di 56 euro. Non sono pochi ma sono una frazione rispetto a quanto richiesto dai “big players”.

L’idea è quella di integrare questo dispositivo in ambiente Linux (Ubuntu server) ed associarlo a KNX per potere realizzare un logger. Gli step sono:
– installare Ubuntu server su una macchina virtuale;
– compilare, fare funzionare knxd in modo dignitoso;
– fare comunicare KNXD con l’interfaccia;
– fare in modo che knxd “tiri fuori i dati” dal bus knx in qualche forma.

Complice il fatto che sono un principiante di KNX, questo processo mi ha richiesto un sacco di tempo e per questo vorrei documentarlo al meglio.
KNXD (maggiori informazioni qui) (oppure qui)
Installare questo software con un pacchetto debian o ubuntu significa perdere tempo. knxd DEVE essere ricompilato e per farlo, occorre prima scaricare “qualche” libreria e pacchetto aggiuntivo:
– apt install libtool
– apt install libusb-1.0-0-dev
– apt install libsystemd-dev
– apt install build-essential
– apt install libev-dev
Fatto questo è possibile clonare il repository: git clone https://github.com/knxd/knxd.git e procedere, come indicato sul sito, alla compilazione:
– cd knxd
– git checkout main
– sh bootstrap.sh
– ./configure –your-chosen-options
– make
– make install
Lo step che può dare “grattacapi” è quello che esegue bootstrap.sh, script deputato (anche) al controllo della presenza di tutto il necessario per la compilazione. Il build del software richiede qualche minuto ma termina con successo. Una volta eseguita l’installazione, tutti i binari si trovano al loro posto.

Lo step successivo è dare in pasto a knxd il dispositivo giusto. Il KNX-Downloader viene riconosciuto immediatamente ma occorre rendere l’accesso al device più libertino.
root@knx:~# lsusb
Bus 001 Device 003: ID 0403:6898 Future Technology Devices International, Ltd TSY KNX-USB Data Interface
Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
root@knx:~#


Usando udevadm: si crea il file /etc/udev/rules.d/70-knxd.rules ed al suo interno si inserisce questa stringa:
SUBSYSTEMS==”usb”, ATTRS{idVendor}==”067b”, ATTRS{idProduct}==”2303″, GROUP=”users”, MODE=”0666″
In questo modo, quando il sistema udev, riconosce il device, così come descritto da idVendor e id Product, associa ad esseo il permission 0666.
Per verificare che knxd possa digerire il dispositivo c’è un comodissimo comando: findknxusb:
root@knx:~# findknxusb
Possible addresses for KNX USB devices:
device: 1:3:1:0:0 (TSY Technology:TSY KNX-USB Data Interface)

Una volta verificata questa possibilità non rimane altro che configurare knxd, e su questo punto ho impiegato diverso tempo.

Chiariamo che knxd non è altro che un router tra il mondo knx ed il mondo ip, in pratica è possibile configurarlo per fare in modo che ad una PDU KNX corrisponda un pacchetto ip e viceversa. knxd può essere configurato attraverso un file di configurazione (che DEVE avere estensione .ini) o attraverso la riga di comando, passandogli una serie di parametri che, fortunatamente sono molto ben documentati, in questo sito.
Dopo diverse prove e grazie a questo sito, la stringa funzionante è questa:
knxd –trace=5 –error=5 –eibaddr=0.2.118 –client-addrs=0.2.20:20 -D -T -R -S -i -b usb:
Due parole di spiegazione:
– trace ed error: livello di debug e di report durante l’esecuzione del software;
– eibaddr: indirizzo del device softare knxd. Come se fosse l’indirizzo dell’adattore USB;
– client-adds: spazio degli indirizzi dei client che si connettono lato ip.
– D : discover. Consente a knxd di rispondere ai pacchetti di discover;
– T : abilita la funzione di tunneling;
– R: consenti lo scambio di pacchetti multicast, usato da altri router knx;
– S: seleziona l’interfaccia ip, sulla quale è presente la default route;
– i: aggancia knxd su tutti gli indirizzi ip< configurati sul dispositivo;
-b: specifica il dispositivo L2 da usare per la connessione
– usb: nella versione attuale, non richiede di specificare il dispositivo da usare. KNXD cerca tra i dispositivi, quello più adatto ai suoi scopi.
SE tutto va a buon fine:

root@knx:~# knxd –trace=5 –error=5 –eibaddr=0.2.118 –client-addrs=0.2.20:20 -D -T -R -S -i -b usb:
W00000125: [ 1:main] Consider using a config file.
W00000126: [ 1:main] knxd should not run as root
Layer 0 [16:B.usb/USBdr 0.020] starting send_Local
Layer 0 [18:B.usb/usbL 0.020] SendUSB(064): 01 13 09 00 08 00 01 0F 01 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0 [18:B.usb/usbL 0.020] StartSend 5595789896d0
Layer 0 [ 4:server/Server 0.020] Open
Layer 0 [ 4:server/Server 0.020] Opened
N00000127: [22:router.pace_] The ‘pace’ filter without a queue acts globally.
Layer 0 [16:B.usb/USBdr 0.031] send_Local done
Layer 0 [18:B.usb/usbL 0.035] RecvUSB(064): 01 13 0B 00 08 00 03 0F 02 00 00 01 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 2 [16:B.usb/USBdr 0.035] recv_Data(064): 01 13 0B 00 08 00 03 0F 02 00 00 01 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 2 [17:B.usb/Conv 0.035] send_Init 3
Layer 0 [17:B.usb/Conv 0.035] starting send_Local
Layer 0 [18:B.usb/usbL 0.035] SendUSB(064): 01 13 0A 00 08 00 02 0F 03 00 00 05 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Layer 0 [18:B.usb/usbL 0.035] StartSend 5595789719a0
Layer 0 [17:B.usb/Conv 0.047] send_Local done
Layer 2 [23:B.usb/CEMI 0.047] OpenL2

A questo punto occorre trovare un software che possa decodificare il traffico knx in modo da poterlo elaborare in modo opportuno.
I candidati sono due:
knxtool e knx-logger.
–knxtool (maggiori informazioni qui ed anche qui)
Programma che consente di interagire con il bus knx. La descrizione in rete non rende giustizia a questo tool, davvero complesso. Invocando il comando con lo switch “list” si ottengono tutte le opzioni di esecuzione:

Tra le tante opzioni sono evidenti i “bus monitor” ed il “vbusmonitor”. In rete ho trovato alcune indicazioni in merito ad un non corretto funzionamento di “busmonitor”, pertanto mi sono concentrato su “vbusmonitor”.
La sintassi di knxtool, prevede che venga invocato indicando l’indirizzo ip dell’interfaccia alla quale si deve collegare:
root@knx:~# knxtool vbusmonitor1 ip:192.168.188.176
L’avvenuta connessione è mostrata anche da knxd:
Layer 0 [24:A.tcp/CConn 3987.870] ReadMessage(002): 00 13
Layer 0 [24:A.tcp/CConn 3987.870] Send(002): 00 13

A questo punto il sistema è “pronto” per interpretare i telegrammi che transitano sul bus knx.
–knxlogger ( maggiori informazioni qui )
Tool essenziale, con una minore configurabilità rispetto al precedente. Per la invocazione richiede solo l’indicazione dell’ip sul quale fare la connessione.
root@knx:~/knx-logger# ./knx-logger ip:192.168.188.176
2022-05-16 07:21:15 Write FROM 0.2.5 TO 24/0/14 VALUE


Fortunatamente sono in una situazione ideale: ho la valigia domotica a disposizione, collegata al calcolatore con una interfaccia USB Gewiss e posso monitorare il traffico KNX con l’applicazione “Easy Controller Software“. Contemporaneamente ho una macchina virtuale che esegue Ubuntu server, ove è in esecuzione knxd ed il logger. Pertanto posso fare un parallelo tra azione (pressione di un pulsante) e modo in cui i due software registrano e visualizzano l’evento.

Configurazione di sistema
Pressione di un pulsante sul dimostratore.

Il modo in cui knxtool mostra il telegramma dipende dallo switch con il quale è stato invocato:
vbusmonitor1:
L_Busmon: BC 02 05 C0 0E E1 00 81 EA :L_Data low from 0.2.5 to 24/0/14 hops: 06 T_Data_Group A_GroupValue_Write (small) 01
vbusmonitor2:
BC 02 05 C0 0E E1 00 81 EA
vbusmonitor3:
(0, f9e953b3) BC 02 05 C0 0E E1 00 81 EA

Nel primo caso le informazioni hanno una componente “human readable”: Il telegramma è stato inviato dal dispositivo 0.2.5 (coerente con l’analizzatore Gewiss) ed ha un determinato payload. L’intepretazione della stringa deve essere fatta attraverso delle funzioni (python ne prevede di native – untested) o riferendosi alla specifica del protocollo.

Come ultimo step, ho voluto fare un monitoraggio del bus anche con ETS5, versione professional. Mi ha colpito il fatto che all’avvio, ETS abbia “visto” anche knxd come interfaccia usabile per la configurazione/monitoraggio del sistema.

Premendo il “solito” pulsante, il risultato di ETS è maggiormente prolisso:

Conclusione:
in questo non breve articolo, ho presentato una soluzione economica per il monitoraggio della bus KNX. I test di funzionamento sono stati svolti utilizzando un dimostratore domotico commerciale ed hanno dato ottimi risultati.

Odroid XU3

Da diversi anni ho installato una Odroid XU3 in uno spazio attrezzato, ove funge (essenzialmente) da piattaforma per Spyserver. Malgrado sia un oggetto piuttosto datato, lavora molto bene e non è particolarmente avida di energia.
Recentemente ho notato che tende ad essere un po’ calda, pertanto, oltre a sostituire la ventolina che non ne poteva più, ho provato a fare un po’ di hack sul controllo della rotazione.
Ho letto un interessante articolo su un forum, in cui viene spiegato in modo molto semplice come cambiare la logica di intervento della ventola. Le impostazioni che ho configurato sono un po’ aggressive: alla temperatura di 50°C la ventola gira al 50%, a 65°C si sale all’80% ed oltre i 75°C arriviamo al valore di 95%. Considerato che la ventola è inserita in un contesto piuttosto “caldo” è meglio “prevenire”.

Situazione di partenza, temperatura media 64°C

Dopo qualche giorno di lavoro, la situazione è la seguente. Tocca solo capire quanto durerà la ventola!

Dopo la cura!

Stazione meteo: 3.0

Da diversi mesi ho smontato la stazione meteo che avevo sul tetto. Finalmente mi sono deciso a farne una nuova. Le motivazioni sono semplici: voglio passare dalla connettività wireless a quella cablata e fare tesoro di quanto scritto in questo articolo.

La nuova piattaforma sarà inizialmente basata su una Raspberry Pi 2. Ormai questo hardware è molto vecchio e non si adatta a lavori molto intensi per carico di CPU. Meglio quindi relegarlo alla data acquisition, visto che a bordo c’è tutto quello che serve: SPI, I2C, Camera ed ethernet. Spero solo che la CPU “regga” il caldo, ma se non dovesse risultare stabile ho pronto un “piano B”. Le caratteristiche della nuova piattaforma:
– alimentazione singola a 12V con regolatori interni per 5V e 3.3V;
– Raspberry PI 2 con camera;
– sensore BME 280 interno per rilevare pressione e la temperatura interna del box;
– sensore DHT 22 esterno per umidità e temperatura;
– convertitore A/D MCP3424A per lettura della velocità del vento;
– rimozione del sensore di direzione del vento (almeno per ora);
– predisposizione per sensore di pioggia;

In questi giorni di sviluppo hardware e software ho anche riaperto la vecchia stazione meteo che era operativa dal 2018 ed ha preso notevoli “botte” di grandine e caldo. La situazione all’interno del box è molto molto buona. Non ci sono segni di ossidazione. Solo i cavi hanno sofferto notevolmente e si sono rovinati (devo rinforzarli). Spero di ripristinare le funzionalità entro fine marzo.

In fase di apertura.
La board
Cavo danneggiato dal pressacavi
Nessun segno di ossidazione

La giornata del saldatore

Ieri, dopo parecchio tempo, ho rimesso mano al saldatore per sistemare un paio di lavoretti arretrati.
Il primo è relativo ad un “trapianto di memoria” in una vecchia chiavetta USB nella quale si è bruciato il controller. La persona che mi ha affidato il dispositivo è riuscita a trovare un oggetto IDENTICO, che ha reso possibile l’operazione di espianto della memoria e inserimento nella chiavetta con il controller funzionante.
L’operazione è stata piuttosto articolata in quanto è stato necessario dissaldare il chip di memoria originale (fatto con la tecnica della colata di stagno), pulire bene i pad e poi risaldare il chip di memoria. Fortuna il saldatore con stilo SMD. La chiavetta, per pura fortuna non si era danneggiato il chip di memoria, è risultata subito funzionante ed ha consentito di recuperare tutto il contenuto.

Le chiavette gemelle
Particolare del chip di memoria risaldato
Chiavetta funzionante.

Il secondo intervento è stato relativo al ripristino di un cavo HP 11730A, usato per la connessione della testina generatrice di rumore ad un NFA 8975A. Per motivi di ageing uno dei pin si è rotto, rendendo impossibile il riconoscimento della testina e la misura.
Dopo qualche tentativo, sono riuscito a risaldare il pin e la testina viene riconosciuta. Non è un lavoro da poco in quanto il cavo è dannatamente costoso!

Il pin riparato.

UCCM – GPSDO la coppia

Finalmente è arrivato il GPSDO che attendevo, come rimpiazzo del buon vecchio Trimble che si è (o è sempre stato) rotto. Un paio di giorni per compiere il trapianto di organo e, finalmente, sulla mia Timing-Desk ho due GPSDO up and running.
Anche questo Samsung è passato subito in stato locked con valori di TFOM stabili ad 1. Si tratta di una unità non propriamente “gemella” dell’altra: il quarzo installato è di dimensioni notevolmente maggiori (sempre marcato Samsung).

Lady Heather per il nuovo Samsung.

La posizione stimata dai due dispositivi è davvero molto “prossima”, visto che usano lo stesso ricevitore GPS (Ublox Lea-6t) e sono nelle stesse condizioni operative:
Samsung 1 (old)
Lat: 43.5866244N Long: 13.5170058E Alt: 226.24
Samsung 2 (new)
Lat: 43.5866200N Long: 13.5170047E Alt: 225.99
Distanza stimata su WG84 di 0.5m, non male.

In modo molto barbaro ho fatto una misura di frequenza, mantenendo il vecchio Samsung (OSM da qui in poi) come riferimento per il counter ed il nuovo come DUT. La misura è incoraggiante.

Misura di frequenza di NSM vs OSM.

Adesso occorre solo aspettare che arrivi il Thunderbolt e qualche accessorio per farlo funzionare:
– amplificatore di distribuzione a 10MHz;
– distributore del segnale GPS a 4 vie (utile anche per una idea futura);
– HUB e convertitori USB-RS232 per il controllo ed il monitoraggio dei sistemi.
Intanto mi godo il monitor!

Trimble UCCM GPSDO – EOL

In un vecchio articolo ho parlato di un oscillatore UCCM Trimble che, dopo molti anni, era riuscito a dotare di case, alimentatore e monitor. Una volta collegato il ricevitore all’antenna, Attivato il monitoraggio del ricevitore mi sono reso conto che qualche cosa non andava: in pratica l’UCCM non passa mai allo stato di LOCK (luce che lampeggia velocemente), in quanto, sembra, che la board non riesca a disciplinare l’oscillatore.
Ho chiesto idee e suggerimenti anche sull’ottimo forum eevblog, ma senza particolari esiti. Pertanto ho provato a giocare un po’ con oscillatore e board, per cercare di capire dove potesse essere il problema.

Il primo step è stato quello di smontare l’oscillatore dalla board, collegarlo ad una fonte di alimentazione lineare e stabile e fare qualche misura di corrente e frequenza. In questa fase ho valutato:
– assorbimento in corrente, deve essere non costante. Il quarzo (OCXO) deve assorbire parecchia corrente in fase di Warm-UP e poi deve stabilizzarsi a valori “ragionevoli;
– frequenza iniziale del quarzo, con il terminale Vtune posto a massa.
Per fare queste acquisizioni ho rispolverato LabView, su una comoda macchina virtuale Windows 10. Gli strumenti usati sono un multimetro da banco HP 34401A ed un counter HP 53131A. Quest’ultimo ha un reference 10MHz esterno, proveniente dal GPSDO Samsung.

Corrente in funzione del tempo.

Il “forno” funziona bene. Il tempo di riscaldamento è ragionevole e, trascorso tale transitorio, la corrente si assesta su valori bassi. Fino a qui, tutto ok. Anche la frequenza di uscita è stabile e centrata attorno ai 10MHz, non ci sono particolari deviazioni, tutto sembra rientrare nella norma (anche se non avendo un datasheet, la norma è un concetto un po’ vago). Ho anche tracciato un grafico della funzione “Frequenza vs Vtune” del quarzo, anche questo è piuttosto lineare (la “gobba” nella parte iniziale è dovuta ad un diverso metodo di misura).

Lo step successivo è stato quello di rimontare l’oscillatore nella board per monitorare la corrente assorbita dalla board, la frequenza di uscita e la tensione di controllo. In teoria la tensione di controllo, dopo un po’ di swing iniziale, dovrebbe assestarsi su un valore costante, mentre il sistema va in lock ed inizia a funzionare regolarmente.

Corrente della board

tensione di controllo.

Anche qui… ci siamo, almeno in teoria. Solo che il sistema, anche monitorato da Lady Heater, non raggiunge mai lo stato di LOCK, mantenendo valori di TFOM molto alti (3 – 7). Inoltre il valore della differenza di fase è molto “ballerino” arrivando a valori molto bassi (4.5 E-6) per tempi brevissimo per poi ricadere in alto (1 E-2). Qualche problema c’è sicuramente. Sarà la board? Sarà l’oscillatore? Non sono in grado (per adesso) di dirlo. Intanto ho ordinato un altro GPSDO per fare “la coppia” in attesa che arrivi un altro giocattolo molto interessante.

Counter HP 53131A

Da qualche tempo, in ufficio, ho un counter HP 53131A. Leggendo nella lista time-nuts, ho scoperto che non è un fenomeno nella misura della frequenza, soprattutto a 10MHz. Malgrado questo, vorrei provarlo con i software di KE5FX, pertanto mi sono dotato di una interfaccia GPIB – USB della National Instruments ed ho provato a fare colloquiare il PC con il counter.

Malgrado i mille tentativi non sono mai riuscito nell’impresa fino a quando mi è sorto un atroce dubbio: vuoi vedere che l’adattatore non fa contatto con la presa sullo strumento? Questo malgrado io abbia serrato completamente le viti di bloccaggio dell’adattatore stesso. Pertanto ho recuperato due vecchi cavi GPIB, ho tolto la abbondante polvere ed ho collegato l’adattatore: tutto perfettamente funzionante.

Inutile sottolineare il mio disappunto per questa cosa. Il lato positivo è che adesso ho collegato sia il counter che il multimetro via GPIB e posso, con un po’ di fantasia, controllarli da LabView per fare qualche misura “long term”. Da questo punto di vista è molto utile avere LabView su una macchina virtuale nella WorkStation dell’ufficio, in modo che possa lavorare anche quando non sono sulla scrivania. Nei prossimi giorni qualche considerazione su un GPSDO che non vuole saperne di funzionare!