[Beantwortet] [V4.0 IP3] KNX Status Objekte für Timberwolf Visu nach Neustart erforderlich?

[zoonuser]

Hallo,

braucht die TW Visu Status Objekte aus der KNX Welt, um nach einen Neustart bzw. Stromausfall alles abfragen zu können?

Grüße
Enrico

[blaubaerli]

Hallo Enrico,

das sollte eigentlich m.E. durch das korrekte Setzen der entsprechenden Flags an den Universalobjekten des TWS in der ETS erledigt werden.

Schau mal hier: https://support.knx.org/hc/de/articles/ ... 8089-Flags

Relevant ist dabei hier das "I" für den von dir angesprochenen Fall.

Der TWS wird sich als zertifiziertes Gerät hier entsprechend korrekt verhalten. Ob dann da auch alle Geräte mit dem richtigen Timing antworten, wird im Zweifel nur ein sauberer "Wiederanlauf-Test" zeigen. Dafür ist ja der Busmonitor im Zweifel das denkbar beste Hilfsmittel...

Beste Grüße
Jens

[StefanW]

Danke Jens,

bist Du sicher, ob Du den "von Dir angesprochenen Fall" herauslesen konntest?


Hi Enrico,

magst Du den Fall genauer angeben? Also WAS ist GENAU hinsichtlich Deiner Frage vom Stromausfall / Neustart betroffen?

Neustart eines einzelnen KNX Gerätes?
Neustart des ganzen KNX Busses?
Neustart des Timberwolf Servers?
Neustart des VISU Subsystems / der Konfiguration
Neustart des Endgerätes mit dem Client der Timberwolf VISU?

Eine Mischung davon?

lg

Stefan

[zoonuser]

Hallo Stefan,

ich kenne es vom X1. Bei einem Neustart weiß die Visu keine Zustände. Deshalb fragt der X1 den Status aller angelegten Geräte ab. Ich wollte in Vorbereitung der TW Visu alle GA's mit dem TW verknüpfen, dabei kam die Frage auf vom Status.

Von Jens mit Flags kann ich nicht ganz mitgehen. Die Visu muss aktiv nach einem Neustart alle Geräte/KOs im BUS nach dem Zustand fragen.

Grüße

[blaubaerli]

Hi Stefan,

bist Du sicher, ob Du den "von Dir angesprochenen Fall" herauslesen konntest?

nicht zu 100 %. Ich hatte da aber eine durchaus starke Vermutung, die mich zum Hinweis mit den Flags verleitet hatte.

Ich lehne mich mal soweit aus dem Fenster, dass speziell ein Großteil der KNX-Autodidakten mit dem „I“-Tag wohl eher stiefmütterliche Bekanntschaft hat. Ich schließe da mal schlicht aus meiner persönlichen Historie.

Beste Grüße
Jens

PS: ich möchte hier aber auch niemandem explizit etwas unterstellen, also bitte nicht falsch verstehen!

[StefanW]

Hi Jens,

Ich lehne mich mal soweit aus dem Fenster, dass speziell ein Großteil der KNX-Autodidakten mit dem „I“-Tag wohl eher stiefmütterliche Bekanntschaft hat.

Das dürfte schon so sein, weil

1. Dieses FLAG von der ETS (zumindest bei den mir bekannten Versionen) gar nicht angezeigt wird und man das separat einblenden muss (da muss man also nicht nur das Flag und dessen Bedeutung kennen, sondern auch die diesbezügliche Bedienung der ETS damit das zumeist unbekannte Flag dann auch einrichtbar wird)

2. Gibt es wohl kaum KNX Geräte, die davon gebrauch machen und selbst wenn, dann nicht mit Universalobjekten (zumindest kenne ich kein anderes Gerät, aber ich kenne auch nicht die Applikation aller 8000+ KNX Geräte am Markt).

Insofern ist das fast eine Timberwolf Server "spezielles" (und saugeiles) Feature, das aber wenig gewürdigt wird, da zumeist unbekannt.

lg

Stefan

[StefanW]

Enrico,

magst Du mir meine Rückfrage noch beantworten, auf welchen Ausfall / Neustart WELCHER Komponente sich Deine Frage beruht, weil das macht teils echt einen Unterschied und ich möchte gerne darauf eingehen, was auch gedacht war.

lg

Stefan

[zoonuser]

Hallo Stefan,

Neustart absichtlich oder unabsichtlich (z.B. bei Stromausfall) vom TW bzw TW Visu. Bei unabsichtlich verhält es sich gleich einem BUS Reset.
Einzelgeräteneustart ist ebenso interessant.
Vielleicht verhält es sich wie bei Logiken welche Persistent sind und die VISU merkt sich alles. KNX Geräte können aber ein anderes Verhalten nach einen Neustart haben. Was macht die VISU in dem Fall?
Grüße

[blaubaerli]

Hallo Enrico,

Neustart absichtlich oder unabsichtlich (z.B. bei Stromausfall) vom TW bzw TW Visu. Bei unabsichtlich verhält es sich gleich einem BUS Reset.

verstehe ich nicht. Wenn du einen Stromausfall hattest, der den TWS betroffen hat, meinetwegen ist der Sicherungsautomat geflogen, dann ist doch nicht automatisch auch der komplette BUS im Reset. Es sei denn, die Stromversorgung deines KNX hat an der identischen Sicherung gehangen.

Das Wiederanlaufverhalten eines Teil- oder auch Komplettsystems ist schon was rechts spezielles. Bei mir hängen BUS und TWS an unterschiedlichen USV-Systemen und nachdem ich meine PV-Anlage am Start habe, ist das mit dem Ersatzstrom noch mal deutlich entschärft. Wird also nur noch dann zum Thema, wenn ich eine Komponente gewollt neu starte, oder der Gesamtstrom komplett weg war.

Beste Grüße
Jens

[gbglace]

Da liegt noch ein grundlegendes Missverständnis zur Funktion des KNX vor.

Nix und niemand im KNX fragt irgendein Gerät oder KO aktiv ab. Einzige Ausnahme ist die ETS in der Diagnose und beim Programmieren von Geräten, weil dann aktiv PA also Geräte mit den Telegrammen adressiert werden.

Auch ein X1 wird das so niemals tun.
was ein X1 dann aber mit dem gesetzten Häkchen tut ist je GA eine Leseanfrage senden (Readrequest). Und bestenfalls kommt genau nur eine Antwort von genau einem Gerät zurück, welches Gerät/KO das ist kann/muss/wird der X1 niemals wissen. Multicast-Prinzip des KNX.

Ein echtes vollwertiges KNX-Gerät, welches keine bunte UI wie der X1 mit Häkchen usw. hat sich standardkonform aber auch bei Reboot den aktuellen Wert besorgen.

Laut Standard kann dies mit dem I-Flag an einem KO realisiert werden. Bedeutet das bei Reboot eines KO, dann dieses ein solches Readrequest Telegramm mit der ersten verknüpften GA sendet. Ein anderes Gerät/KO mit einem gesetzen L-Flag wird dann mit einem entsprechenden Readresponse Telegramm antworten, hier aber obacht ein solches KO kann zwar die Anfrage zu GA 1/1/1 sehen und wird aber auch immer nur mit der ersten verbundenen GA antworten, was dann auch mal 25/3/230 sein kann. Also kicht wundern wenn man einen Readrequestvzur 1/1/1 sender aber mit einer andren GA eine Antwort erhält.

Wichtig ist dann noch, dass das KO welches die Anfrage sendet auch das A-Flag gesetzt bekommt, da es sonst nicht die Antwort (Readresponse) in sich aufnimmt. Denn ein S-Flag bedeutet das nur die normalen Telegramme aufgenommen werden.

Gibt es also ein Reboot des gesamten Busses oder nur des TWS, wird die passende Kombination von I-Flag, L-Flag und A-Flag dafür sorgen, dass der TWS bei Reboot für eine GA einen validen Zustand erhält.
Weitere Bedingung ist dabei aber auch, das jenes Gerät welches antworten soll, bei kompletten Busreboot schon vor dem TWS fertig gebootet ist, sonst gehen die Anfragen natürlich auch ins Leere.

Ist der Wert dann im TWS aktuell, wird Stefan sicher noch erklären wie ein reboot des Visusubsystems oder ein reconnect eines Visuclients zu validen Werten aus dem TWS Objektsystem kommt.

Die Visu ist ja kein anderes Gerät. Und die Visu generiert ja keinen Status, die nimmt aktive Aktionen entgegen (Tasterdruck) oder gibt andere Zustände Werte wieder, halt Visualisierung von etwas. Insofern benötigt sie keine eigene Persistierung wie die Logikengine, die eben eigene Werte unabhängig vom KNX generiert.

Die geteaserten Minizeitreihen kommen sicher eh aus der Timeseries Datenbank.

Hier könnte dann zwar die Visu sich auch den zuletzt am TWS angekommenen Wert ziehen aber das würde eben nicht die Falle abdecken wo nur TWS seitig die Verbindung zum KNX unterbrochen war. Daher kann man dann hier im KNX mit den Flags entsprechend reagieren und sich Sicherheit verpassen.

Bei MQTT gibt es ähnliche Mechanismen, Modbus muss aktiv abgefragt werden.


Das I-Flag ist bei allen Geräten die ich so kenne auch nicht nur gut versteckt, sondern auch meist deaktiviert. Ist auch nicht verkehrt, denn sonnst kommt so mancher Bus bei Reboot nicht mehr in die Spur wenn alles an Geräten erstmal alles für sich abfragt und dann noch Antworten generiert werden.
Aber ja das Wissen um dieses Flag macht das Leben deutlich einfacher.