ElabNET Technik Forum

Ausgangslage:

- eine Gruppenadresse (binär) hängt ausschließlich an einem Universalobjekt vom TWS
- Alle Flags sind gesetzt (inkl. I-Flag)
- KNX-Stack vom TWS neu starten (aus der ETS "Gerät neu starten")
- Readrequest (durch gesetztes I-Flag) wird vom TWS auf die GA ausgelöst, es kommt aber keine Antwort
- Auch auf einen manuell ausgelösten "Lesen-Aufruf" aus der ETS kommt keine Antwort vom TWS.
- Sende ich jetzt, (z.B. FALSE), dann antwortet der TWS beim nächsten Readrequest mit False.

Der KNX-Stack kennt also einen GA-Wert-Zustand "undefined" und reagiert darauf mit Nichtantwort (finde ich gut)

Warum ist dann aber der Logikausgang, an dem die GA hängt auf FALSE und nicht auch auf undefined (siehe [V4.5 IP3] Wert senden bei Busreset / Geräteneustart

Wenn die Logik nun erstmals läuft und das Ergebnis FALSE wird, wird das False nicht gesendet. Und @Robert_Mini Der Geräteneustart aus der ETS (Gerät neu starten) triggert auch nicht Erweiterung für Persistenz: Senden nach Reboot, so dass ich mit meinem Problem, den Wert im Stack nach Geräteneustart (bus reset) erneut senden lassen zu wollen nicht weiterkomme Das kann doch nicht sein, dass ich den Bus nicht initialisiert bekomme, wenn ich Geräte neu programmiere oder die Busspannungsversorgung kurz weg geht, oder ich beim Ab/Anklemmen einen Kurzschluss auf dem BUS auslöse. Der TWS soll für mich in dem Fall die Initiialisierung des Busses wieder herstellen, damit Visu, Statusobjekte etc. ppp in allen "dümmeren" Geräten wieder stimmt. Hat denn sonst keiner die Anforderung an einen permanent sauberen Zustand der Objekte ?

Gruß

Franky

Ich mache als Workaround jetzt folgendes:

• Ich lasse ein Logikmodul (MDT) mit seiner Funktion "Senden nach Reset" eine GA triggern, die ich dann im TWS abfange. Das entspricht dem "Baustein 1: Trigger nach Reboot" aus [V4.5 IP3] Wert senden bei Busreset / Geräteneustart.
  
  
  wird gesendet auf:
  
  und dann am TWS einlesen: (ignoriert mal unsauber Flagauswahl, das wird noch bereinigt)
  

• Der Vorteil zu einem reinen Workaround im TWS ist, dass es auch bei einem Neustart des Busses (Geräteinstallation, Aufruf aus der ETS, Netzteil Neustart, Kurzschluss auf BUS, ...) ausgelöst wird und nicht "nur", wenn das Logik Subsystem des TWS oder der TWS komplett neu startet.

• Den Trigger vom MDT-Logikmodul fange ich dann analog zu @Robert_Minis Lösung im Baustein 2: Persistente Zelle zum Senden nach Reboot ab.

Daraus würde ich gerne einen (eher niedrig) priorisierten FR stellen:

[FR]: Trigger (vielleicht vergleichbar mit Modul Clocksignal), der ausgelöst wird, wenn es einen BUS-Reset / Neustart des KNX-Stacks gibt (das fängt den Neustart des Logik Subsystem / des kompletten TWS mit ab).

Optionale Erweiterung des FR: Wenn das Programmieren eines Gerätes erkannt werden könnte, könnte man auch in diesem Fall GAs senden, um jene Geräte zu initialisieren, die zu einfach gebaut sind, um beim Geräteneustart ein Readrequest auszulösen. Nach meiner Sicht, müsste man nicht das Gerät identifizieren können, sondern man initialisiert in einer custom logik wie Baustein 2: Persistente Zelle zum Senden nach Reboot einfach so, wie bei einem Neustart des KNX-Stacks.

Siehe hierzu auch:

Link 1 Link 2 Link 3

Gruß

Franky

Hallo Franky!

Danke für die Diskussion und FR.
Ich denke es gibt hier keinen perfekten Weg und unterschiedliche Ansichten. Den Fall Bus-Reset hatte ich nicht am Schirm, hab ich ehrlicherweise auch noch wie verwendet....
Auch der TWS bekommt nur selten eine KNX-Programmierung (aber gelegentlich natürlich schon), da hatte ich aber noch nie ein Thema.

Mein Fokus war immer, dass nach einem Stromausfall alles richtig initialisiert, was ganz gut klappt. Deinen Workaround finde ich ganz gut. Eventuell wäre ein Objekt: "KNX-Stack resetted" eine gute Idee als Erweiterung für den Stack V2?

Ansonsten noch ein paar Gedanken:
- Mit aktivierter Persistenz sollte grundsätzlich er letzte Wert am Ausgang vorliegen
- Bei einem Neustart / Stromausfall etc. gibt es bei manchen Logiken auch einen Reihenfolgeeinfluss (d.h. zB bei einer State Machine könnte man in einem anderen Status landen, je nachdem wie in welcher Abfolge die Werte kommen).
- Die Idee, diesen Wert bei KNX reset in den Stack zu übernehmen gab es schon mal, finde die Diskussion grad nicht. Dies fände ich noch immer die smarteste Lösung inkl. Reset-Objekt

lg
Robert

Robert_Mini hat geschrieben: ↑So Mär 16, 2025 10:36 am - Bei einem Neustart / Stromausfall etc. gibt es bei manchen Logiken auch einen Reihenfolgeeinfluss (d.h. zB bei einer State Machine könnte man in einem anderen Status landen, je nachdem wie in welcher Abfolge die Werte kommen).

ja, in jedem Fall, das habe ich noch nicht überrissen: Haben wir noch keine Lösung, um die Reihenfolge zu steuern? Wenn nicht, könnte eine Lösung darin bestehen, für jede Logik eine Wiederanlaufzeit vorzugeben ("Verzögerung nach Reset" nennt MDT das bspw.) Wäre das ein weiterer FR Die Reihenfolge muss m.E. in jedem Fall gesteuert werden können, um da keine ungewollten Seiteneffekte zu bekommen.

LG

Franky

Hi Robert,

Robert_Mini hat geschrieben: ↑So Mär 16, 2025 10:36 amEventuell wäre ein Objekt: "KNX-Stack resetted" eine gute Idee als Erweiterung für den Stack V2?

Steht schon auf der Liste, Credits gehen allerdings dafür an Franky, weil wir lesen schon aufmerksam mit, ich kann nur zeitlich nicht auf alles ständig eingehen, aber alles was eine vernünftige "Forderung" ist, fällt bei uns auch auf fruchtbaren Boden. Kennen alle die länger dabei sind ja auch.

Konkret fällt das unter das große Thema "Systemobjekte", das es eben auch auf Ebene der Subsysteme & Geräte geben soll.

Es gibt auch schon - seit Jahren - eine erste Implementierung mit den fünf Systemobjekten, die automatisch für jede HTTP-/REST-API generiert werden. Allerings ist unser Eindruck, dass diese nicht wirklich umfangreich verwendet werden, weil viele betrachten beim Einrichten von Logik nur die "Bedingungen bei Sonnenschein", also wenn alle Sensoren & Aktoren und alle dazwischenliegenden Übertragungs- und Verarbeitungssysteme einwandfrei funktionieren. Kaum jemand interessiert sich für die Bedinungen bei "Schlechtwetter" und ob eine Logik auch die richtigen Entscheidungen trifft, wenn Sensoren gar keinen aktuellen Wert mehr liefern (weil z.B. seit einem halben Jahr defekt). Deren Berücksichtigung würde man Fail-Safe nennen. Sind schon Verkehrsflugzeuge abgestürzt deswegen, weil der Ausfall eines Sensors bzw. die Diskrepanz zwischen zwei Sensoren (der eine Sensorwert wurde dem einen Piloten angezeigt und der Wert des zweiten Sensors dem anderen Piloten ohne eine Hinweisflag für Unterschiedlichkeit) nicht erkannt wurde.

Für den nächsten KNX Stack ist jedoch vorgesehen, dass es hier eine Reihe von Systemobjekten - für alle auftretenden Zustände gibt - die dann von einer Logik auch genutzt werden können. Würde mir wünschen, dass dies dann auch von mehr als dem einen Prozent der Nutzer am Ende dann auch genutzt wird.

Robert_Mini hat geschrieben: ↑So Mär 16, 2025 10:36 amDie Idee, diesen Wert bei KNX reset in den Stack zu übernehmen

Ist auch auf der Liste, am besten konfigurierbar. Ob jetzt pro Objekt oder ale Eigenschaft pro "1000er Block" überlegen wir derzeit.


Hi Franky,

dazu - also konfigurierbare Eigenschaften pro "1000er Block" - gehören dann auch Timing Themen, also "Senden frühestens xx Sekunden ab Bus-Wiederkehr" mit "Request On Init ab xxx Sekunden nach Buswiederkehr". Wir diskuttieren das derzeit intern, es kommt also alles an.


lg

Stefan

Ich glaube ehrlicherweise du verrennst dich da grad etwas.

Reihenfolgeeinfluss meint ja, dass eine unterschiedliche Reihefolge unterschiedliche Stati erlaubt. Dazu müsste man aber die letzte gültige Reihenfolge wissen (speichern) und nicht eine fixe vorgeben, die dann doch wieder in einen anderen Status einmündet.

Vieles ist aber auch theoretisch und bei guter Programmierung auch vermeidbar.
Mit Persistenz an den betroffenen Logiken hatte ich da noch nie ein Problem und hab doch ein paar Neustarts des TWS, Stromausfälle etc. hinter mir.
Manches kann (oder muss) man auch durch zyklisches Senden lösen, weil man das Thema Reihenfolge vermutlich nie 100% lösen kann.

Konstruierte Beispiele:
- Es mag bei einem Reboot die Behanghöhe mal ein paar Minuten falsch sein, weil der Fensterstatus zu früh kommt und der TWS/die Logik das nicht mitbekommt. Nach dem 1x zyklisch Senden des Fensterstatus passt das dann.
- Gerade Timer sind da tricky! Ein State könnte durch Timerablauf weiterspringen. Da ist Persistenz auch besser, weil die Stati in der Logik und an den Ein/Ausgängen erhalten bleiben und dann auf neue Änderungen reagieren. Das klappt bei Reboots/kurzen Stromausfällen praktisch immer. Deshalb wär da das aktive Übertragen an den KNX Stack das Richtige.

lg
Robert