ETS Aktualisierung GA, bzw. Auswertbarkeit von GAs/Flags.

[Mikelop]

Hallo, sorry für die Überschrift, aber mir ist nichts besser eingefallen und es kann auch sein das ich mich jetzt blamiere,
aber bin ja hier im Einsteiger-Bereich und hätte eine grundlegende Fragen wegen der ETS und GAs.

Ich denke das ich mich mit der reinen Programmierung/Parametrierung ist es ja bei KNX eigentlich nur, schon auskenne wegen beruflichen Hintergrund.

Aber trotzdem falle ich immer wieder über die Fallstricke der ETS mit seinen GAs und Flags, bzw. zyklischen Rückmeldungen rein.

Einfaches Beispiel:

MDT LED-Anzeige mit integrierter Logik. Logik besteht aus 3 Oder, es werden 3 Fenster offen abgefragt und dann leuchtet eine LED wenn eine der GA aktiv ist (True).

Soweit so gut, also die Logik ist nicht schwierig. Aber mein Problem, sie funktioniert nicht immer. Erst wenn ich unter Diagnose rein gehe und jede 3 GAs einmal lese, ist sie dem "System/ETS" bekannt. Es kann auch sein, das es am nächsten Tag wieder nicht mehr klappt. D.h. ich öffne ein Fenster, aber die LED leuchtet nicht.
Lasse ich das Fenster offen und starte in der ETS den Gruppenmonitor und ich wähle jede einzelne GA aus und gehe auf lesen, dann fängt die LED zum leuchten an, aber auch erst wenn ich alle 3 GAs eingelesen habe. Obwohl es ja eine Oder-Logik wäre. Aber anscheinend wertet MDT alle Eingänge aus wartet mit der Logikauswertung.

Es gibt ja auch immer die Möglichkeiten wie:

- Ausgang senden bei Änderung Eingänge
- Ausgang senden bei Änderung Ausgang
- Ausgang senden wenn alle Eingänge plausibel
- usw.

Und natürlich das zyklische Senden. Mit dem behelfe ich mir jetzt aktuell, aber es kann doch nicht die Lösung sein, jede Minute die GAs auf den Bus zu schreiben,
damit die Logiken lauffähig bleiben. Ganz abgesehen davon, das der Gruppenmonitor total unübersichtlich wird und ewig viel Traffic am Bus ist.

Was mache ich Falsch? Ich bin es von der SPS oder Hochsprachenprogramm gewohnt, das wenn die Logik zusammengebastelt hat, das es dann auch funktioniert.
Aber in der ETS reagiert der eine Hersteller so, das er sofort alles auswertet, andere erst wenn alle GAs aktuell sind.
Manchmal kommt es auch vor das ich GAs nicht auslesen kann, also bei Lesen im Gruppenmonitor kommt keine Rückmeldung beim ersten Lesen. Wenn ich aber einfach True schreiben gehe, dann "erwacht" die GA zum leben und sie kann dann wieder im Monitor ausgelesen werden, bzw. sie reagiert dann sogar, also es kann sein, wenn ich auf True schreibe, das dann vom Gerät mit der sie verknüpft ist, sofort False zurück kommt, weil die Logik merkt das True gerade nicht erlaubt ist.
Aber warum kommt dann beim ersten lesen kein "False"??

Wie gesagt was mache ich falsch? Liegt es an falschen Flags? Oder gehört es anders parametriert die einzelnen Module?
Ich kann jetzt schlecht Screenshots mitgeben, da das bei mir ja eher ein allgemeines GA-Problem ist und nicht auf wenige Module begrenzt.

Schön wäre auch eine "GA-Übersicht" welche GAs überhaupt "auswertbar" sind von einer Logik. Also welche aktuell ist. Das scheint bei mir eine reine Glücksache zu sein. Kann es mit den Linienkoppler zu tun haben, wenn diese nach der Programmierung neu reingeladen werden, das dann viele GAs "tot" / "deaktiviert" sind, bis ich sie wieder einmal im Monitor "aktiviere"?

Sorry für langen Text, ich hoffe einer kann mir etwas Tipps geben, wie man das in der ETS "stabiler" und "vertrauenswürdiger" hinbekommt.

[Gast1961]

Und natürlich das zyklische Senden. Mit dem behelfe ich mir jetzt aktuell, aber es kann doch nicht die Lösung sein, jede Minute die GAs auf den Bus zu schreiben, damit die Logiken lauffähig bleiben.

Es muss nicht jede Minute sein, aber wenn deine Fensterkontakte gar nicht zyklisch senden sondern nur bei Änderung hast du die genannten Probleme: die Logik kennt beim Start den Fensterzustand nicht und damit ist das Ergebnis der Logik so lange undefiniert, bis alle Fensterkontakte einmal gesendet haben. Also bis alle Fenster einmal geöffnet/geschlossen wurden.

Einzige Lösung wäre eine Logik, die beim Start die Zustände aktiv abfragen kann. Wenn die KO der Fensterkontakte ein "L"-Flag gesetzt haben würden sie antworten. Beispiel Gira Logikmodul, das kann den Zustand von GA aktiv abfragen. Bei der eingebauten Logik in vielen Geräten fehlt diese aktive Abfrage aber.

[Mikelop]

OK verstanden, aber wenn das Fenster einmal offen war und wieder zu. Warum klappt die Logik dann am nächsten Tag oder nach dem reinladen bestimmter
Komponenten wieder nicht? Muss ich nach dem Linienkoppler laden, wieder alle GAs "refreshen"?
Bzw. kann man irgendeine Auswertung fahren, drüberlaufen lassen, welche GAs undefiniert sind?

[Gast1961]

Denk dran, daß KNX nicht SPS ist. KNX arbeitet mit Telegrammen, nicht mit dauerhaft anliegenden Pegeln.

Wenn ein Gerät (hier: Logik) das Telegramm verpasst (z.B. weil es nach Programmierung neu startet) dann kennt das Gerät den zuvor gesendeten Fensterzustand nicht. Dann braucht es ein neues Telegramm mit dem Wert.

Die Frage ist also nicht "Welche GA sind undefiniert?" sondern die Frage ist "Wer hat welche bereits gesendeten Telegramme verpasst?".

[Mikelop]

Das schwierige ist halt dann, wenn man eine größere Logik hat, mit Uhrzeitvergleich und mehreren Binär GAs und man lädt versehentlich einen Teilnehmer neu,
dessen eine GA in der großen Logik verschachtelt ist, ist die Logik sozusagen "Kaputt" bis man drank denkt, das man die eine GA nochmal antriggern muss.
Schöner wäre es, wenn man das auslesen könnte, was alles fehlt, denn so verlässt man sich z.B. auf die Wohnraumlüftung, oder Beschattung oder dergleichen.
Aber sie funktioniert ein paar Tage und dann ändern man was an einer anderen Stelle und schon ist alles unsmart und die Rollos bleiben oben, oder Lüftung immer aus usw.

Und man weißt nicht mal von den z.B. 10 GAs welche undefiniert ist. Klar könnte man sagen, sobald mal alles programmiert ist und alle GAs einmal angetriggert wurden, dann kennen alle Komponenten die Zustände.

Aber so ein KNX lebt halt auch und wenn ich mal ein paar Wochen später was umstelle/neulade, gehen Logiken die mal funktioniert haben nicht mehr.
Bis man mühevoll die GAs findet, welche inaktiv sind.

Konkretes Bespiel:

Fensterkontakt -- Linienkoppler -- LED Logik (MDT LED Modul)

Wenn ich jetzt den Linienkopper neulade, weil ich für einen anderen Teilnehmer eine neue GA brauche, dann muss ich "Fenster zu" nochmal schicken, weil es die LED Logik nicht mehr kennt? Nichtmal die alten Fensterkontakte, die nicht über den Linienkoppler laufen,
werden nicht mehr ausgewertet, weil in der Oder-Logik vom LED-Modul die eine GA nicht mehr 1 und auch nicht mehr 0 ist, sondern undefiniert.

[vento66]

Dann lass zyklisch aller 12 Stunden senden, dann gehts am nächsten Tag wieder.

[Gast1961]

Schöner wäre es, wenn man das auslesen könnte, was alles fehlt, denn so verlässt man sich z.B. auf die Wohnraumlüftung, oder Beschattung oder dergleichen.

Die "besseren" Logikgeräte beherrschen die aktive Abfrage beim Start, die können dann selbst eine Leseanfrage schicken.

Ansonsten musst du halt zyklisch senden, das würde ich ohnehin immer machen. Es genügt ja alle 30 Minuten oder so.

[Mikelop]

Klar könnte ich alle 12 Stunden viele GAs zyklisch senden. Wenn ich aber z.B. nach ca. 30min nach dem letzten zyklischen Senden, eine GA anlege und dadurch den Koppler neulade, oder bestimmte Teilnehmer neureinlade, dann laufen wichtige Hausfunktionen wie Lüftung oder Beschattung 11h und 30 min nicht mehr, da die Logik "kaputt" ist.

Um diesen Umstand zu umgehen, müsste man ja jede 10s alle GAs zyklisch senden, am besten noch jede GA um 1s verzögert um den Bus nicht zu überlasten, damit man annähernd an die Funktion wie bei einer SPS zu kommen, die ca. alle 30-50ms ihre EAs aktualisiert.

Ich hätte gehofft, das entweder alle Teilnehmer diese "fehlenden GAs" erkennen uns selber nochmal anfragen, oder wenn man das Problem lösen könnte, bestimmte Hacken bei den Flags der GAs zusetzen, das die sich selber aktualisieren, bei undefinierten Zuständen.

Oder wenn die Logik, wenigsten einen Fehler bringt, wenn eine GA zur Auswertung fehlt und nicht einfach 0 bleibt und man denkt, es ist alles ok.

Versteht ihr was ich meine? Anscheinend kann eine einzelne GA ja 3 Zustände haben.
Entweder sie ist True oder False. Und anscheinend gibt es ja noch einen undefinierten Zustand dazwischen, siehe Monitor wenn man die GA auslesen will. Denn wenn ich dann True oder False auf die GA schreibe, hat sie ja wieder einen definierten Zustand.

[vento66]

Zum Glück hast Du das "besseren" in Anführungszeichen gesetzt, hab fast meinen Whisky über den Monitor geprustet

[Gast1961]

Um diesen Umstand zu umgehen, müsste man ja jede 10s alle GAs zyklisch senden

Mach was du willst. Du hast Tipps bekommen, wie andere mit dem Thema umgehen und im Ergebnis keine Probleme haben.

Oder wenn die Logik, wenigsten einen Fehler bringt, wenn eine GA zur Auswertung fehlt und nicht einfach 0 bleibt und man denkt, es ist alles ok.

Bitte mal nachdenken - mit einem 1-bit-Ausgang gibt es nur zwei mögliche Zustände, und die sind beide gültig. Also wird die Logik sinnvollerweise gar nichts senden. Das kannst du aber an deiner LED nicht erkennen, ob die AUS ist weil sie ein AUS bekam oder weil noch gar nichts kam.

Ich hätte gehofft, das entweder alle Teilnehmer diese "fehlenden GAs" erkennen uns selber nochmal anfragen

Kein Problem, einfach eine Logik kaufen die das kann. Ich hatte oben ein Beispiel gezeigt.

[meti]

Fensterkontakt -- Linienkoppler -- LED Logik (MDT LED Modul)

Wenn ich jetzt den Linienkopper neulade, weil ich für einen anderen Teilnehmer eine neue GA brauche, dann muss ich "Fenster zu" nochmal schicken, weil es die LED Logik nicht mehr kennt?

Definitiv nicht. Der letzte empfangene Status der GA wird in jedem Gerät vorgehalten das die GA benutzt (bei dir die Led-Logik). Mit dem Koppler oder dem Fensterkontakt kannst du machen was du willst.
Programmierst du das Led-Modul neu, oder bootest es neu, wird es wohl initialisiert werden müssen - ob es das nun aktiv machen kann, defaults gesetzt sind oder einfach aufs nächste Telegram wartet ist dann ne andere Geschichte.

Manchmal kommt es auch vor das ich GAs nicht auslesen kann, also bei Lesen im Gruppenmonitor kommt keine Rückmeldung beim ersten Lesen. Wenn ich aber einfach True schreiben gehe, dann "erwacht" die GA zum leben und sie kann dann wieder im Monitor ausgelesen werden, bzw. sie reagiert dann sogar, also es kann sein, wenn ich auf True schreibe, das dann vom Gerät mit der sie verknüpft ist, sofort False zurück kommt, weil die Logik merkt das True gerade nicht erlaubt ist.
Aber warum kommt dann beim ersten lesen kein "False"??

Für Ursachenfindung bräuchte es da ein konkretes Beispiel mit Konfiguration, Zuordunungen etc.

[mumpf]

Hi,

Wie gesagt was mache ich falsch? Liegt es an falschen Flags? Oder gehört es anders parametriert die einzelnen Module?
Ich kann jetzt schlecht Screenshots mitgeben, da das bei mir ja eher ein allgemeines GA-Problem ist und nicht auf wenige Module begrenzt.

Wie Du schon schreibst, hast Du eher ein allgemeines Verständnisproblem und nichts konkretes. Und es ist schlecht möglich, hier einen Kurs über KNX-Kommunikation abzuhalten. Aber aus dem, was Du schreibst, schließe ich, dass Du exakt bei der Buskommunikation Lücken hast.

Ich bin es von der SPS oder Hochsprachenprogramm gewohnt, das wenn die Logik zusammengebastelt hat, das es dann auch funktioniert.

Das ist natürlich auch bei KNX so, Du musst nur das Gesamtsystem betrachten. Der Unterschied zu SPS bzw. Hochsprachen ist der, dass Du dort ein Zentralsystem hast, es gibt nur eine Stelle, die das gesamte Wissen über die Anlage hat. Dieser große Vorteil ist auch der größte Nachteil (single point of failure). Würdest Du eine Logik (in einer Hochsprache geschrieben, z.B. NodeJS) über mehrere Knoten verteilen und dann zufällig die einzelnen Knoten durchstarten, würdest Du auch die gleichen Probleme bekommen und das System als unzuverlässig bezeichnen, solange Du es nicht durchdrungen hast und die Einzelprobleme abgestellt hast.

Bei KNX kommen noch neben den Problemen der reinen Verteilung der Intelligenz die Probleme hinzu, die sich durch die "Eigenheiten" der Einzelgeräte ergeben, bedingt durch unterschiedliche Philosophien der einzelnen Hersteller. Aber wenn man akzeptiert hat, dass es ein verteiltes System mit lokaler Intelligenz ist und die telegrammbasierte (NICHT zustandsbasierte) Kommunikation durchdrungen hat, dann sind die Spezialitäten der Hersteller eine Kleinigkeit .

Sorry für langen Text, ich hoffe einer kann mir etwas Tipps geben, wie man das in der ETS "stabiler" und "vertrauenswürdiger" hinbekommt.

Das wichtigste ist die Kommunikation. Du hast da eine falsche Vorstellung, das merkt man alleine, weil Du dauernd von GA sprichst, die Du auslesen möchtest oder die "erwachen". Das geht überhaupt nicht. Die GA ist nur eine Adresse. Du kommunizierst immer mit einem KO. Und wie das KO mit Dir (bzw. dem Bus) kommuniziert, wird durch die Flags am KO bestimmt. Warum ist das Wichtig? Weil eine GA mit mehreren KO verbunden sein kann. Wenn Du eine GA liest, dann können Dir durchaus mehrere KO antworten, und das sogar mit mehreren unterschiedlichen Werten. Ein KO kann nur antworten, wenn das L-Flag gesetzt ist usw.

Normalerweise kommt man auch sehr weit, ohne diese Details zu kennen. Wenn man sich aber über Verhalten wundert und genauer analysieren möchte, warum etwas nicht klappt, führt mangelndes Detailwissen häufig zu Fragen, wie Du sie stellst... weil das Ergebnis zufällig, unzuverlässig oder einfach überraschend ist.

Ich würde das folgende halbwegs konkrete Beispiel mal herannehmen für eine Untersuchung:

Manchmal kommt es auch vor das ich GAs nicht auslesen kann, also bei Lesen im Gruppenmonitor kommt keine Rückmeldung beim ersten Lesen.

Hier muss man als erstes schauen, ob das/die beteiligten KO ein L-Flag gesetzt haben. Falls ja, sollte eine Antwort kommen. Falls nein, das L-Flag setzen, neu programmieren und es erneut versuchen.
Allgemein: Falls Du (und nicht der Hersteller) das L-Flag gesetzt hast, muss (laut Spec) das KO nicht darauf reagieren (da steht "may answer"). Auch wenn das Gerät gerade neu gestartet wurde, gibt es bei manchen Geräten eine einstellbare "Wartezeit nach Neustart, bis das Gerät aktiv wird". Auch in dieser Zeit ist nicht klar, wie Geräte auf Leseanfragen reagieren, manche kommunizieren in der Zeit gar nicht.

Wenn ich aber einfach True schreiben gehe, dann "erwacht" die GA zum leben und sie kann dann wieder im Monitor ausgelesen werden,

Das glaube ich nicht, dazu müsstest Du schon Screenshots der KO und des Gruppenmonitors machen. Um was für ein Gerät geht es? Mit wie vielen KO ist die GA verbunden? Hintergrund: Wenn ein KO das L-Flag gesetzt hat, antwortet es immer (außer vielleicht in der von mir erwähnten Totzeit nach dem Neustart).

also es kann sein, wenn ich auf True schreibe, das dann vom Gerät mit der sie verknüpft ist, sofort False zurück kommt, weil die Logik merkt das True gerade nicht erlaubt ist.

Das geht zwar technisch (wenn das L- und S-Flag auf einem KO gesetzt ist und das Gerät so agiert, dass es seinen Status direkt über das selbe KO kommuniziert), ist aber eher selten. Ich würde hier vermuten, dass diese GA mit 2 KO verbunden ist, das eine empfängt das gesendete "true", das Triggert dann eine Logik, die Logik berechnet ein "false", das wird über ein weiteres KO auf die selbe GA gesendet. Ist aber nur eine Vermutung, und dann hättest Du das so parametriert und es passiert genau das, was passieren soll.

Aber warum kommt dann beim ersten lesen kein "False"??

Wie gesagt, das glaube ich nicht, da wäre ein Beispiel interessant. Mehr kann man zu dem beschriebenen Fall nicht sagen.

Noch was zur Logikauswertung:
Noch

Es kann auch sein, das es am nächsten Tag wieder nicht mehr klappt. D.h. ich öffne ein Fenster, aber die LED leuchtet nicht.
Lasse ich das Fenster offen und starte in der ETS den Gruppenmonitor und ich wähle jede einzelne GA aus und gehe auf lesen, dann fängt die LED zum leuchten an, aber auch erst wenn ich alle 3 GAs eingelesen habe. Obwohl es ja eine Oder-Logik wäre. Aber anscheinend wertet MDT alle Eingänge aus wartet mit der Logikauswertung.

Dass es am nächsten Tag nicht mehr klappt liegt mit Sicherheit daran, dass Du in der Zwischenzeit das Gerät, dass die Logik enthält (ich vermute, es ist die LED-Anzeige), neu programmiert hast. Damit sind die Eingänge der Logik undefiniert. Du kannst nach einem Neustart auch nicht davon ausgehen, dass die Eingänge alle "false" sind. Stell Dir mal vor, Du hast eine Alarmlogik, die eine Sirene auslöst, wenn eine bestimmte Situation 3 "false" liefert. Sicherlich willst Du nicht, dass nach jedem Neustart des Gerätes (also auch nach einem Stromausfall mitten in der Nacht) die Sirene losgeht. Also kann die Logik erst sinnvoll funktionieren, wenn der Zustand der Eingänge korrekt belegt ist, und das ist frühestens nachdem an jedem Eingang mindestens ein Telegramm eingegangen ist. Deswegen "erwacht" die Logik erst, wenn Du alle 3 GA in der ETS gelesen hast. Das ist der Hintergrund.

Noch ein Tipp zur konkreten Problemlösung:
MDT hat aber bei seinen Geräten immer auch Parameter, die das Verhalten nach einem Neustart spezifizieren. Bei den Logiken sollte es so was geben wie "Bei Busspannungswiederkehr externe Werte lesen". Damit ist Dein Logikproblem mit der LED-Anzeige gelöst.

Gruß, Waldemar

[Mikelop]

Hier muss man als erstes schauen, ob das/die beteiligten KO ein L-Flag gesetzt haben. Falls ja, sollte eine Antwort kommen. Falls nein, das L-Flag setzen, neu programmieren und es erneut versuchen.
Allgemein: Falls Du (und nicht der Hersteller) das L-Flag gesetzt hast, muss (laut Spec) das KO nicht darauf reagieren (da steht "may answer").

Zur Info, damit ich nicht was falsch mache, habe ich noch nie ein Flag selber gesetzt oder umgeschrieben. Daher auch die Frage ob man in Sonderfällen, wie du schreibst, evtl. mit dem L-Flag setzen, wenn es der Hersteller nicht selber macht, zum Erfolg kommt.

Noch ein Tipp zur konkreten Problemlösung:
MDT hat aber bei seinen Geräten immer auch Parameter, die das Verhalten nach einem Neustart spezifizieren. Bei den Logiken sollte es so was geben wie "Bei Busspannungswiederkehr externe Werte lesen". Damit ist Dein Logikproblem mit der LED-Anzeige gelöst.

Auf das bin ich selber auch schon gekommen. Ich spiele ja schon länger an den Parametern rum:

LED.jpg
LED.jpg

Trotz dieser Einstellung, bleiben alle LEDs aus, bis man wirklich von Hand jede verknüpftes (KO) über GA einmal neu ausliest.
Ich hätte ja gehofft das das LED-Modul beim initialisieren das selber macht.


Aber kürzen wir das hier ab. Wenn ich eure Tipps und Antworten gelesen und richtig verstanden habe, bleiben mir 2 Optionen:

Option A: So gut wie jedes KO zyklisch senden lassen, 1 wie auch 0, damit die verschiedenen Logik-Funktionen der Hersteller funktionieren, auch wenn man mal das eine oder andere Gerät neu ladet. Bzw. nicht nur Logik, betrifft eigentlich auch andere Teilnehmer die auf KOs/GAs hören.

Option B: Nach jedem neu starten/laden eines KNX-Teilnehmers alle KOs/GAs dieses Teilnehmer mit der Hand im Gruppenmonitor nochmal an triggern/auslesen.

Macht ihr das wirklich von Hand bei jedem Teilnehmer den ihr neu ladet, das ihr durchgeht und alle Signale "auffrischt"?
Besonders bei Glastastern/Bedienzentralen sowie Jalousieaktoren ist das ja eine ganz schöne Arbeit, bis man alle Zustände neu triggert.

Und wenn ein Großteil von euch alles zyklisch macht, dann wird man im Gruppenmonitor ohne Filterung nichts mehr analysieren können, da ja dann die Zeilen nur noch so durchlaufen mit dem ganzen zyklischen senden. Gut man könnte zwar wie geschrieben bloß alle 12 Stunden "updaten", aber bei vielen GAs muss man die auch zeitlich etwas versetzen.
Weiterhin gibt es manche Hersteller die ein zyklischen senden gar nicht zur Auswahl haben, d.h. für diese Teilnehmer müsste das zum Beispiel ein Logikmodul nachholen. MDT kann das ja zum Beispiel auch, aber bei den wenigen freien Logiken auch keine tolle Lösung.

[mumpf]

Hi,

Daher auch die Frage ob man in Sonderfällen, wie du schreibst, evtl. mit dem L-Flag setzen, wenn es der Hersteller nicht selber macht, zum Erfolg kommt.

ich setze die Flags immer so, wie ich sie brauche und probiere entsprechend aus, ob das die gewünschte Wirkung zeigt. Im Zweifelsfall einfach merken, wie die Originaleinstellung war und bei Misserfolg wieder zurücksetzen. Immer beachten: Auch nach einer Flagänderung musst Du das Gerät programmieren.

Trotz dieser Einstellung, bleiben alle LEDs aus, bis man wirklich von Hand jede verknüpftes (KO) über GA einmal neu ausliest.

Schau doch mal nach dem Programmieren auf den Gruppenmonitor, ich bin mir sicher, dass da passende ReadRequests auftauchen. Du musst dann einfach nur analysieren, ob geantwortet wurde. Und wenn nicht, dann prüfen, warum nicht.

So gut wie jedes KO zyklisch senden lassen,

Nein. Zyklisch senden hat seine Berechtigung, z.B. für Temperaturen, damit ein Heizaktor in Notbetrieb gehen kann, wenn eine bestimmte Zeit lang keine Temperatur empfangen wurde. Mit gleichem Argument kann man Fensterkontakte zyklisch senden lassen, einfach um sicher zu sein, dass der Binäreingang noch funktioniert.
Aber der Status eines Gerätes wird bei mir nicht zyklisch gesendet, da er ja in den empfangenden KO erhalten bleibt.

Nach jedem neu starten/laden eines KNX-Teilnehmers alle KOs/GAs dieses Teilnehmer mit der Hand im Gruppenmonitor nochmal an triggern/auslesen.

Ein noch größeres NEIN. Ich verwende nur Logiken, die ihre Werte bei einem Neustart vom Bus lesen können (wie die MDT-Logik oben). Ich sehe zu, dass sie immer eine korrekte Antwort bekommen.

Macht ihr das wirklich von Hand bei jedem Teilnehmer den ihr neu ladet, das ihr durchgeht und alle Signale "auffrischt"?
Besonders bei Glastastern/Bedienzentralen sowie Jalousieaktoren ist das ja eine ganz schöne Arbeit, bis man alle Zustände neu triggert.

Nochmals nein. Du hast ja schon selber erkannt, dass das keinen Spaß macht. Ich analysiere die Situation so lange, bis sie auch nach einem Neustart funktioniert. Genauer gesagt, gibt es 2 Arten von Neustarts: Das Gerät selbst oder das Gesamtsystem (Stromausfall). Der 2. Fall ist noch schwieriger zu behandeln, da bin ich auch noch nicht so weit, wie ich möchte. Da ist das Zauberwort aber die "Geräteanlaufzeit" (siehe Dein Screenshot oben).

Wenn Du Dir die Mühe machst, zu verstehen, was da abgeht, dann wird jede weitere Analyse einfacher...

Gruß, Waldemar

[Mikelop]

Ok, also LED-Anzeige fragt nach Neustart die einzelnen KOs ab.
Dann werde ich mal weiter analysieren welches KO dann nicht antwortet, oder wo es sonst hängen kann.

Ich werde das mit dem setzen des L-Flags und anschließendem neu laden dann auch nochmal testen.