Beim Start: Wartezeit zwischen Read Anfragen, Buslast zu hoch bei sehr vielen Geräten

[1vnt]

Normalerweise liegt die Buslast im ETS5 busmonitor bei ca. 9-20%, sobald hkknx gestartet wird und anfängt alle GAs abzufragen liegt diese bei 130% und höher, vieles wird als gelb markiert.

Gut wäre, wenn man die gesendeten Telegramme pro Sekunde festlegen, oder auch eine kleine Wartezeit zwischen den reads angeben könnte.

[brutella]

Du hast Recht, beim starten von hkknx werden die Geräte initialisiert und die dazugehörigen Gruppenadresse so schnell wie möglich abgefragt.

Falls eine Wartezeit zwischen zwei aufeinanderfolgenden Abfragen eingeführt wird, dauert das Initialisieren der Geräte länger - daher gab es bis jetzt auch keine Wartezeit.

Wie lange sollte hkknx deiner Meinung nach zwischen zwei Abfragen warten?

[hr-automation]

Anmerkung meinerseits - Könnte man anstatt einer allgemeinen Änderung, diese Zeit evtl. selbst definieren?

[mirkolenz]

Vielleicht sollte man eine maximale Anzahl von Abfragen pro Sekunde einstellen können? Das könnte man auch global einstellen und somit alle KNX-Telegramme in einen Puffer bzw. eine Queue schreiben. Diese Warteschlange hätte den Vorteil dass bei wenigen Telegrammen (ca. 20 oder weniger) alles sofort ausgeführt wird, während größere Vorgänge entsprechend gepuffert wären. Es gibt auch bei manchen KNX IP Interfaces einen solchen Puffer, der maximal 150 Telegramme zwischenspeichert und je nach Buslast sendet. Aber diese Funktion haben leider nicht alle Interfaces.

[brutella]

Ich würde eine generelle Lösung des Problems bevorzugen, ohne eine Option extra dafür zu machen. Vielleicht könnte hkknx Anhang der Buslast eine variable Wartezeit verwenden.

Gibt es eine gute Möglichkeit die Buslast festzustellen?

[hr-automation]

Hallo @brutella Deine Idee finde ich sehr gut.

Mir ist aber leider kein Weg bekannt, die Buslast ohne ETS und kompatiblen IP Interface auszulesen. Generell verwende ich ein USB Interface damit der Busmonitor überhaupt in der ETS funktioniert.

Würde mich freuen, ob hier jemand eine andere Lösung des "Problems" hat?

PS: Geteilt im KNX-U-F (https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/1797345-buslast-auslesen-und-weiterverwerten), damit vllt. mehr Leute helfen können. LG

[1vnt]

Eventuell wäre eine Option passend für die gesendeten Telegramme in der Sekunde, hier könnte man die funktion ja auch ausschalten, wenn man sie nicht benötigt. Auch das Probieren von verschiedenen Optionen wäre damit möglich um eine geeignete Einstellung zu finden.

[mirkolenz]

Eventuell wäre eine Option passend für die gesendeten Telegramme in der Sekunde, hier könnte man die funktion ja auch ausschalten, wenn man sie nicht benötigt.

Das ist auch das, was ich in meinem vorigen Post vorschlagen wollte. Vielleicht war es etwas umständlich formuliert, aber ich denke auch, dass es eine gute Lösung für das Problem darstellt.

In der KNX-Integration bei Home Assistant wird es im Übrigen genauso gehandhabt (dort heißt es dann Rate Limit:

[getcom]

Man könnte auch den group cache von knxd bemühen (/usr/lib/knxd/groupcacheread), dann wäre die Buslast gleich null und die Abfragezeit wäre auf ein Minimum verkürzt. Nur für den Fall, dass groupcacheread keine Antwort liefert, kann man die entsprechende Busadresse direkt abfragen. Dieser Fall wäre aber seltsam. Diese direkten Abfragen würde ich via Rate limit parametrisieren, wie von @mirkolenz vorgeschlagen. Ob der knxd verfügbar ist, kann man abfragen und wenn ja, dann soll er dessen Cache verwenden, wenn nicht, dann direkt, bzw. nur dann, wenn der Status unbekannt ist. In meinen eigengestrickten Logiken hatte ich am Anfang auch direkt abgefragt. Ab einer gewissen Komplexität hatte ich dann den Bus in die Knie gezwungen, Seitdem ich den knxd cache verwende ist himmlische Ruhe.

[brutella]

Man könnte auch den group cache von knxd bemühen (/usr/lib/knxd/groupcacheread).

knxd wird von hkknx nicht verwendet.

[1vnt]

knxd wird von hkknx nicht verwendet.

Dazu wurde etwas erwähnt.

Ob der knxd verfügbar ist, kann man abfragen und wenn ja, dann soll er dessen Cache verwenden, wenn nicht, dann direkt, bzw. nur dann, wenn der Status unbekannt ist.

Wäre es möglich, relativ bald einen Telegrammratenbegrenzer zu implementieren, da es sehr stört wenn einige Geräte nach dem Start nicht den korrekten Status gekriegt haben?

[getcom]

Man könnte auch den group cache von knxd bemühen (/usr/lib/knxd/groupcacheread).

knxd wird von hkknx nicht verwendet.

Ich weiß, dass hkknx den knxd nicht benötigt, aber wenn er sowieso vorhanden ist könnte man dessen Cache abfragen. Das funktioniert natürlich nicht bei einem kompletten Systemstart, da dann auch der Cache leer ist. Zumindest wäre das im laufenden Betrieb beim Neustart von hkknx eine einfache Lastreduzierung vom Bus. In meinem Fall läuft er eben sowieso auf dem RPi mit. Den Cache abzufragen kostet nichts.

Ohne Telegrammratenbegrenzung in einer Anlage mit 7 Linien, wovon zwei auch noch Linienverstärker haben, fährt der hkknx den Bus aktuell gegen die Wand. Das Problem dabei ist, dass dann evtl. wichtige Telegramme nicht durch kommen. Im Normalzustand liegt die Buslast im einstelligen Bereich, gelegentlich geringfügig höher. Sobald der hkknx neu startet, ist in der Anlage die Hölle los. Neulich musste ich die KNX IP-Router von zwei Linien neu starten, weil sich das nicht mehr beruhigt hatte und die Buslast bei 157% (!) lag. Dort sind u.a. 19 RTRs und 28 Gira Stellantriebe im Einsatz. Die RTRs haben die Rückmeldungen nicht mehr quitiert bekommen und haben den Bus damit lahm gelegt. Da bei einer Integration der hkknx aber nun öfter neu gestartet werden muss, ist das aktuell jedes Mal ein Fackelzug. In kleinen Anlagen mag das unauffällig sein, in größeren jedoch ist das Starten des hkknx in der jetzigen Ausprägung wie eine DoS-Attacke.

[getcom]

Ich würde eine generelle Lösung des Problems bevorzugen, ohne eine Option extra dafür zu machen. Vielleicht könnte hkknx Anhang der Buslast eine variable Wartezeit verwenden.

Gibt es eine gute Möglichkeit die Buslast festzustellen?

Geht nur über Protokoll-Auswertung. Eigentlich müsstest du nur das Bit 0-3 vom 5. DRL-Byte auswerten, um die Länge des Datenanteils im Frame zu kennen. Dann zählst du die Frames pro Sekunde mit ihrer jeweiligen Länge und bestimmst dadurch die Datenrate je Sekunde. TP1 hat 9600 Bit/s, womit du dann die Buslast berechnen können solltest. Sollte eigentlich nicht so schwer sein. Das setzt aber voraus, dass das Medium bekannt ist (TP/PL/RF). In gemischten Umgebungen wird das sicher anstrengender.

Die aktuelle Buslast-Berechnung müsste jedoch nach jeder Abfrage erneut erfolgen, d.h. hkknx müsste erst abwarten, was genau eine entsprechende Abfrage bewirkt und dann entscheiden, wie lange die Zeit für die nächste Abfrage sein soll. Die nächste Reaktion könnte aber wieder komplett anders aussehen. Das müsste deshalb dann so laufen: aktuelle Buslast berechnen, Read-Requests absenden, Buslast beobachten, bis wieder ungefähr die ursprüngliche Buslast eingetreten ist, dann nächste GA abfragen, bis der zuletzt errechnete Wert erreicht ist, usw.

Eine einstellbares Rate-Limit ist unter dem Strich wohl einfacher und vor allen Dingen schneller implementiert.

[farmio]

Wie lange sollte hkknx deiner Meinung nach zwischen zwei Abfragen warten?

20 ms. Oder 5 ms aber jedenfalls max. 50 Telegramme pro Sekunde. Bei Routing zumindest.

[getcom]

Wie lange sollte hkknx deiner Meinung nach zwischen zwei Abfragen warten?

20 ms. Oder 5 ms aber jedenfalls max. 50 Telegramme pro Sekunde. Bei Routing zumindest.

Das gilt für den kompletten Bus und höchstens für writes, aber nicht für reads. Status-GAs abfragen hat immer eine Rückmeldung zur Folge und Geräte senden bei Werteänderung von sich aus Telegramme. Das muss berücksichtigt werden.

[getcom]

Es gibt eine Antwort aus dem knx-user-forum, die berechtigt ist: https://knx-user-forum.de/forum/%C3%B6ffentlicher-bereich/knx-eib-forum/1797345-buslast-auslesen-und-weiterverwerten?p=1800594#post1800594 Du siehst neben diesem Einwand unter Umständen nicht die komplette Buslast, wenn Linienteilnehmer sich z.B. nur auf ihrer Linie unterhalten ohne über den KNX IP-Router zu gehen. Das ist auf jeden Fall so auch bei erweiterten Linien, die mit Linienverstärker arbeiten und gerade nicht über das Backbone kommunizieren.

[brutella]

In Version 2.4.2-b1 gibt es ein fixes Limit von 50 Telegramme pro Sekunde. Bitte austesten und Feedback geben. Danke.

[getcom]

Die Buslast stieg beim starten vom hkknx service von 13% auf 125% an. Das Verhalten hat sich somit in der neuen Version kaum verbessert. Nachdem die Buslast wieder unten war habe ich die Home App gestartet. Ergebnis: es fehlen Werte von verschiedenen RTRs und von Rolladenaktoren. Dimmer und Schaltaktorenzustände habe ich nicht gecheckt, da ich durch die Räume hätte laufen müssen. Es sind auch immer mal andere, die fehlen. Wie bereits erwähnt, sind 50 Telegramme/Sekunde viel zu viel. Selbst 25/Sekunde sind unrealistisch. 10 würde ich einstellen, wenn es die Möglichkeit gäbe. Konfigurierbar wäre schon besser aus meiner Sicht und wenn es als Parameter beim Start übergeben werden könnte. Neue Idee: mach es komplett anders: Lausche auf dem Bus, bis 10ms lang (oder länger) kein Telegramm vorbei kam, dann sende ein Statusabfrage-Telegramm und warte auf die Rückmeldung bis zu einem konfigurierten oder besser konfigurierbaren timeout, dann wiederhole das, bis alle Adressen durch sind. Anschließend durchläufst du noch mal eine Schleife mit den Adressen, die durch den timeout raus gefallen sind. Die, die immer noch nicht antworten, schreibst du in ein Logfile raus, Damit bist du dynamisch unterwegs, das heißt, selbst wenn gerade viel los ist, entgeht dir normal dennoch nichts und du brauchst keine Berechnung oder statische Werte, an die man sich heran tasten muss. Das Logfile kann man dann als User lesen und ggfls. checken, ob da noch Leseflags nicht gesetzt sind. Fertig ist der Lack.

[1vnt]

@brutella Eventuell eine Rückmeldung dazu?

[hr-automation]

Beta ebenfalls nicht zu gebrauchen - wieder zurück zu 2.4.1

[brutella]

In 2.4.2-b2 ist die Datenrate jetzt auf 10 Telegramme pro Sekunde limitiert.

[1vnt]

Wieso nicht einfach eine Option zum Einstellen der Begrenzung, sollte nicht schwer sein das zu implementieren?

[1vnt]

Viel gebracht hat es trotzdem nicht, nach einer kurzen Zeit fängt alles an zu antworten (das heißt, die Geräte), und es schießt wieder über die 100% (ca. 130% wird benutzt)

[getcom]

Viel gebracht hat es trotzdem nicht, nach einer kurzen Zeit fängt alles an zu antworten (das heißt, die Geräte), und es schießt wieder über die 100% (ca. 130% wird benutzt)

Das Verhalten kann ich bestätigen.

Eine Einstellrate, wie im Post eins weiter oben beschrieben, wäre auch nur eine Momentaufnahme, die nicht immer zutreffend sein wird. Meine Vorstellung, wie das funktionieren kann, habe ich weiter oben geschrieben (=>Neue Idee). Ich glaube, dass der Gira Homeserver das genau so macht, wenn ich das richtig beobachtet habe. Der Homeserver braucht dafür eben auch mal 10, 15 Minuten, bis er oben ist. Das ist aber sicherer, als wichtige Telegramme zu verlieren.

[mbrockeu]

Wie verhält es sich den eigentlich mit Timeouts nach einem Neustart?

Da ich aktuell noch am Testen bin und meine laufende KNX Installation nur aus dem nötigsten besteht sind viele Aktoren nicht angeschlossen, aber bereits in HKKNX definiert.

Wenn ich jetzt etwas ändere dauert es extrem lange bis die Bridge wieder da ist. Selbst wenn nur eine GA geändert wird und nicht die Geräte selbst.

Das die Geräte ggfs. nicht da sind nach einem Start wäre für mich zumindest ok, aber die Bridge selbst ist ja auch nicht da und man weiß nicht mal, ob das Ding läuft oder nicht.

[1vnt]

@brutella Gibt es mittlerweile ein Update hirzu?

Zu dem Problem von @mbrockeu : Es ist bestimmt eine einfache Änderung nur die GA von einem Gerät zu ändern, das sollte leicht implementierbar sein.

[getcom]

@brutella Es gibt derzeit ein offenes Ticket bei der technischen Alternative zum CAN-BC2 KNX-Modul: TA#6426558. Dieses KNX-Hardware-Modul hängt sich beim Start vom hkknx daemon regelmäßig auf, was sich so äußert, dass es weder Werte sendet, noch empfängt.

Zuerst dachte ich, dass das ein unabhängiges Problem sei, jedoch konnte ich mittlerweile beobachten, dass der Modul-Freeze mit dem Start von hkknx zusammen fällt. Sobald die Buslast über 120-130% läuft, hängt sich das KNX-Modul auf und lässt sich nur durch einen Hardware-Reset davon erlösen. Es verhält sich so, dass bei einem Freeze sowohl die Werte vom KNX-Bus kommend, als auch gehend zum Stillstand kommen. Das CAN-BC2 hat CAN-intern jedoch noch aktuelle Werte, daher konnte ich das auf das KNX-Modul runter brechen. Die Entwickler des Moduls konnten das über Firmnware-Upgrades bisher nicht verbessern, bzw. können in der jetzigen Hardware-Revision schlicht und einfach den Buffer nicht vergrößern.

Über einen Telegramm-Loop konnte ich den Freeze ganz einfach provozieren. Tatsächlich steigt eine Hardware-Firmware durch einen Telegramm-Overload aus. Hier kommen sicherlich zwei Probleme zusammen, dennoch ist für dieses spezielle Problem als indirekter Verursacher hkknx sehr wahrscheinlich.

Um das Problem zu umschiffen, habe ich einen Watchdog geschrieben, der das CAN-BC2-Modul neu startet, sobald n festgelegte Gruppenadressen seit der bestimmten Zeit t keine Updates mehr erhalten. Lieber wäre es mir jedoch, wenn stattdessen beim Start von hkknx die Buslast im grünen Bereich bleibt. Gibt es eine Chance, dass für dieses Problem die Prio etwas nach oben wandert?

[hr-automation]

Hallo @brutella

Ich wiederhole meinen Wunsch, dass es jedem selbst überlassen ist, welche Wartezeit man wählt.

Bin gerade am testen der 2.4.2b6 - und es tut sich einfach nach 15 Minuten noch immer nichts, außer das die Brücke noch immer initialisiert wird.

Log-Files welche ich hierzu bereit stellen kann?

EDIT: Benutze noch immer das Linux .IMG der Version 1.3. (alle Aktualisierungen für Buster durchgeführt) Letzte funktionierende Version (bei mir): 2.4.2b1

[getcom]

@brutella Was ich aus den bisherigen Antworten heraus höre, zusammen mit den eigenen Erfahrungen, gibt es zwei gegensätzliche Meinungen zu diesem Thema und eine umfangreiche Faktenlage. Ich versuche das mal zusammen zu fassen, damit man hier auf einen gemeinsamen Nenner kommt.

• hkknx, bzw. die Bridge sollte so schnell wie möglich nach Neustart zur Verfügung stehen
• Ein Abfragen sämtlicher Gruppenadressen in zu kleinem Zeitrahmen hat eine hohe Buslast zur Folge, die a) zu verlorenen Telegrammen führen kann, b) zu Telegramm-Wiederholungen führen kann, c) dazu führen kann, dass KNX-Hardware aussteigt wegen buffer overload.
• Im Idealfall sollte hkknx lediglich nur neue Gruppenadressen abfragen und den Bus dabei nicht fluten.
• Eine Berechnung der maximal mögliche Buslast und damit eine dynamische Abfragegeschwindigkeit ist nicht verlässlich möglich, da erweiterte Linien vorhanden sein könnten und insgesamt das Telegramm-Peak-Aufkommen anderer Teilnehmer, wie L1, X1, Homeserver, TA CAN-BC2 mit KNX-Modul, EibPC, diverse DMX-, DALI- und andere Gateways, beim Start von hkknx nicht bekannt sind.
• Das Buslast-Problem steigt mit der Anzahl der Linien & Teilnehmer exponentiell an, auch wenn Teilnehmer-Paare, die i.d.R. sich oft mit sich selbst unterhalten (z.B. RTRs <=> Stellantriebe), sich in einer Linie befinden. Im Beispiel einer Anlage mit 8 Linien und bis zu 128 Teilnehmer auf einer Linie ist der Start von hkknx in der aktuellen Ausprägung auch in der letzten B-Version eine DoS-Attacke, wenn mehrere Instanzen je max 150 Teilnehmer benötigt werden.

Vermutlich ist das nur über mehrere Einzelmaßnahmen anzugehen und das könnte man auslagern.

@brutella Nachdem es hier recht ruhig geworden ist, frage ich mich gerade, wie die Zukunft von hkknx aussieht? Wäre es nicht vielleicht sinnvoll, das modular aufzuteilen und die KNX-Gruppenadressen-Kommunikation einem hkknxd-Modul zu überlassen, das Open Source ist während die eigentliche Bridge in deiner Obhut bleibt? Das hkknxd Modul könnte das Bindeglied zwischen mehreren hkknx Instanzen sein und sich um die Kommunikation in Richtung KNX kümmert. Der Vorteil wäre, dass die Bridge quasi nach Neustart ad hoc verfügbar wäre und alle im hkknxd cache vorhandenen Werte sofort ausliefert und neue Werte dann zuerst mit einem Null-Wert und sofort nach Verfügbarkeit nachliefert. Wäre so eine Konstellation denkbar? Du kannst dich dann auf hkknx konzentrieren und bräuchtest dich mit Kommunikationsproblemen nicht mehr belasten, wenn eh kaum Zeit für Weiterentwicklung ist. Was meinst du dazu?

[brutella]

Danke für deine Zusammenfassung. Ich kann dir nur zustimmen, dass sich das Problem mit dem Abfrage-Limit universell kaum lösen lässt.

Die Idee mit einem Cache finde ich ganz interessant. Aber die ganze KNX Kommunikation in ein eigenes Modul (hkknxd?) auszulagern, möchte ich nicht. Damit fängt man sich nur weitere Probleme ein. Es gibt schon gute Gründe, warum alles in einem Binary gebundelt ist.

Ich habe mal Testweise in Version 2.4.2-b7 einen Cache eingebaut. Somit sollte die Brücke nach einem Neustart viel schneller in HomeKit zur Verfügung stehen. Solange die Verbindung zum KNX Gateway besteht, wird der Cache verwendet. Wird die Verbindung zum KNX Gateway getrennt (zB KNX Secure wird aktiviert, oder die IP Adresse ändert sich), wird der Cache auch gelöscht. Ein erneutes Initialisieren bleibt einem dann leider nicht erspart.

Mal sehen, ob sich damit das Problem etwas entschärfen lässt.

[mirkolenz]

Das ist wie ich finde ein sehr eleganter Ansatz. Problematisch wird es nur, wenn HKKNX längere Zeit offline war (bspw. durch einen Server-Defekt). Für solche Fälle wäre es dann gut, einen Sync-Button irgendwo zu haben.

[brutella]

Wenn hkknx neu gestartet wird und eine neue Verbindung zu dem KNX Gateway aufbaut, ist auch der Cache leer und wird beim Initialisieren wieder "befüllt". Sollte also kein Problem sein.

[hr-automation]

2023-01-17_13:10:44.68524 2023/01/17 14:10:44 disconnect: write udp4 192.168.1.210:35011->192.168.1.201:3671: use of closed network connection 2023-01-17_13:10:44.93548 INFO 2023/01/17 14:10:44 main.go:194: app: stop 2023-01-17_13:10:44.93556 INFO 2023/01/17 14:10:44 main.go:227: good bye ;) 2023-01-17_13:10:44.98850 INFO 2023/01/17 14:10:44 main.go:79: version 2.4.2-b7 (built at 2023-01-17T13:46:12Z+0100) 2023-01-17_13:10:45.14614 INFO 2023/01/17 14:10:45 main.go:221: webpage available at port 8080 2023-01-17_13:10:45.14763 INFO 2023/01/17 14:10:45 app.go:335: tunnel: connected to 192.168.1.201:3671 via 1.1.197 2023-01-17_13:10:45.28898 2023/01/17 14:10:45 rate limitting (sleeping 949.275551ms) 2023-01-17_13:10:45.28919 2023/01/17 14:10:45 rate limitting (sleeping 948.999723ms) 2023-01-17_13:10:46.23878 2023/01/17 14:10:46 discarding message with sequence number 3 (expected 4) 2023-01-17_13:10:46.30159 2023/01/17 14:10:46 rate limitting (sleeping 977.978754ms) 2023-01-17_13:10:56.24043 INFO 2023/01/17 14:10:56 io.go:21: read 1/2/45: group read: timeout 2023-01-17_13:10:56.28757 INFO 2023/01/17 14:10:56 tunnel.go:68: tunnel: using cached value [0] from 1/2/47 2023-01-17_13:10:56.30952 2023/01/17 14:10:56 rate limitting (sleeping 978.348433ms) 2023-01-17_13:11:06.28907 INFO 2023/01/17 14:11:06 io.go:21: read 1/2/65: group read: timeout

Das ist das letztgültige Log File nach Aktualisierung auf b7 und Brücke initialisiert immer noch...

Gibt es hierzu eine Idee @brutella ?

EDIT: Kannst Du mir evtl. einmal eine Version mit 50 kompilieren und zukommen lassen?

[brutella]

@hr-automation Sind deine Gruppenadressen 1/2/45 und 1/2/65 lesbar?

[mirkolenz]

Wenn hkknx neu gestartet wird und eine neue Verbindung zu dem KNX Gateway aufbaut, ist auch der Cache leer und wird beim Initialisieren wieder "befüllt". Sollte also kein Problem sein.

Ah, verstehe. Wobei die Funktion dann bei mir nur einen kleinen Effekt hat. Denn insbesondere bei einem Neustart des Servers oder des Containers tritt das Problem der hohen Buslast dann noch immer auf. Aber es ist schonmal ein guter erster Schritt, wenn im laufenden Betrieb nicht mehr abgefragt wird, nur weil sich die Konfiguration ändert 😄

[hr-automation]

@hr-automation Sind deine Gruppenadressen 1/2/45 und 1/2/65 lesbar?

War zwar nie ein Problem bis dato, aber habe mal den Gruppenadressen die Flag "Lesbar" hinzugemacht.

ABER: Es bleibt beim Initialiseren :-)

2023-01-17_13:53:44.35144 2023/01/17 14:53:44 rate limitting (sleeping 979.851787ms) 2023-01-17_13:53:45.33178 2023/01/17 14:53:45 discarding message with sequence number 40 (expected 41) 2023-01-17_13:57:42.92400 INFO 2023/01/17 14:57:42 main.go:79: version 2.4.2-b7 (built at 2023-01-17T13:46:12Z+0100) 2023-01-17_13:57:43.08336 INFO 2023/01/17 14:57:43 main.go:221: webpage available at port 8080 2023-01-17_13:57:43.08629 INFO 2023/01/17 14:57:43 app.go:335: tunnel: connected to 192.168.1.201:3671 via 1.1.197 2023-01-17_13:57:43.22782 2023/01/17 14:57:43 rate limitting (sleeping 949.227899ms) 2023-01-17_13:57:43.22810 2023/01/17 14:57:43 rate limitting (sleeping 948.879387ms) 2023-01-17_13:57:44.17799 2023/01/17 14:57:44 discarding message with sequence number 3 (expected 4) 2023-01-17_13:57:44.22384 2023/01/17 14:57:44 rate limitting (sleeping 975.661125ms) 2023-01-17_13:57:45.20030 2023/01/17 14:57:45 discarding message with sequence number 6 (expected 7) 2023-01-17_13:57:45.20240 2023/01/17 14:57:45 rate limitting (sleeping 999.261087ms) 2023-01-17_13:57:46.20231 2023/01/17 14:57:46 discarding message with sequence number 10 (expected 11) 2023-01-17_13:57:46.20295 INFO 2023/01/17 14:57:46 tunnel.go:68: tunnel: using cached value [0] from 1/2/47 2023-01-17_13:57:46.30422 2023/01/17 14:57:46 Unexpected inbound message of type *knxnet.TunnelRes 2023-01-17_13:57:46.30436 2023/01/17 14:57:46 rate limitting (sleeping 898.384207ms)

Ich frage mich, was sich seit b1 dahingehend (außer das Limit) geändert hat, dass es nicht mehr funktioniert...

[brutella]

@hr-automation Sehe hier keine Fehler. Die Meldung discarding message with sequence number xx (expected xx) sollte zu keinen Problemen führen. Mit dem nächsten Update werden diese Meldungen verschwinden.

[hr-automation]

Das ist echt komisch... Würde es helfen, wenn ich Dir einmal ein Backup zukommen lasse? Oder das gesamte Raspberry PI Image?

[mbrockeu]

@brutella kann man den initialisieren-statu der Bridge noch etwas aufbohren im Sinne von y von x Geräten? oder ggfs. auch im Log das ausgeben?

Bei mir gehts manchmal schnell, mal langsam, oder gar nicht mehr. So sieht man wenigstens ob noch was passiert.

[brutella]

@mbrockeu Ein Initialisierungsstatus wird jetzt in 2.4.2-b9 angezeigt.

[mbrockeu]

@mbrockeu Ein Initialisierungsstatus wird jetzt in 2.4.2-b9 angezeigt.

Traumhaft danke!!

[mirkolenz]

Ich habe gerade auf Beta 9 aktualisiert, nun verbindet sich hkknx weder mit dem IP Interface not mit HomeKit. Habe dann auf Beta 8 downgegraded, ging auch nicht. Erst mit 2.4.1 geht es wieder auf Anhieb. Bei mir läuft das ganze in Docker mittels macvlan, falls das noch relevant ist.

[brutella]

Hattest du mal den Status von KNX und HomeKit unter Status beobachtet?

[mirkolenz]

Du meinst hier?

Dort stand bei den Betas bei den oberen beiden Punkten nicht verbunden bzw. nicht verfügbar.

[brutella]

@hr-automation Dein Problem mit dem Initialisieren sollte mit 2.5.0-b1 behoben sein.

[hr-automation]

Danke @brutella !! Ich kann bestätigen, dass hiermit eine Initialisierung ermöglicht und alles reibungsfrei läuft!

Danke nochmals für die Behebung des Fehlers

[mirkolenz]

@brutella Wie in #200 berichtet, hatte ich das gleiche Problem bei der letzten Beta auch. Habe nun Version 2.5.0-b1 installiert und gleiches Problem (siehe Screenshot). Habe auch den Container mehrere Male neu gestartet, aber es hatte keinen Effekt. Bin nun wieder bei 2.4.1.

[Graefer]

Die Begrenzung der Telegramme auf 5/sek. ist ja sehr irritierend - und könnte dann für das finale Release wieder entfernt werden, oder?

[brutella]

Diese Begrenzung wird nur dann angewendet, wenn eine neue Verbindung zum Gateway aufgebaut wird. Das passiert bspw. bei einem Update oder Neustart. Im schlimmsten Fall dauert somit die Initialisierung ~1 Minute.

[mirkolenz]

@brutella Ich habe mir jetzt nochmal etwas Zeit genommen, das Problem von der Beta bzgl. nicht verbunden/verfügbar zu untersuchen. Dabei ist mir aufgefallen, dass die Beta funktioniert, wenn man sie einige Minuten laufen lässt. Irgendwann wird dann angezeigt, dass initialisiert wird und danach läuft es normal.

[mirkolenz]

Und noch eine andere Frage: Was passiert eigentlich mit bei neuen Beta, wenn ein KNX-Gerät nicht antwortet? Wird dann später noch einmal versucht. Ich habe nämlich ein paar Zigbee-Sensoren und auch Schalter, die ich über Home Assistant nach KNX "expose". Bei einem Server-Neustart war es bisher immer so, dass HKKNX schneller gestartet war und dann den Status dieser Sensoren nicht lesen konnte. Bei den Schaltern hat es dazu geführt, dass diese dann als "Aus" angezeigt werden. Ideal wäre es daher, wenn HKKNX bei solchen Geräten, die am Anfang nicht antworten, noch einmal nach 5-10 Minuten das Lesen probiert.