homebridge/homebridge-knx <-> knxd: keine Notifizierung bei Bus-Änderungen

[pinky74]

Liebe KNX-Gemeinde,

ich bin neu im Thema KNX, Heimautomatisierung und habe arbeitsbedingt leider wenig Zeit mich in das Thema einzuarbeiten. Da ich von Hause aus SW-Entwickler bin und daher dazu neige mir die Lösungen zusammen zu kopieren kam folgendes Setup heraus:
KNX <-> KNX-USB IF <-> Synology DS713+ (DSM 6.0...) + Docker Image für KNXD (v.12) + Docker Image für Homebridge mit Homebridge-KNX plugin (v.0.3) <-> Apples Home App auf dem iPhone 6

Bisher ist es mir gelungen als PoC eine Lampe im Arbeitszimmer per iPhone ein- und auszuschalten. Leider habe ich aber das Problem, dass bei einer Änderung des Status der Lampe (durch Druck auf dem Taster im Raum), diese nicht auf dem iPhone mitzubekommen.

Irgendwo auf der langen Strecke scheint das Telegramm unterzugehen bzw. nicht weiterzukommen.

Ich starte knxd mit
# knxd -t1023 -f9 -e 0.0.1 -E 0.0.2:8 -DTRS -i -b usb:

Ein groupswrite ip:localhost 1/1/25 0|1 funktioniert und wird im busmonitor1 auch angezeigt. Komischerweise ist der log des vbusmonitor1 leer bzw. bei entsprechendem debug Level kommen nur irgendwelche Byte-Arrays.

Das homebridge-knx plugin hört auf den Port 6270 und geht auf die IP der Synology. Listen auf die GA ist auch drin.

Grundsätzlich funktioniert es ja, aber ohne diesen Updatemechanismus ist es für mich nicht nutzbar.

Hat jemand einen Tipp, wie ich das Problem zumindest etwas eingrenzen kann? Muss ich noch den Socket mit aufmachen (-u)?

Danke für Eure Hilfe!

Gruß
Simon

[Smurf]

Du willst grundsätzlich nicht busmonitor1, sondern vbusmonitor*.

Nimm mal -t 254, das sollte reichen für den Anfang.

Passiert überhaupt irgendwas im Log, wenn du die Taste drückst? eigentlich sollten da zwei Pakete ankommen (die 1/1/25 um die Lampe zu schalten, und was-auch-immer für die Statusänderung).

[pinky74]

Das nenne ich mal eine kurze Resonse-Time. Danke schon mal dafür!

Muss kurz korrigieren: Habe mittlerweile Listen auch wieder auf die GA 1/1/25 zurückgesetzt.

Habe -t254 verwendet und erhalte im vbusmonitor1 bei ausschalten und direktem wieder einschalten folgenden Output des vbusmonitor1 (-t254 hat darauf keinen Einfuß oder? Bezieht sich ja auf knxd, oder?):

root@DiskStation-II:~# knxtool vbusmonitor1 ip:localhost
LPDU: B0 3F 00 BC 11 25 09 19 E1 00 80 0F 86 :L_Data system from 3.15.0 to 11.12.17 hops: 02 Unknown TPDU: 09 19 E1 00 80 0F
LPDU: B8 8E FC BC 11 02 09 1A E1 68 :L_Data normal from 8.14.252 to 11.12.17 hops: 00 Unknown TPDU: 09 1A E1

LPDU: B8 B5 F8 BC 11 25 09 19 E1 00 81 0E FC :L_Data normal from 11.5.248 to 11.12.17 hops: 02 Unknown TPDU: 09 19 E1 00 81 0E
LPDU: B0 0F 0C BC 11 02 09 1A E1 11 :L_Data system from 0.15.12 to 11.12.17 hops: 00 Unknown TPDU: 09 1A E1

Was mich wundert: Die angegebenen Adressen sind alles andere als die mir bekannten (also weder Überstimmung mit IP noch GA).

Zum Vergleich der Log bei Verwendung von:
knxtool groupswrite ip:localhost 1/1/25 0 bzw 1 ist deutlich klarer:

root@DiskStation-II:~# knxtool vbusmonitor1 ip:localhost
LPDU: BC 00 05 09 19 E1 00 80 37 :L_Data low from 0.0.5 to 1/1/25 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 00
LPDU: B0 C9 F4 BC 11 02 09 1A E1 2F :L_Data system from 12.9.244 to 11.12.17 hops: 00 Unknown TPDU: 09 1A E1

LPDU: BC 00 06 09 19 E1 00 81 35 :L_Data low from 0.0.6 to 1/1/25 hops: 06 T_DATA_XXX_REQ A_GroupValue_Write (small) 01
LPDU: B0 6A DC BC 11 02 09 1A E1 A4 :L_Data system from 6.10.220 to 11.12.17 hops: 00 Unknown TPDU: 09 1A E1

Irgendeine Idee warum das unterschiedliche logs erzeugt?

[pinky74]

Ich sehe gerade wenn man die Logs vergleicht, dass diese sich ähnlicher sind als man denkt. Im Falle von Taster kommen am Anfang noch 3 Bytes dazu (B0 3F 00).
Wenn man diese gedanklich entfernt, dann steht dort nur noch:
BC 11 25 09 19 -> übersetzt heißt das (wenn ich das richtig verstanden habe): from 1.1.37 to 1/1/25

Es gibt allerdings kein Gerät mit der IP 1.1.37. Lediglich eine GA mit 1/1/37. Die wird aber nur geschickt, wenn man vom selben Taster (ist ein 4fach Tastsensor) die Taste 3 drückt (aktuell drücke ich die Taste 1 für GA 1/1/25).

Grundsätzlich scheint also etwas anzukommen.

Meine Frage(n) wäre(n) nun noch:
Wie erkenne ich, ob sich das homebridge-knx Plugin am knxd angemeldet hat?
Ist das eine dauerhafte Verbindung oder nur "on demand" (zählt also die Client ID hoch bei jedem Befehl 0.0.3 .. 0.0.4 ... etc.) und trennt sich danach wieder (dann wäre ja per Definition keine Notification möglich)?
Kann man irgendwie sichtbar machen, dass der knxd an seine Clients auch was verschickt?

[Smurf]

Das klingt jetzt so als würde dein Adapter ein anderes Protokoll verwenden. Teste mal ft12cemi.

[pinky74]

Wie soll ich das anstellen? Habe jetzt folgendes probiert:
knxd ... -b ft12cemi: -> initialisation of backend 'ft12cemi:' failed: No such file or directory
knxd ... -b ft12cemi/dev/ttyS0 (bis 3) -> funktioniert, aber groupswrite geht ins Leere
knxd ... -b ft12cemi:/dev/usb/hiddev8 -> initialisation of backend 'ft12cemi:/dev/usb/hiddev8' failed: Invalid argument


Oder gibt es eine Option nur das Protokoll zu ändern, also sowas wie:
knxd ... --enable-ft12cemi -b usb:

[Smurf]

Sorry, ich war blind, du hast ja USB statt seriell.

Dui hast recht mit den drei Bytes am Anfang. Ich habe (noch) keine Ahnung, wo die herkommen. Was ist das für ein KNX-USB-Adapter?

[pinky74]

Busch Jäger 6186 USB. Habe noch keine Info gefunden was er an Protokollen kann. In einem Paper von 2008 habe ich gesehen, dass der
Busch-Jäger EIB sensor USB, art. no. 6123 USB-82 weder EMI2 noch cEMI kann und wohl nur eine alte Version des EMI1. Über den "neueren" von mir (2012) habe ich nichts gefunden. Leider habe ich hier keine Bauumgebung, sonst hätte ich mal versucht lokal auf das FT1.2 zu patchen. Habe wir vorhin die KNX Spec angeschaut und gesehen, dass hier die ersten 4 und letzten 2 Byte weggenommen werden (um von FT1.2 auf EMI zu kommen). Grundsätzlich hast du also schon den richtigen Richer gehabt...

Ich habe auch schon dieses BCUADDRTAB reset gesehen, aber das ist nur für seriell oder? Abgesehen davon dass ich die exe gar nicht habe...

[pinky74]

Nur zum testen würde ich mal gerne die 4 Byte weglassen beim parsen in eibusb.cpp, line 275 und:
res1->set (res.data() + 11, res[6]);
ersetzen mit
res1->set (res.data() + 15, res[6] - 4 );

Jetzt brauch ich nur noch jemanden der mir das für mein x64-linux auf der Syno baut :-)

[Smurf]

Also generell sagen die Adapter, welche [c]EMI[12]-Version sie sprechen. Siehe src/libserver/eibusb.cpp, da wird das abgefragt.

Ohne den Adapter selber zu haben (oder Zugang zu selbigem), sind meine Debugmöglichkeiten etwas eingeschränkt. Wenn du das irgendwie ermöglichen könntest, wäre es fein.

[pinky74]

Laut Knxd log ist es emi1.
Was mich nur wundert ist dass das anschließende (nachdem das Protokoll verifiziert wurde) read dies nicht unterscheidet/beeinflusst.

Werde wohl um eine Build Umgebung nicht rumkommen.

melde mich wieder...

[pinky74]

UPDATE: Habe eine build Umgebung aufgesetzt und die Datei eib_common.cpp, line 189 gepachted indem ich folgendes hinzugefügt habe (ignoriert einfach die ersten 3 Bytes des EMI Protokolls):
CArray res = *c;
c->set (res.data() + 3, res.size() - 3);

Damit funktioniert es nun. Alle Konsolenausgaben machen nun Sinn und die IP-Adressen passen alle. Mit homebridge klappt es nun auch.
Habe auch in der Spec nachgeschaut aber auf anhieb nicht diesen Umstand verstanden.

Vielleicht kann sich einer erklären was mein USB-Adapter hier schickt...

Für den Moment habe ich also eine Lösung und das Thema ist mit diesem Hack erst mal erledigt. Wenn ich mal wieder Zeit habe, prüfe ich noch ob Programmierung und andere Werte schreiben als nur bool auch funktioniert.

Danke noch mal an Smurf für die sagenhaft schnellen Antworten!

[Smurf]

Starte mal mit -t1023. Da findest du eine Zeile

 
 Send(064): 01 13 09 00 08 00 01 0F 01 00 00 01 00 …

Die darauffolgende Zeile "RecvUSB" hätte ich gerne. Irgendwie muss man ja diesen Adapter von anderen EMI1-Lieferanten unterscheiden können.

[pinky74]

RecvUSB(064): 01 13 17 00 08 00 0F 01 01 00 00 49 02 83 1C 9C 12 17 25 21 D3 00 80 07 E6 D0 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

Laut Spec ist die Länge der Nachricht (LDAP ist das glaube ich dann) an Position 7, hier 0F also 15. Das stimmt - ausgehend von Start an Position 12 beginnend mit 49...
49 ist laut KNX Spec 2.1, Kapitel 3.6.3 (EMI) dann der Typ der Nachricht (hier bei EMI1: L_Data.ind). Dieser erwartet an Pos2 das Control (im Wesentlichen die Prio), dann 2 Byte für source und 2 Byte für Destination. In der Nachricht oben kommen aber nach der 49 noch 02 83 1C bevor dann mit 9C das Control, 12 17 die Source und 25 21 die Destination kommt. Habe auch gesehen, dass ab und an ein Timestamp mit im EMI Telegram vorkommt. Nach Analyse der console logs machen die aber keinen Sinn (keine permanente Zunahme, sondern wild springende Werte).

Nach aktuellem knxd Stand wird dann daraus:

RecvEMI(015): 49 02 83 1C 9C 12 17 25 21 D3 00 80 07 E6 D0

Wie schon erwähn, wenn die drei Bytes (02 83 1C) entfernt werden, dann passt es soweit...

[Smurf]

Du missverstehst. Ich suche die RecvUSB-Zeile, die die Antwort auf den erwähnten Send ist. Findet sich ziemlich am Anfang des Ganzen. Ein vollständiges -t1023-Log wäre noch besser.