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.
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.