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

[StefanW]

Hallo Enrico,

Neustart absichtlich oder unabsichtlich (z.B. bei Stromausfall) vom TW bzw TW Visu.

Fangen wir mit dem einfachsten an:

Die TW-VISU startet man eigentlich nicht neu, außer man würde den Dienst neu starten. In diesem Fall ließt das TW VISU Subsystem alle verknüpften Objekte aus dem Objektsystem ab und damit sind alle VISU Clients wieder auf dem aktuellen Stand.

Wenn der TW neu startet, dann ließt er die zuvor gesicherten Daten des Objektsystems von der SSD (ja, die sind remanent, zumindest auf 10 Minuten genau, dieser Wert wird womöglich noch angepasst). Die danach startende VISU kennt dann wieder die zuletzt gespeicherten Objekte (und auch die letzte bekannte Aktualisierungszeit). Der Punkt hier ist allerdings, dass ein Server auch vor einer Woche heruntergefahren sein konnte und damit - aus aktueller Sicht - recht alte Werte abgelegt hat.

Das das Objektsystem mit aktuellen Werten versorgt wird, ist Augabe der jeweiligen Subsysteme. Also KNX, Modbus, MQTT, 1-Wire usw. müssen anlaufen und entsprechend ihre Arbeit tun und aktuelle Werte einspeisen. Es geht also nicht nur um KNX.

Bei unabsichtlich verhält es sich gleich einem BUS Reset.

Nein. Ein durch Stromausfall (oder sauberem Herunterfahren) abgeschalteter Timberwolf Server löst keinen Reset am KNX Bus aus. Der Server verhält sich wie jeder normale andere KNX Teilnehmer. BUS Reset sind Funktionen von KNX Spannungsversorgungen und eigentlich nur ein etwas längerer Kurzschluss.

Einzelgeräteneustart ist ebenso interessant.

Nun, allgemein kann man es nicht sagen, weil das kommt ein wenig auf das KNX Gerät an. Manche sind völlig autark, andere benötigen zunächst Werte von anderen Geräten. Ansich sind dafür die Flags da, sie spielen - neben anderen Einstellungen hinsichtlich "Busspannungswiederkehr" - eine große Rolle. Hierbei ist der Unterschied zwischen KOs und GAs und insbesondere der "Sending GA" zu beachten.

Hat aber nichts mit der Visu zu tun. Diese bekommt ja gar nicht mit, dass ein einzelner Teilnehmer fehlt, es gibt keine generelle Funktion hierfür. Wir planen allerdings, dass man Timeout Anzeigen in der Visu setzen kann, die auf alte Werte aufmerksam macht.

Im Kern ist es Aufgabe eines jeden neu gestarteten Geräts, die jeweils aktuellen Werte zu senden.

Vielleicht verhält es sich wie bei Logiken welche Persistent sind und die VISU merkt sich alles.

Richtig, das Objektsystem merkt sich im Rahmen der Möglichkeiten alles und die VISU kann darauf zurückgreifen.

[StefanW]

Hi Göran,

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

Es ist nicht die "erste verbundene GA" sondern die "Sending GA".

Zwar ist die "Sending GA" oft die erste verbundene GA, aber das muss nicht so sein, weil man in der ETS bei der Liste der GAs eines Objektes separat festlegen kann, welche davon die "Sending GA" ist. Das kann also jede sein, daher drauf achten in der ETS. Oder im Timberwolf Server, weil wir die Sending GA dort hervorgehoben anzeigen.

Nur damit keine Missverständniss entstehen.

lg

Stefan

[gbglace]

Moin Stefan,
Das macht die ETS ganz clever, wenn man die Sending Eigenschaft verändert, dann sortiert die ETS auch direkt die Reihenfolge der angebundenen GA um und holt diese an die erste Stelle, auch wenn man sie irgendwann mal als vierte erst angebunden hatte und dann irgendwo mittig oder am Ende der verbundenen GA hatte.

Aber ja ganz präzise ist es die sending GA begrifflich zu verwenden, optisch orientiert geht auch erste. Praktisch wird der Anfänger nie an der Eigenschaft spielen und dann ist/war es auch die zuerst verbundene GA.

Und man darf dieses S und diese Spalte in der Geräteansicht nicht als S-Flag des KO Missverstehen.

[zoonuser]

Guten Morgen Stefan,

die TW VISU braucht keine Objekte zu einem Status KO von beliebigen KNX Gerät. Bitte einfach bestätigen mit ja oder nein. Das finde ich einfacher, wie ganze Diskussion vorher. Ich weiß nicht wie eure Strukturen in der ETS aufgebaut sind, aber 95% meiner KNX Geräte (75 Stk) haben ein Status KO in einer jeweiligen eigenen GA.
Thema X1. Er braucht immer eine Status GA, sonst stimmen die Zustände bis zur ersten Änderung nicht. Es war einfach nur eine Frage, braucht die TW VISU einen Status KO Verknüpfung oder nicht. Siehe Überschrift.
Die Flag Diskussion i.M.n. hier nicht richtig. Ihr schreibt immer sofort, wenn es nicht zum Thema passt. Hier wird an einigen Stellen am Thema vorbei diskutiert.
Ich hatte im ganzen VISU Thema bisher den Eindruck, es soll einfach sein. Flag Anpassungen in der ETS sind sicherlich nicht ganz einfach und haben großes Fehlerpotential.

[blaubaerli]

Hallo Enrico,

sorry, die Situation ist aber nicht wirklich so simpel. Das hat aber überhaupt nichts mit dem TWS zu tun oder der Visu. Grundsätzlich versuchen wir hier die Antworten in der Regel so zu verfassen, dass Mitlesende das für ihre Situation adaptieren können. Daher hier eventuell die etwas "bohrend" wirkenden Nachfragen.

Wir könnten auch provokant sagen "nein brauchst du nicht. Stelle doch bei all deinen sonstigen KNX-Devices das zyklische Senden der Werte auf den Bus ein." Das würde aber völlig am Thema vorbei gehen, weil damit das Ziel zwar womöglich auch erreicht würde, aber dann bei dir der Bus zugemüllt würde.

Also wenn du nur auf einen kurzfristigen Reboot des TWS reagieren möchtest, dann wird die Timberwolf Visu die Daten aus der Datenbank des TWS bedienen. In den Screenshots der Visu ist auch zu erkennen, dass sich hier das Alter der Information pro Datum darstellen lässt bzw dargestellt wird.

Willst du einen kompletten Neustart des kompletten BUS also inkl. aller Teilnehmemer anch nach einem längeren Stromaussfall sicherstellen und dann gewährleisten, dass du an der Visu asap wieder die aktuellstmöglichen Werte siehst und das Thema mit möglichst geringer Buslast umgesetzt wird, dann setzt du die entsprechenden Status-Objekte ein. Das ist dann aber auch nur ein Teil der Wahrheit, weil dann die Flags schon sauber gesetzt sein solten um das perfekte Ergebnis zu erreichen.

Damit ist die Antwort leider ein "Jein".

Beste Grüße
Jens

[zoonuser]

Hallo Jens,

ok. Dann teste ich zu gegebener Zeit, was in meinen Situationen alles passiert und entscheide dann, welche Lösung am effektivsten ist.
Und richtig, zyklisches Senden habe ich nur bei zwei Geräten von 75. Da brauche ich es leider unbedingt. Mein Buslast liegt immer hohen einstelligen und manchmal im kleinen zweistelligen Bereich. Da soll sie auch bleiben.

[gbglace]

Der X1 ist halt nur ein teilen ein KNX-Gerät mit voller Applikation für alle Objekte. Da sagts Du ihm halt in seiner internen UI das Du zu diesem Datenpunkt einen Status per GA zur Verfügung stellen kannst und ob dieser dann bei Neustart des X1 aktiv abgefragt werden soll.

Aber auch im X1 hat das erstmal nichts mit der Visu zu tun, denn das braucht es auch wenn diese KNX-Objekte nur in der X1 Logik Verwendung finden sollen.

Im TWS ist es vom Prinzip her alles das selbe, nur das dieses Verhalten der Datenbeschaffung nicht in der Visu konfiguriert wird, wo es ja auch nichts zu suchen hat. Sondern da wo es hingehört beim Verhalten des KNX-Objektes. Und da unterscheiden sich dann TWS und X1 fundamental, da der TWS an der Stelle die gesamte KNX-Kommunikation wie jedes andere normale KNX-Gerät auch bewerkstelligt und konfiguriert wird, in der ETS.
Auch etwas komplexere Taster die etwas anzeigen sollen müssen entsprechend parametriert werden und an Ihren Status-KO's die entsprechenden GA verbunden werden. Beim TWS machst Du es eben genauso, Du richtest ein KO für die Aktion einer Tasterfunktion und ein KO für ein Rückmeldeobjekt ein, um eine saubere UM-Schaltfunktion in der Visu abbilden zu können. Dann verbindest an diese beiden KO jeweils die passende GA in der ETS und setzt die Flags richtig.

Das mag im ersten Moment aufwändiger sein, resultiert aber daher, dass der TWS eben 2000-ganz individuelle KO bereitstellt und diese beliebig Status AN/AUS oder mal Zählerstand in kWh sein können, da ist nix vordefiniert.

Sollten diese Grundlagen der KNX-Konfiguration der Masse an User zu aufwändig erscheinen und eine extreme Bremse des Verkaufserfolges des TWS sein, dann denke ich kommen die Ideen eines TWS internen Editors, der sich dann die ETS-Parameter quasi selbst in den KNX-Stack programmiert wieder nach weiter vorne auf den Tisch, nur muss dass dann auch irgendwie ins ETS-Projektfile selbst, damit die Oberfläche in der ETS auch wieder in Synch ist mit der Programmierung des TWS selbst.

Es ist im X1 an der Stelle etwas einfacher, weil der X1 an der Stelle sich nicht wie ein natives KNX-Gerät verhält. Daher braucht man beim X1 in anderen Linien auch immer gleich einen Dummy, weil der LK sonst nichts davon mitbekommt, das es da noch ein Gerät gibt welches mit bestimmten GA etwas anfangen will.

Die Visu greift intern einfach auf das Objektsystem des TWs zu, da ist es der Visu erstmal vollkommen egal aus welcher Quelle der Wert herkommt. Und je Quelle muss der User dann halt wissen wie er sich einen konsistenten Status besorgt/erzeugt. Der TWS ist auf Ebene KNX mehr eine KNX-Gerät als ein X1 aber insgesamt auch wieder weniger weil er ein absoluter Multiprotokoll-Server ist und auch super in einer Umgebung ganz ohne KNX funktionieren würde und das umso mehr, wo er eine Visu bietet. Da kann man sich auch ein Smarthome ganz auf Basis von Shellys und Hue HW zusammenbasteln und mit dem TWS bedienen.

[zoonuser]

Hallo Göran,

super du hast mega viel geschrieben aber die Frage ist trotzdem nicht beantwortet. Braucht die TW Visu ein Objekt zu einer Status GA/KO vom KNX Gerät oder nicht. Es geht mir nicht um den Aufwand. Ich möchte nur keine Arbeiten ausführen, welche nicht benötigt werden. Es wäre schön statt viel bla mal eine saubere Antwort zu bekommen. Ja ist notwendig/sinnvoll oder eben nicht.

[StefanW]

Hallo Enrico,

die TW VISU braucht keine Objekte zu einem Status KO von beliebigen KNX Gerät. Bitte einfach bestätigen mit ja oder nein.

Nein.

Aber diese doppelte Verneinung finde ich jetzt fast unverständlich.

Daher:

1. Ich habe JETZT erst mit diesem Post verstanden, dass Du mit "Status"-Objekten eigentlich die "Rückmelde"-Objekte meinst. Gebräuchlich sind beide Bezeichnungen, wir verwenden intern bei uns nur den Begriff "Rückmelde"-Objekt, daher hat Status-Objekt bei mir zuwenige Synapsen getriggert. Sorry.

2. Für eine korrekte Darstellung z.B. des aktuellen Status eines Aktors in der VISU BENÖTIGT diese auch dieses Statusobjekt, dass den aktuellen Status rückmeldet.

==> JA, die VISU (jede) benötigt für eine korrekte Anzeige eine entsprechende Information. Hierfür ist die Sending-GA der jeweiligen Status-Objekte mit jeweils einem KNX-Objekt des Timberwolf Servers zu verbinden und in der Visu dann beim entsprechenden Widget mit dem Status.

Aber:

Die Verbindung des Statusobjektes zur Rückmeldung ist eine Selbstverständlichkeit für alle diesbezüglichen Anzeigen (egal ob es eine VISU ist oder ein Glastaster, bei dem z.B. ein Glühbirnen-Symbol aufleuchtet, wenn das Licht - über welche GA auch immer - eingeschaltet wurde, sofern man nicht nur nach dem mithören gehen will).

Daher haben wir haben Deine Frage vor allem bezüglich den Neustart diverser Komponenten bezogen. Und hier spielen dann die Flags eine wichtige Rolle, weil darüber sich das "Abfragen des aktuellen Status" im KNX-Subsystem steuern lässt und auch bei den KNX Geräten, welches denn nun Antworten soll. Hängt aber auch damit zusammen, was die einzelnen KNX Geräte hinsichtlich "Busspannungswiederkehr" in der Applikation anbieten.

==> Eine pauschale Aussage ist daher nicht möglich.

Beispiel: Weil wenn man ein Treppenhauslicht hat, deren sechs Leuchtmittel von drei Aktorkanälen gesteuert wird, dann muss man schon überlegen, welcher Kanal denn nun den Status senden soll? Und das kann man z.B. mit den Flags einstellen.

Ich hatte im ganzen VISU Thema bisher den Eindruck, es soll einfach sein. Flag Anpassungen in der ETS sind sicherlich nicht ganz einfach und haben großes Fehlerpotential.

Zusammenfassend:

1. Status-Objekt mit VISU Widget verknüpfen ist die Pflicht

2. Die Flags für die Steuerung der Feinheiten ist die Kür

Ja, das mit den Flags muss man richtig machen. Bei der Einführung des Timberwolf Servers mit der damals üblicherweise verwendeten Comet Visu kam es immer wieder zu komischen Darstellungsfehlern bei verschiedenen Neustarts, die sich größtenteils mit den richtigen Flags lösen haben lassen. Daher erwähnen die Granden des Forums dies auch, weil das eine wichtige Erkenntnis damals für viele Foristen war.


lg

Stefan

[zoonuser]

Hallo Stefan,

danke für die eindeutige klare Antwort. In der ETS Welt heißt das Status/Rückmelde KO - Status. Daher meine Frage mit dem Status welche nun geklärt ist.

Grüße