Zentralfunktionen auf dem KNX - Telegramme gehen verloren

[jonofe]

Ich hätt' da gern mal'n Problem...

Folgende Situation:
- Ich habe in unserem haus ca. 50 Leuchten, davon ca. 35 via KNX, 3 an IP Steckdosen und 12 HUE
- Ich folgende zentralen Schalt-KO definiert: Beleuchtung-KG, Beleuchtung-EG, Beleuchtung-OG, Beleuchtung-DG, Beleuchtung-Gesamt.
- Außerdem entsprechende zentrale Status-KO: Beleuchtung-KG-Status, Beleuchtung-EG-Status, Beleuchtung-OG-Status, Beleuchtung-DG-Status, Beleuchtung-Gesamt-Status.

Die o.g. zentralen Status-KOs habe ich über entsprechende ODER LBS zusammengeklickt. Als Input bekommen die ODER LBS die Status-KOs (KNX und Edomi) der einzelnen Leuchten. Damit werden dann die zentralen Status-KOs berechnet. Funktioniert auch soweit ganz gut.

Die Schalt-KOs habe über entsprechende Ausgänge realisiert, wo bei in jedem Ausgang dann die Liste der Schaltbefehle steht, um alle Leuchten in KG, EG, OG, DG zu schalten.

Soweit mein initialer Ansatz.

Wenn ich nun z.B. Beleuchtung-Gesamt schalte, dann bleiben oft einige Leuchten an bzw. aus, d.h. es werden nicht alle Schaltvorgänge ausgeführt.
Ich vermute nun, dass es irgendwie zu einer Überlastsituation führt, da jeder der 35 KNX Schaltvorgänge auf dem KNX ein Statustelegramm des Aktors auslöst, dieses KNX Status Telegramm führt dann wieder meine o.g. Status-Logik, z.B. Beleuchtung-EG-Status aus. Diese wiederum triggert die Beleuchtung-Gesamt-Status Logik und sendet ggf.ihren Status auch noch auf den KNX falls ich irgendwo einen Schalter mit Status-LED für die Beleuchtung im EG habe.

Es scheint mir nun, dass irgendetwas in dieser Kette zur Überlastung führt. Im ETS Gruppenmonitor sehe ich die fehlenden Schaltvorgänge auch gar nicht. Entweder werden die gar nicht gesendet oder auch die ETS bekommt diese nicht mit.

Ein "SendByChange" LBS vor jedem Status-Ausgang hat das Problem scheinbar gelöst, so dass es nun ziemlich zuverlässig funktioniert. Ich muss es noch weiter in der Praxis testen.

Mich würde nur interessieren, ob diese Erfahrung auch schon andere gemacht haben und wo die Ursache liegt? Kann ich das irgendwie weiter debuggen?

Telegrammrate steht auf 20 und ich setze die eibmarkt IP Schnittstelle mit 5 Tunnelverbindungen ein.

Wie macht ihr solche "Massenschaltvorgänge" auf dem KNX via Edomi?
Man könnte z.B. noch den Status der einzelnen Leuchten auswerten und wirklich nur die ein-/auschalten, die nicht ein/ausgeschaltet sind.

Danke für euer Feedback

André

[coliflower]

OK, ich habe nur 20 Lichtkreise, bis jetzt keine negative Erfahrungen gemacht.

- Ich folgende zentralen Schalt-KO definiert: Beleuchtung-KG, Beleuchtung-EG, Beleuchtung-OG, Beleuchtung-DG, Beleuchtung-Gesamt.

Sind das in Edomi definierte KOs oder tatsächlich in der ETS parametrierte GAs auf die auch die Aktoren lauschen ?

[vento66]

Eine Zentral GA, die ausschaltet. Die Leuchten sollten dann halt nur ihre Rückmeldung senden, wenn sich der Status ändert.

[jonofe]

Eine Zentral GA, die ausschaltet. Die Leuchten sollten dann halt nur ihre Rückmeldung senden, wenn sich der Status ändert.

Du meinst damit KNX GA? Und die dann jeder Leuchte per ETS zuordnen?

[vento66]

Ja klar. Zentraladresse an jede Leuchte (dann hast die Panikfunktion auch gleich mit dabei )

[jonofe]

OK, ich habe nur 20 Lichtkreise, bis jetzt keine negative Erfahrungen gemacht.



Sind das in Edomi definierte KOs oder tatsächlich in der ETS parametrierte GAs auf die auch die Aktoren lauschen ?

Das sind interne EDOMI KOs. Manche davon haben aber auch eine entsprechende KNX GA, z.B. Beleuchtung-Gesamt. Diese wird als EDOMI-KO berechnet und bei Änderung dann auf die entsprechende KNX GA geschrieben.

[coliflower]

Dann wie schon Micha geschrieben hast, für deine Bedürfnisse wie z.B. KG, OG, 1G oder DG eine zentrale GA in der ETS einrichten und jedem Aktor (Leuchte) zuordnen ...

[jonofe]

Ja klar. Zentraladresse an jede Leuchte (dann hast die Panikfunktion auch gleich mit dabei )

Damit hatte ich in der Vergangenheit ähnliche Probleme. Aber ich vermute meine Aktoren sind derzeit so programmiert, dass sie immer den Status senden und nicht nur bei Change. Muss ich mir mal anschauen, aber ich erinnere mich an ein ähnliches Problem, weil dann wirklich alle Aktoren den Befehl gleichzeitig bekommen. Damals hat das Entzerren über einzelne Schaltbefehle das Problem gelöst. Aber das war vor EDOMI, zwar auch per php aber über eibd.

[gaert]

Sofern Du keine "Logikschleife" (versehentlich) produzierst, ist es egal wieviele GAs gesetzt werden etc. - wird alles in einer Queue verarbeitet. Ich kenne ja Deine Logiken nicht, von daher kann ich keine konkrete Aussage treffen. Wichtig zu wissen ist aber, dass dies alles asynchron erfolgen wird, d.h. die Statusantwort vom Aktor trifft u.U. erst viel später als erwartet ein - je nach Buslast. Entscheidend ist also die Logik dahinter: Erwartet die Logik eine Reaktion in einem bestimmten Zeitfenster? Dann könnten natürlich "Probleme" entstehen...

EDIT:
Ein Beispiel aus meiner Hütte: Ich habe inzwischen rund 70 Leuchten-Kanäle, die ich spaßeshalber alle per Szene ein/ausschalte - das geht dann klack-klack-klack...*70 Auch die Rückmeldungen trudeln dann zeitnah ein - jedoch total zufällig bezüglich der Reihenfolge (aber vollständig). Anscheinend ist die Reihenfolge selbst pro Aktor "zufällig" verteilt, d.h. wenn ich ABCDE schalte, kommt z.B. BDCAE zurück.

[jonofe]

Die Logik ist minimalistisch:

Schalten: Eingangssignal und dann direkt auf den Ausgang, der dann alle KNX Schaltbefehle enthält.
Status: Für jedes KNX Statusobjekt ein Eingang in einem ODER LBS, das ganze das kaskadiert bis der finale Status herauskommt.

gaert Szene bedeutet, dass du auch alle 70 KNX Kanäle einzeln schaltest und auch alle 70 Rückmeldung separat verarbeitest?


EDIT: Mir ist noch was aufgefallen: Wenn ich EDOMI neu starte, dann wird ja irgendwann der Kreis leuchtend grün, was ja m.W. bedeutet, dass der Start erfolgreich war. Dann dauert es bei mir immer noch recht lange, bis ich über EDOMI performant KNX Signale versenden kann, d.h. ca. 20-30 Sekunden. Die Signale die ich vorher sende werden zwar abgearbeitet, aber sehr verzögert (erst nach den 20 Sekunden). Passieren nach dem der Ring grün wurde noch weitere Initialisierungs-Tasks von EDOMI? Liegt das ggf. an meiner Logik? Wird dann ggf. die Logik initial durchlaufen? Ich sehe dann auch eine sehr hohe mySQL Last, die sich nach den 20 Sekunden dann wieder einpendelt.

[jonofe]

Die Logik ist minimalistisch:

Schalten: Eingangssignal und dann direkt auf den Ausgang, der dann alle KNX Schaltbefehle enthält.
Status: Für jedes KNX Statusobjekt ein Eingang in einem ODER LBS, das ganze das kaskadiert bis der finale Status herauskommt.

gaert Szene bedeutet, dass du auch alle 70 KNX Kanäle einzeln schaltest und auch alle 70 Rückmeldung separat verarbeitest?


EDIT: Mir ist noch was aufgefallen: Wenn ich EDOMI neu starte, dann wird ja irgendwann der Kreis leuchtend grün, was ja m.W. bedeutet, dass der Start erfolgreich war. Dann dauert es bei mir immer noch recht lange, bis ich über EDOMI performant KNX Signale versenden kann, d.h. ca. 20-30 Sekunden. Die Signale die ich vorher sende werden zwar abgearbeitet, aber sehr verzögert (erst nach den 20 Sekunden). Passieren nach dem der Ring grün wurde noch weitere Initialisierungs-Tasks von EDOMI? Liegt das ggf. an meiner Logik? Wird dann ggf. die Logik initial durchlaufen? Ich sehe dann auch eine sehr hohe mySQL Last, die sich nach den 20 Sekunden dann wieder einpendelt.

EDIT2: Wie kann ich das in EDOMI debuggen, d.h. prüfen, ob alle KNX Kommandos gesendet und alle Status-Rückmeldungen empfangen wurden? Ist es das Monitor-Log oder gibt es noch was anderes?

Sorry, sollte eigentlich als EDIT2 im vorherigen Post landen...

[coliflower]

In Telegram, dann siehst die Leuchten und die dazugehörige Reihenfolge :-)
Ist aber Arbeit dies einzurichten :-(

[jonofe]

In Telegram, dann siehst die Leuchten und die dazugehörige Reihenfolge :-)
Ist aber Arbeit dies einzurichten :-(

Damit könnte ich das Ergebnis sehen. Aber ich möchte ja sehen, wenn das Ergebnis nicht das erwartete ist, wo dann die KNX Kommunikation in die Hose gegangen ist. Im ETS Gruppenmonitor sehe ich die Schaltsignale nämlich nicht. Ich würde jetzt gerne prüfen, ob EDOMI die an die Schnittstelle sendet.

Ich meine mich zu erinnern, dass ich mal ein ähnliches Problem hatte, als ein Linienkoppler defekt oder zu alt war, da gabs auch Probleme. Ich tippe da eher auf ein solches Problem. Denn habe inzwischen auch gesehen, dass manchmal beim InitScan 2 Abfragerunden benötigt werden, obwohl alle GAs definitiv readable sind.

[jonofe]

Gerade ist es wieder mal schief gegangen. Es sollten alle leuchten eingeschaltet werden. von den 35 KNX Leuchten wurden nur 3 geschaltet. Und genau diese 3 Schaltaktivitäten (EDOMI => KNX) tauchen im Monitor Log auf, die anderen 32 aber nicht. Frage ist nun: Was bedeutet es, wenn ein Eintrag im Monitor Log erscheint bzw. nicht erscheint?

[gaert]

Du könntest noch das Tracelog aktivieren zum Mitschneiden der gesamten KNX-Kommunikation. Offenbar ist irgendetwas mit der Kommunikation im Argen würde ich sagen

EDIT:
Zu Deinen anderen Fragen: Ja, meine 70 KOs aus der Szene liefern alle eine individuelles Status-GA zurück. Meine Aktoren sind ja alle auf "dumm" programmiert, daher gibt's bei mir (fast) keine Zentraladressen etc.

Wenn der Ring grün ist, ist alles soweit erledigt. Bedeutet: Initscan/Initsend ist durch und auch die LBS sind alle initialisiert worden. Ab "grün" werden natürlich ggf. diverse Logiken ausgeführt, sofern diese z.B. von einer GA getriggert werden.