KNX/EIB Buslast auslesen und weiterverwerten

[nixeifoit]

Hallo zusammen,

das liebevolle Projekt hkknx sucht nach Erfahrungsberichten bzw. Möglichkeiten die Buslast auszulesen und somit basierend auf dieser diverse Werte der Verbindung zu KNX anzupassen.

Siehe Github Issue: https://github.com/brutella/hkknx-pu...ent-1245483151

Vllt. hat hier jemand Erfahrungen bzw. kann zu einer tollen Lösung beitragen.

Danke und LG

[ETechniker]

Das Projekt ist doch von brutella…

[nixeifoit]

Korrekt ETechniker! Ich habe überlegt ob ich es in den "Support-Thread" hier posten soll, oder ein eigenes Thema aufmache.

Habe mich für zweiteres entschieden, weil es ja um eine KNX Grundlage geht, und nicht per se um sein Projekt.

LG

[vento66]

Irgendwie hab ich da gerade einen knopf im Kopf… die bridge läuft doch 24/7 und kennt alle Stati. Wieso liest er die dann beim Starten der app neu ein?

[gbglace]

weil es ja um eine KNX Grundlage geht

Ich kann da keine KNX-Grundlage erkennen.


Was der Bus an Telegrammrate verträgt steht in der Spezifikation. Wenn man nun mit seiner Software selbst eine enorme Telegrammschleuder ist, sollte man das Design so anpassen, dass nicht die mögliche Telegrammlast des IP-Mediums die Telegrammrate definiert, sondern jenes Mediums / Geräts (wie LK) welches in einer jeweiligen Anlage die geringste Telegrammrate bewerkstelligen kann. Die Werte für die Medien IP / TP / RF / PL sollten wohl in den Specs zu finden sein, die Kapazitäten der verwendeten LK ggf in deren Handbüchern oder den in der ETS eingestellten Parametern zur Telegrammratenbegrenzung.

Interessant ist es für so eine Telegrammschleuder also nur zu wissen welches das langsamste Medium / Gerät in der Anlage ist und wie viele der geforderten Leseanfragen aus welchem Medium kommen werden. Da dies aber ohne genaue Kenntnis der ETS-Projektdatei nicht verfügbar ist, ist es schwierig da die passende Telegrammratenbegrenzung festzulegen.

Dazu kommt das eine dynamische Begrenzung auch nicht so sinnig ist, da der zu regelnde Wert gleichzeitig Ursache/Auslöser für diese Regelung wird. Sprich du flutest gerade den Bus siehst die Flutung am Limit und dann, drehst runter und wieder hoch. Da schwingt Dir doch reichlich die Telegrammlast. Und wie schnell willst / kannst da reagieren?
Wenn während der Flutung dann mal noch ein ordentliches Gerät mal wieder was sendet (wie ein KNX-Stromzähler). Wie willst dem Vorfahrt gewähren? Deren Telegramme kommen ja ggf. gar nicht in der Art und Weise an, weil Deine eigene Flutung die anderen Telegramme schon blockiert. Gerade wenn LK's im Spiel sind. Da flutest Du nun aus einer HL den gesamten Bus und die Telegramme aus der Sublinie schaffen es gar nicht mehr auf die HL, um überhaut als Grund erkannt zu werden die Flutung zu reduzieren.

[nixeifoit]

gbglace Da bin ich voll auf deiner Seite!

Ich persönlich kann überhaupt keine "Überlastung" spüren. Ich tippe hier auf ein Problem des Endnutzers, welcher einfach den KNX-Standard nicht befolgt hat und XXX Geräte in einer Linie betreibt.

Dennoch wäre es interessant, ob man irgendwie die Buslast "tracken" kann und somit auch für eine evtl. Verbesserung sorgt.

[gbglace]

Tracken macht quasi jedes Ding was Buslog kann und die Telegramme in eine DB schaufelt aus der man das dann ablesen kann. Bei mir tut dies der 24/7 Logikserver/Schnittstelle, sowie der am KNX Bus hängt.

Oder man schaut nochmal in die Details der Spannungsversorgungen mit Diagnosefunktion was die ggf. für Werte per KO liefern können.


Wobei Bussegment mit dreistelliger Anzahl KNX-Geräte kein Grund ist das der Bus wegen Telegrammflut blockiert ist.

[vento66]

Man müsste doch nur schauen, ob ein Gerät „Busy“ auf den Bus sendet.

[hubidoo]

gbglace Da bin ich voll auf deiner Seite!

Ich persönlich kann überhaupt keine "Überlastung" spüren. Ich tippe hier auf ein Problem des Endnutzers, welcher einfach den KNX-Standard nicht befolgt hat und XXX Geräte in einer Linie betreibt.

Dennoch wäre es interessant, ob man irgendwie die Buslast "tracken" kann und somit auch für eine evtl. Verbesserung sorgt.

hkknx fragt aktuell so schnell, wie möglich alle GAs ab, die konfiguriert sind. Mach das mal in einer Anlage mit 10+ Linien. Der hkknx flutet damit unweigerlich den Bus. Das kann sich schön hoch schaukeln.

[hubidoo]

Ich kann da keine KNX-Grundlage erkennen.


Was der Bus an Telegrammrate verträgt steht in der Spezifikation. Wenn man nun mit seiner Software selbst eine enorme Telegrammschleuder ist, sollte man das Design so anpassen, dass nicht die mögliche Telegrammlast des IP-Mediums die Telegrammrate definiert, sondern jenes Mediums / Geräts (wie LK) welches in einer jeweiligen Anlage die geringste Telegrammrate bewerkstelligen kann. Die Werte für die Medien IP / TP / RF / PL sollten wohl in den Specs zu finden sein, die Kapazitäten der verwendeten LK ggf in deren Handbüchern oder den in der ETS eingestellten Parametern zur Telegrammratenbegrenzung.

Interessant ist es für so eine Telegrammschleuder also nur zu wissen welches das langsamste Medium / Gerät in der Anlage ist und wie viele der geforderten Leseanfragen aus welchem Medium kommen werden. Da dies aber ohne genaue Kenntnis der ETS-Projektdatei nicht verfügbar ist, ist es schwierig da die passende Telegrammratenbegrenzung festzulegen.

Dazu kommt das eine dynamische Begrenzung auch nicht so sinnig ist, da der zu regelnde Wert gleichzeitig Ursache/Auslöser für diese Regelung wird. Sprich du flutest gerade den Bus siehst die Flutung am Limit und dann, drehst runter und wieder hoch. Da schwingt Dir doch reichlich die Telegrammlast. Und wie schnell willst / kannst da reagieren?
Wenn während der Flutung dann mal noch ein ordentliches Gerät mal wieder was sendet (wie ein KNX-Stromzähler). Wie willst dem Vorfahrt gewähren? Deren Telegramme kommen ja ggf. gar nicht in der Art und Weise an, weil Deine eigene Flutung die anderen Telegramme schon blockiert. Gerade wenn LK's im Spiel sind. Da flutest Du nun aus einer HL den gesamten Bus und die Telegramme aus der Sublinie schaffen es gar nicht mehr auf die HL, um überhaut als Grund erkannt zu werden die Flutung zu reduzieren.

Das Problem ist, dass die Flutung die Antworten der Teilnehmer auslöst und damit das Ganze unberechenbar wird.
Der hkknx fragt aktuell beim Starten alle konfigurierten GAs so schnell, wie möglich ab. Er kennt weder Medien-Typen, noch Telegramm-Limitierung, noch Buslast und genau das ist das Problem, was behoben werden soll, wenn ich das richtig interpretiere.

Ob dazu die Projektdatei hilfreich ist, bezweifle ich, da du damit immer noch nicht die Events kennst, die unter Normalbedingungen, also ohne Flutung, zeitgleich auftreten können.

Aus meiner Sicht müsste entweder ein weiterer daemon laufen, der einen Cache aufbaut, den hkknx beim Starten befragt, was aber nur beim Neustart von hkknx funktionieren dürfte, nicht aber beim Systemneustart und weiterhin müsste die aktuelle Buslast errechnet werden und dann nach Abfragen der ersten GA so lange gewartet werden, bis die ursprüngliche Buslast wieder ungefähr erreicht ist und erst dann die nächste GA abgefragt wird. Einfacher wäre wohl, einfach eine Telegrammraten-Begrenzung zu implementieren, so wie das die meisten Geräte auch machen. Wie macht das der Gira Homeserver? Er limitiert die Abfragen und braucht deshalb etwas Zeit, bis er hoch gefahren ist.

[hubidoo]

Man müsste doch nur schauen, ob ein Gerät „Busy“ auf den Bus sendet.

Klappt das noch, wenn Telegramme gar nicht mehr durch kommen?

[hubidoo]

Tracken macht quasi jedes Ding was Buslog kann und die Telegramme in eine DB schaufelt aus der man das dann ablesen kann. Bei mir tut dies der 24/7 Logikserver/Schnittstelle, sowie der am KNX Bus hängt.

Was bedeuten würde, dass hkknx einen externen Service befragen müsste, was brutella wohl nicht machen möchte, wenn ich die Antworten im Issue lese.

Oder man schaut nochmal in die Details der Spannungsversorgungen mit Diagnosefunktion was die ggf. für Werte per KO liefern können.

Das setzt voraus, dass eine Spannungsversorgung mit Diagnosefunktion vorhanden ist. Genau das kann man aber nicht voraussetzen.

Wobei Bussegment mit dreistelliger Anzahl KNX-Geräte kein Grund ist das der Bus wegen Telegrammflut blockiert ist.

Klar geht das. Frage einfach mal alle Status-GAs quasi gleichzeitig ab. Das hat unvorhersehbare Auswirkungen.

[meti]

> Frage einfach mal alle Status-GAs quasi gleichzeitig ab. Das hat unvorhersehbare Auswirkungen.

Entgegen der Spezifikationen handeln hat wohl immer unvorhersehbare Auswirkungen 🤷

Es gibt sowohl für Routing, als auf für Tunnelling eigene Methoden zur Flusskontrolle. Die sind in den KNX Specs dokumentiert - und sollten halt auch eingehalten werden.
Eine davon ist zB RoutingBusy - aber das gibts halt nur bei Routing - und das sollte greifen *bevor* Telegramme verloren gehen.

[hubidoo]

Irgendwie hab ich da gerade einen knopf im Kopf… die bridge läuft doch 24/7 und kennt alle Stati. Wieso liest er die dann beim Starten der app neu ein?

App? Es geht um hkknx selbst. Beim Start der bridge fragt es alle konfigurierten Status-GAs so schnell, wie möglich ab und das ist das Problem. Beim Start des hkknx service kennt es keinen aktuellen Status mehr, da es keinen separaten Cache service mitbringt. Zudem wäre der auch nicht persistent über einen Systemneustart, sonst wären bestimmte Stati sicherlich veraltet. Für die Vergangenheit ginge das, nicht jedoch für die Blindphase, bis der Service wieder online wäre.

[vento66]

Und wo ist das Problem, wenn der initiale Start 20min Dauert?