eibd anstatt knxd?

[drehm]

die option --no-tunnel-client-queuing wird schon benutzt, ändert aber nichts. habe mal die traces vom knxd aktiviert. hier sehe ich, dass smarthomeNG beim start alle gruppenaddressen anfragt, die unter den items mit knx_init markiert sind, allerdings liesst der knxd nicht alle Adressen ein. Lediglich bei 3 der 10 angefragten Adressen bekomme ich ein "Recv L_Data low from 0.2.6 to 2/2/10..."

Auf einem 2ten PI-2 habe ich noch das ursprüngliche Image der smarthome.py mit SmartVISU 2.7 und eibd 0.0.5. Hier funktioniert das "initialisieren" ohne Probleme. Macht es sinn das image von smarthomeNG zu nehmen und zu installieren um das Problem zu lösen, oder besteht das Risiko, dass es doch irgendwo an meiner Konfiguration liegt und ich mit dem neuen Image dann auch wieder die gleichen Probleme habe?

[wvhn]

Ich würde erstmal alle Optionen des eibd-Aufrufs vom alten Pi auf den knxd-Aufruf am neuen Pi übertragen. Wenn das nichts hilft, würde ich die eibd-Dateien vom alten auf den neuen Pi kopieren. Dann muss man knxd Socket und Service disablen. Wie man ein Service-file für eibd erstellt, habe ich hier beschrieben: https://github.com/wvhn/smarthome/wi...aspbian-Jessie (ganz unten)

Nicht dass ich empfehle, eibd wieder einzusetzen. Aber dies würde helfen, den Fehler weiter einzugrenzen und ggfls. ein issue beim knxd auf github aufzumachen.

Gruß Wolfram

[drehm]

Hallo zusammen, habe versucht den eibd unter dem raspian zum laufen zu bringen, was jedoch leider nicht funktioniert, da sich der eibd auf dem raspian image zwar compilieren lässt, allerdings kommt es zu einer Segmentation fault beim Versuch ihn zu starten.

Habe aber dafür noch ein paar traces vom knxd und der ETS erstellt.

Im knxd log sieht man, dass die GruppenAddressen 2/2/10, 2/2/9, ... bis 2/2/1 angefragt werden:

Layer 4(01163978,583C968E) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0110F5E8,583C968E) Enqueue L_Data low from 0.0.0 to 2/2/5 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 8(01162B58,583C968E) RecvMessage(006): 00 27 03 06 00 00
Layer 7(0118354C,583C968E) Send(002): 00 00
Layer 4(01163978,583C968E) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0110F5E8,583C968E) Enqueue L_Data low from 0.0.0 to 0/3/6 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 8(01162B58,583C968E) RecvMessage(006): 00 27 0A 08 00 00
Layer 7(0118354C,583C968E) Send(002): 00 00
Layer 4(01163978,583C968E) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0110F5E8,583C968E) Enqueue L_Data low from 0.0.0 to 1/2/8 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 8(01162B58,583C968E) RecvMessage(006): 00 27 12 04 00 00
Layer 7(0118354C,583C968E) Send(002): 00 00
Layer 4(01163978,583C968E) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0110F5E8,583C968E) Enqueue L_Data low from 0.0.0 to 2/2/4 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 8(01162B58,583C968E) RecvMessage(006): 00 27 03 04 00 00
Layer 7(0118354C,583C968E) Send(002): 00 00
Layer 4(01163978,583C968E) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0110F5E8,583C968E) Enqueue L_Data low from 0.0.0 to 0/3/4 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 8(01162B58,583C968E) RecvMessage(006): 00 27 0A 04 00 00
Layer 7(0118354C,583C968E) Send(002): 00 00
Layer 4(01163978,583C968E) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0110F5E8,583C968E) Enqueue L_Data low from 0.0.0 to 1/2/4 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 8(01162B58,583C968E) RecvMessage(006): 00 27 12 02 00 00
Layer 7(0118354C,583C968E) Send(002): 00 00
Layer 4(01163978,583C968E) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read
Layer 3(0110F5E8,583C968E) Enqueue L_Data low from 0.0.0 to 2/2/2 hops: 07 T_DATA_XXX_REQ A_GroupValue_Read
Layer 8(01162B58,583C968E) RecvMessage(006): 00 27 03 05 00 00
Layer 7(0118354C,583C968E) Send(002): 00 00
Layer 4(01163978,583C968E) Send GroupSocket T_DATA_XXX_REQ A_GroupValue_Read

Im ETS Busmonitor sehe ich jedoch nicht den Read request für die GruppenAddressen 2/2/5, 2/2/4 und 2/2/2:

# Time Service Flags Prio Src.addr Source Dest.addr Destination Rout DPT Type Data
25 21:41:52.105 from bus L 1.1.128 Not Found 2/2/10 Wohnzimmer Terrasse 6 - Read
26 21:41:52.119 from bus L 1.1.128 Not Found 0/3/12 Haustechnikraum 6 - Read
27 21:41:52.147 from bus L 1.1.128 Not Found 1/2/24 Haustechnikraum 6 - Read
28 21:41:52.161 from bus L 1.1.128 Not Found 0/3/15 Garage 6 - Read
29 21:41:52.174 from bus L 1.1.128 Not Found 0/3/16 Heizungsraum 6 - Read
30 21:41:52.202 from bus L 1.1.128 Not Found 1/2/27 Heizungsraum 6 - Read
31 21:41:52.216 from bus L 0.2.7 HV 25 - 28 0/3/12 Haustechnikraum 6 1 byte Response $01 | 0 %
32 21:41:52.230 from bus L 1.1.128 Not Found 2/2/9 Heizungsraum 6 - Read
33 21:41:52.258 from bus L 0.2.5 HV 29-32 0/3/15 Garage 6 1 byte Response $01 | 0 %
34 21:41:52.272 from bus L 0.2.5 HV 29-32 0/3/16 Heizungsraum 6 1 byte Response $01 | 0 %
35 21:41:52.286 from bus L 1.1.128 Not Found 2/2/8 Heizung 6 - Read
36 21:41:52.314 from bus L 1.1.128 Not Found 1/2/13 Eingang Wand 6 - Read
37 21:41:52.328 from bus L 1.1.128 Not Found 1/2/18 Esszimmer 6 - Read
38 21:41:52.439 from bus L 0.2.4 EG-Diele UV_EG 1/2/20 Kueche 6 1 bit Response $01
39 21:41:52.453 from bus R L 1.1.128 Not Found 1/2/18 Esszimmer 6 - Read
40 21:41:52.495 from bus L 0.2.4 EG-Diele UV_EG 1/2/21 Kueche Wand 6 1 bit Response $00
41 21:41:52.522 from bus R L 1.1.128 Not Found 1/2/18 Esszimmer 6 - Read
42 21:41:52.536 from bus L 1.1.128 Not Found 1/2/19 Esszimmer Wand 6 - Read
43 21:41:52.550 from bus L 1.1.128 Not Found 1/2/23 Terrasse 6 - Read
44 21:41:52.578 from bus L 1.1.128 Not Found 2/2/7 Garten 6 - Read
45 21:41:52.592 from bus L 1.1.128 Not Found 1/2/28 Abstellraum 6 - Read
46 21:41:52.606 from bus L 1.1.128 Not Found 2/2/6 Abstellraum 6 - Read
47 21:41:52.731 from bus L 0.2.4 EG-Diele UV_EG 1/2/24 Haustechnikraum 6 1 bit Response $00
48 21:41:52.745 from bus R L 1.1.128 Not Found 2/2/6 Abstellraum 6 - Read
49 21:41:52.787 from bus L 1.1.128 Not Found 0/3/5 Ben 6 - Read
50 21:41:52.815 from bus L 1.1.128 Not Found 1/2/5 Ben 6 - Read
51 21:41:52.829 from bus L 1.1.128 Not Found 2/2/3 Ben 6 - Read
52 21:41:52.843 from bus L 1.1.128 Not Found 0/3/3 Schlafzimmer Strasse 6 - Read
53 21:41:52.871 from bus L 1.1.128 Not Found 0/3/2 Schlafzimmer Garten 6 - Read
54 21:41:52.884 from bus L 1.1.128 Not Found 1/2/3 Schlafzimmer 6 - Read
55 21:41:52.898 from bus L 1.1.128 Not Found 2/2/1 Schlafzimmer 6 - Read
56 21:41:52.926 from bus L 1.1.128 Not Found 1/2/29 Ankleide 6 - Read
57 21:41:52.940 from bus L 1.1.128 Not Found 1/2/10 Diele 6 - Read
58 21:41:52.954 from bus L 1.1.128 Not Found 1/2/11 Diele Wand 6 - Read
59 21:41:52.968 from bus L 0.2.8 UV_OG_L 13-16 0/3/5 Ben 6 1 byte Response $02 | 1 %
60 21:41:52.982 from bus R L 1.1.128 Not Found 1/2/11 Diele Wand 6 - Read
61 21:41:53.010 from bus L 0.2.11 UV_OG_L 17-20 0/3/3 Schlafzimmer Strasse 6 1 byte Response $02 | 1 %
62 21:41:53.024 from bus R L 1.1.128 Not Found 1/2/11 Diele Wand 6 - Read
63 21:41:53.052 from bus L 0.2.11 UV_OG_L 17-20 0/3/2 Schlafzimmer Garten 6 1 byte Response $02 | 1 %
64 21:41:53.065 from bus R L 1.1.128 Not Found 1/2/11 Diele Wand 6 - Read
65 21:41:53.093 from bus L 0.2.16 UV_OG_L 1/2/5 Ben 6 1 bit Response $00
66 21:41:53.107 from bus R L 1.1.128 Not Found 1/2/11 Diele Wand 6 - Read
67 21:41:53.135 from bus L 0.2.4 EG-Diele UV_EG 1/2/13 Eingang Wand 6 1 bit Response $00
68 21:41:53.149 from bus R L 1.1.128 Not Found 1/2/11 Diele Wand 6 - Read
69 21:41:53.163 from bus L 0.2.19 UV_OG_R 2/2/3 Ben 6 1 bit Response $01
70 21:41:53.177 from bus R L 1.1.128 Not Found 1/2/11 Diele Wand 6 - Read
71 21:41:53.191 from bus L 0.2.19 UV_OG_R 2/2/1 Schlafzimmer 6 1 bit Response $01
72 21:41:53.219 from bus L 0.2.6 HV 2/2/10 Wohnzimmer Terrasse 6 1 bit Response $01
73 21:41:53.246 from bus L 0.2.4 EG-Diele UV_EG 1/2/19 Esszimmer Wand 6 1 bit Response $01
74 21:41:53.274 from bus L 0.2.16 UV_OG_L 1/2/3 Schlafzimmer 6 1 bit Response $01
75 21:41:53.302 from bus L 0.2.16 UV_OG_L 1/2/29 Ankleide 6 1 bit Response $00
76 21:41:53.316 from bus L 0.2.6 HV 1/2/27 Heizungsraum 6 1 bit Response $00
77 21:41:53.358 from bus L 0.2.6 HV 2/2/9 Heizungsraum 6 1 bit Response $01
78 21:41:53.386 from bus L 0.2.16 UV_OG_L 1/2/10 Diele 6 1 bit Response $00
79 21:41:53.400 from bus L 0.2.6 HV 2/2/8 Heizung 6 1 bit Response $01
80 21:41:53.427 from bus L 0.2.6 HV 1/2/23 Terrasse 6 1 bit Response $00
81 21:41:53.455 from bus L 0.2.6 HV 2/2/7 Garten 6 1 bit Response $01

Bin leider ein Spezialist was den knxd betrifft, aber könnte mir vielleicht einer von euch weiter helfen?
Wäre euch echt dankbar.

[henfri]

Ich weiß dass ich mich wiederhole aber die Symptome gleichen absolut dem Problem was ich oben beschrieben habe.

wenn du also sagst dass der entsprechende Parameter gesetzt ist wäre die Frage ob dieser auch beim knxd ankommt und wenn das der Fall ist ob sich im aktuellen knxd ein Bug befindet.

ich denke am besten wird dir geholfen wenn du im oben genannten Issue dein Problem schilderst.

ich würde allerdings abraten dort irgendetwas von irgendwelchen images und so weiter zu erzählen, denn du kannst nicht davon ausgehen dass sie dort bekannt sind.
gib stattdessen die genaue knxd Version an.

[drehm]

Habe mir deinen link nochmals genau anschaut in der Hoffnung etwas übersehen zu haben, leider jedoch ohne Erfolg.
Habe dann anschliessend folgendes gemacht:
1. Backup erstellt vom smarthome- und smartvisu-Verzeichnis und der /etc/knxd.conf Datei
2. wie auf folgender Seite erläutert, das smarthomeNG v1.3 image installiert: https://sourceforge.net/p/smarthomen...age/wiki/Home/
3. die beiden zuvor erstellten Backups auf dem neue installierten image wiederhergestellt
4. In der /etc/knxd.conf Datei die gleichen Parameter eingetragen wie in der zuvor erstellten knxd.conf backup Datei.
5. Den Raspberry Pi3 neu gestartet

Das Ergebnis war, dass sich all Items erfolgreich und vor allem vollständig initialisiert haben, sprich den aktuellen Wert vom Bus eingelesen haben.
In dem Image von smarthomeNG v1.3 läuft ein knxd mit der Version 0.10.0. Diese Version scheint noch einwandfrei zu funktionieren. Auf meiner ursprünglichen Installation lief eine Version 0.11.9. Diese Version scheint das Problem verursacht zu haben. Meine Vermutung ist, dass in der Version 0.11.9 der Parameter --no-tunnel-client-queuing nicht ordentlich verarbeitet wird.

Hat einer/eine von euch zufällig Connections zu den knxd Entwicklern und könnte den Bug reporten?

[wvhn]

Hast Du ja in github schon erledigt :-). Ich habe noch den Link zu diesem Thread ergänzt, wegen der guten Dokumentation des Fehlers.

[Smurf]

Bitte mal ausprobieren ob der Fehler in 0.11.9 weg ist wenn man denn --no-bla-Befehl weglässt.

[Smurf]

Hat einer/eine von euch zufällig Connections zu den knxd Entwicklern und könnte den Bug reporten?

Ich bin der aktuelle Head Honcho von knxd.

Für das Melden eines Bugs brauchst du keine Connections, sondern einfach nur einen github-Account …

[Smurf]

Zusätzlich: im aktuellen Code wurde die Verzögerung von 1sec auf 20msec geändert, weil das eigentlich reichen sollte und diverse Leute das ausprobiert hatten. Bitte mal ausprobieren ob das Problem weggeht wenn man das wieder erhöht (und ab welchem Wert es stabil läuft, 1sec ist definitiv Unfug).

Zeile 382 in src/backend/eibnettunnel.cpp

[Smurf]

Es gibt jetzt eine Testversion, die das Problem hoffentlich mit einer konfigurierbaren Verzögerung beheben sollte.

https://github.com/knxd/knxd/tree/p171

[drehm]

Habe heute mal die neue version von knxd getestet mit dem parameter --send-delay=200. Allerdings funktioniert es immer noch nicht so wie es sollte.
Das kommand das ich benutze ist folgendes:
/usr/bin/knxd -e 0.2.215 -u/tmp/eib --send-delay=200 -b ipt:192.168.1.254 -DTRS -c
Wenn ich dann in der ETS den Gruppenmonitor laufen lasse sehe ich, dass die Lese-Packete dennoch all nahezu gleichzeitig geschickt werden. In der Spalte Zeit des Gruppenmonitors steht bei fast allen LESE anfragen den gleichen Zeitstempel bis auf die Millisekunde genau.
Habe ich hier was mit der knxd config falsch gemacht? Muss der parameter an einer anderen Stelle stehen?

[Smurf]

Die Verzögerung bezieht sich nur auf die Pakete, die an die 192.168.1.254 geschickt werden. DIe Multicastdaten, die das ETS auf dem Ethernet sieht, sind davon nicht betroffen.
Starte wireshark (oder tcpdump) auf dem sendenden Rechner und beobachte den Traffic an den KNX-Gateway direkt.

[arnix]

Hallo zusammen,

ich hätte gerne die neue Variante des knxd, bei der nur noch 20 ms Verzögerung parametriert ist. Ich weiß, die Frage ist peinlich, aber wie kann ich das Update von Github auf meinen Raspi bringen?
Ich habe natürlich schon versucht, mich in Github einzulesen und vermutlich muss ich in einem Verzeichnis meines Raspis "git pull" eingeben. Aber mein Problem ist, ich finde das entsprechende Verzeichnis des knxd nicht auf meinem Raspi.

Ich habe einen Raspi 2 mit Debian 8 und habe SmarthomeNG und auch den knxd nach folgender Anleitung installiert:

https://github.com/smarthomeNG/smart...plettanleitung

Ich habe das Weinzierl KNX IP Interface 730 und habe in der Config "--no-tunnel-client-queuing". Es funktioniert auch alles, nur die Verzögerungen bei Massenschaltungen sind für meinen Geschmack einfach etwas zu lange, daher mein Wunsch, auf die kürzere Pausenzeit zu wechseln.

Könnte mir irgendwer den Gefallen tun und kurz für Doofies erklären, wie ich den knxd updaten kann?

Würde mir weitere nutzlose Stunden mit Google sparen.

Danke und Grüße

Arne

[henfri]

Auf github findest du nur an den Quellcode.
den musst du kompilieren. kannst du das?

[arnix]

Soll ich es nochmal so machen, wie es in der Anleitung steht? Also kann ich das einfach über die bestehende Installation drüber schreiben?

https://github.com/smarthomeNG/smart...plettanleitung