Connectionstate_response

[Smurf]

Um festzustellen, wer "schuld" ist, konfiguriere man einen Mirror-Port auf dem hoffentlich gemanagten Switch, starte Wireshark, und beobachte was konkret passiert. Sich zu streiten, wenn wir nicht mal wissen ob dieses Log ein- oder ausgehende Statuspakete und-oder -antworten zeigt, ist müßig.

makki ein tpuart1 ist leider auch keine saubere Lösung – weil er die Empfangsbestätigung derart schnell erwartet, dass doppelte Pakete trotz eines 100% sauberen Busses alles Andere als selten sind. Der tpuart-Treiber des knxd filtert empfangene Duplikate nicht aus Versehen raus.

[MiCon]

Die serielle Schnittstelle zum KNX-Bus hängt ja am Wiregate und läuft auch sauber (soweit ich es sehe..). Ich kann über IP auch problemlos mit der ETS programmieren und der Homeserver 3 und auch das Wiregate mucken seit Jahren kein bisschen. Der ioBroker ist ja "nur" nachgelagert und soll die Verbindung zu anderen "Smartgeräten" wie Miele@home, harmony, openwb, solaredge WR, Alexa und homekit herstellen. Für diese Anforderung ist mir kein zertifiziertes Gateway bekannt. IOBroker kann die alle unter einem Hut bringen.. Bringt nur leider nicht so viel, wenn KNX nicht sauber implementiert ist...

[makki]

Smurf es geht ja nicht um die Schuldfrage, das war mir schon immer eher "wurscht" ich habe damals wirklich Wochen und Monate damit verbracht den eibd "auf Spur zu bekommen" und das ganze sauber mkoegler zu berichten, der es dankenswerterweise dann auch immer behoben hat (dabei hab ich so halbwegs C++ gelernt) - trotz widerlicher, aber zertifizierter SS wie die alten USB, FT1.2 für die im eibd/knxd alleine ca. 10 schmutzige "Workarounds" sind die sicher heute keiner mehr versteht. Mangels Historie dazu, siehe ML..
Was ich dazu nur beitragen wollte: das passt schon so wie es ist, wenns nichts funktioniert, ist der Fehler erstmal nicht beim eibd zu suchen, dafür habe ich den viel zu lange mit Oszi, LogicAnalyzer in der linken Hand und dem KNX-Standard in rechten Hand angeschaut, übrigens auch an dem WireShark-Plugin für KNXNET/IP mitgeschrieben (hats glaube ich leider nie wirklich US geschafft..) das sagt dir auch genau, wenn das Timing ned stimmt

Beim TP-UART bin ich nicht ganz bei dir, der ist Timing-kritisch, ja, weil der KNX halt nunmal Timing-kritisch ist aber dafür auch sehr "ehrlich", bei den anderen SS haste keine Chance darauf Einfluss zu nehmen - und kann alles inkl. ACKen "lokal" aufm ATMega/Tiny (wie das auf nem Bastel-Raspi mit emuliertem RS232 aussieht weiss ich ned..aber auf nem uralten 500MHz AMD [WG] mit ner echten 16550A geht das wunderbar vollgasfest mit 50 tps 72h lang im Dauertest ohne einen einzigen Telegrammverlust! da saufen vorher so manch zertifizierte Geräte am KNX derbe ab.. ohne jetzt Namen zu nennen..)
Also ich habe in 14J KNX so einiges gelernt und auch meine Meinung teils revidiert, aber als SS würde ich immer wieder NUR ein TP-UART nehmen!
Und es ist bestimmt nicht das erste KNX-Interface auf ner Segelyacht aber mein erstes auf der Blue Horizon, ich sitze gerade im Cockpit, was soll ich sagen: es funktioniert

MiCon dann musst du den Fehler aber halt am Client ioBroker suchen bzw. dort berichten, wir sind uns ja einig, ich könnte dir auch den eibd 0.0.4.18+ fürs WG bauen - finde es nur den falschen Lösungsansatz das mit einem Quirk durch fummeln an Timeouts vermeintlich zu "lösen"
Edit: Denn es löst nicht wirklich das Problem oder die Ursache..

Makki

[MiCon]

Und es ist bestimmt nicht das erste KNX-Interface auf ner Segelyacht aber mein erstes auf der Blue Horizon, ich sitze gerade im Cockpit, was soll ich sagen: es funktioniert

Jetzt bin ich Neidisch.... Ich muss hier im Büro hocken und mein Bötchen dümpelt alleine vor sich im Hafen hin....

MiCon dann musst du den Fehler aber halt am Client ioBroker suchen bzw. dort berichten, wir sind uns ja einig

Da stimme ich Dir voll und ganz zu, deswegen hatte ich das ja auch schon bei Github gepostet. Mittlerweile habe ich gehört, dass der Fehler auch schon früher einmal gemeldet und vermutlich behoben wurde. Ich habe jetzt probehalber dort mal eine recht alte Version des Adapters (1.20) installiert und was soll ich sagen, kein Fehler mehr seit gut einer Stunde. Vielleicht reagiert ja der Entwickler des Adapters, ansonsten versuche ich es vielleicht mal mit Node Red. Ist zwar auch nicht zertifiziert, soll aber gut laufen und alle von mir benötigten Schnittstellen mitbringen.

[MiCon]

Ich habe zur Sicherheit mittlerweile mal den Netzwerkverkehr mitgeschnitten und mit Wireshark analysiert. Der Mitschnitt erfolgte direkt auf dem ioBroker Server, welcher mittlerweile auf einem Intel Nuc direkt unter Debian installiert ist. Hier einmal ein Auszug der Pakete bezüglich des Connection-State Hearbeats:

Time	Source	Destination	Protocol	Length	Info
551.491.776.345	192.168.178.175	192.168.178.32	KNXnet/IP	58	ConnStateReq #01 @0.0.0.0:38412
551.493.275.824	192.168.178.32	192.168.178.175	KNXnet/IP	60	ConnStateResp #01 OK
564.545.971.213	192.168.178.175	192.168.178.32	KNXnet/IP	58	ConnStateReq #01 @0.0.0.0:38412
564.547.539.471	192.168.178.32	192.168.178.175	KNXnet/IP	60	ConnStateResp #01 OK
690.394.474.049	192.168.178.175	192.168.178.32	KNXnet/IP	58	ConnStateReq #01 @0.0.0.0:38412
690.396.013.425	192.168.178.32	192.168.178.175	KNXnet/IP	60	ConnStateResp #01 Error 0x15

192.168.178.175 ist mein ioBroker und 192.168.178.32 mein Wiregate. Damit ist in meinen Augen klar, dass der Heartbeat vom Adapter in ioBroker nicht regelmäßig genug gesendet wird.

Mittlerweile habe ich auch die verschiedenen Versionen des Adapters getestet und festgestellt, dass es seit Version 1.0.35 vom 15.09.2019 nicht mehr richtig funktioniert. Bei Wiregate tauchte der Fehler auch bereits 2019 auf. Man ist dort allerdings davon ausgegangen, dass der Fehler seitdem bereits behoben wurde. Dies ist wohl leider nicht passiert.

@smurf: Hast Du über die Möglichkeit, den Timeout zu konfigurieren noch einmal nachgedacht?

Liebe Grüße

Michael

[MiCon]

Ich habe jetzt knxd im Source-Code angepasst und den Timeout auf 240 Sekunden verdoppelt. Jetzt läuft alles.. Vom Programmierer des Adapters habe ich noch keine positive Rückmeldung bekommen. Man glaubt scheinbar nicht wirklich an einen Fehler bei sich und meint, ich sollte mir eine ordentliche Schnittstelle kaufen, dann würde es auch laufen... Das lass ich jetzt mal unkommentiert...

Vielen Dank auf jeden Fall für die sehr hilfreichen Hinweise hier im Forum!

Liebe Grüße

Michael

[Smurf]

Die aktuelle Version hat einen konfigurierbaren Timeout.

[MiCon]

Die aktuelle Version hat einen konfigurierbaren Timeout.

Das hatte ich gar nicht gesehen. Ich hatte den Branch „Debian“ verwendet, dort war der Timeout noch fest. Bei welcher Version kann man das denn einstellen und wie und wo?

[Smurf]

Sorry, war noch unvollständig. Habe die aktuelle Version gepusht und auf debian gemergt. 0.14.51.