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

[StefanW]

Enrico,

Es wäre schön statt viel bla mal eine saubere Antwort zu bekommen. Ja ist notwendig/sinnvoll oder eben nicht.

so gehen wir hier nicht miteinander um!

Tatsächlich hast Du Deine Frage unklar gestellt, weil Deine Frage sich vor allem auf den Neustart bezogen hat. Hier spielen die vielen genannten Details zu Flags usw. durchaus eine Rolle.

Die Mühe der Foristen, die Dir die tatsächlich technisch wirksamen Zusammenhänge erklären wollen, mit "Bla" abzustempeln empfinde ich als unhöflich.

Ich möchte Dich bitten, die Forenregeln einzuhalten.

Stefan

[zoonuser]

Stefan,

ich empfand auch einige Erklärungen sehr unschön, teilweise beleidigend. Ich hatte mehrfach darum gebeten, die Frage nach der Verknüpfung Status KO zu beantworten. Belehrungen, ob mit ohne USV Stromversorgung BUS oder eine Flagerläuterung passten nicht. Ich weiß nicht warum ich mich falsch ausgedrückt haben soll. Siehe Bild, Auszug von einem Standard KNX Herstellerhandbuch. Da steht "Status" und nicht Rückmeldeobjekt. Da kann ich nicht riechen, dass die TW Welt eine andere Sprache benutzt.

[gbglace]

Es wäre schön statt viel bla mal eine saubere Antwort zu bekommen. Ja ist notwendig/sinnvoll oder eben nicht.

Naja müssen tut da gar nichts.
Die Visu wird das anzeigen was man Ihr als Input anbietet.
Sinnvoll ist es aber natürlich eine explizite Status/Rückmelde GA im Projekt zu nutzen.

Man kann auch einfach das Schalt-KNX-Objekt zweimal verbinden, das funktioniert auch, nur zeigt die Visu dann eben an, das man zuletzt mit der Visu oder irgendeinem anderen Gerät mit der gleichen GA einen Befehl gesendet hat und nicht dass was der Aktorkanal zuletzt bei sich umgesetzt hat unabhängig davon was er an Befehlen so erhalten hat.

ggf will man ja explizit auch die Funktionen trennen und verbindet als Statusmeldung für die Visu einen Aktorstatus von Kanal3 des Aktors, sendet aber seine schalten GA immer nur an Aktor Kanal7, die sinnstiftende logische Verbindung von Kanal3 zu Kanal7 erfolgt dann ggf. über ganz andere Sachverhalte.

Also in anderer Weise, ja ein Widget als UM-Schalter konfiguriert wird mindestens zwei Objekte benötigen, ein Objekt über den die Aktion ausgegeben wird und ein Objekt über den der Schaltzustand ausgegeben wird. Was man an das jeweilige Widget-KO anbindet ist egal, es muss dann nur vom Datentyp passen.

Und ja wir antworten gern recht generisch, weil der TWS eben sehr viel Flexibilität bietet.

Wir sind auch bemüht die weiteren Sachverhalte zu erklären und die Visu ist ein TWS-Subsystem und ist damit erstmal ganz losgelöst vom KNX und dessen Sprachgebrauch.

Ich denke das passende Wording für die Anknüpfungspunkte an einem Visu-Widget ist noch nicht definiert. Aber offensichtlich sollte man nicht KO benutzen, da dies bei KNX-fokussierten Usern zu Fehlinterpretationen führt.

[StefanW]

Hi Enrico,

Siehe Bild, Auszug von einem Standard KNX Herstellerhandbuch. Da steht "Status" und nicht Rückmeldeobjekt. Da kann ich nicht riechen, dass die TW Welt eine andere Sprache benutzt.

ich habe auch oben "sorry" geschrieben, dass ich das mit Status nicht gleich verstanden habe, weil in meinem Schädel eben "Rückmeldeobjekt" verlinkt ist.

Hat aber nichts mit der TW-Welt zu tun. Ich habe das mal gegoogelt und zu KNX Rückmeldeobjekt gab es 1500 Fundstellen und zu KNX Statusobjekt 4500 Fundstellen (so über den Daumen). Ich habe auch Handbücher von KNX Herstellern gefunden, welche das Wording "Rückmeldeobjekt" in ihren Handbüchern benutzen.

Finde ich auch unschön, dass es hier ein doppeltes Wording gibt und künftig bin ich darauf auch sensitiviert. Wenn ich das noch anmerken darf, wir alle hier machen das kostenfrei, es darf uns erlaubt sein, dass unsere Antworten nicht der Erwartungshaltung entsprechen.


Nur zur Vervollständigung:

Was ich meinte ist, dass wir Deine Frage verstanden haben hinsichtlich erforderlich für die Situation "nach Neustart". Und es gibt einen Unterschied zwischen Normalbetrieb (alles ist gebootet und alles hat sich eingeschwungen in dem alle Nachrichten auf dem aktuellen Stand ausgetauscht wurden) und der Situation nach dem Neustart (wobei man hier tatsächlich unterscheiden müsste, was in welcher Reihenfolge hochkommt und die Situation nach einer Sekunde ist eine andere als nach 10 Sekunden und nach mehreren Minuten, wenn der Sturm am Bus vorüber ist). Und genau das letztere, also die Steuerung nach Neustarts in diversen Szenarien kann zunächst zu falschen Anzeigen führen, da einfach sich noch nicht alles gegenseitig auf den neuen Stand gebracht hat und hier helfen die Flags ungemein, das zu optimieren.

Aus meiner Sicht bezog sich Deine Frage auf die Neustart-Situation, weil so ist der Thread bezeichnet und so ist Deine Eingangsfrage gestellt. Dies hat die Antworten dann in die Richtung bewegt.

Ich denke, es ist alles gut. Du hast Deine Antwort bekommen und diejenigen, die diesen Thread auch lesen und sich für die erweiterten Themen interessieren, haben für sich ein paar Infos bekommen zu Flags und was am TWS richtiger gemacht ist hinsichtlich KNX als alle anderen KNX Server.

Aus meiner Sicht ist alles ok.

lg

Stefan

[StefanW]

Hi Göran,

Wir sind auch bemüht die weiteren Sachverhalte zu erklären und die Visu ist ein TWS-Subsystem und ist damit erstmal ganz losgelöst vom KNX und dessen Sprachgebrauch.

Richtig. Die VISU lebt im Timberwolf Server und ist an dessen Objektsystem (und die APIs) gebunden. Die VISU kann - wie richtig von Dir erkannt - auch völlig ohne KNX genutzt werden. Es gibt kein Erforderniss für ein spezifisches Protokoll. Wer nur Shellys per MQTT, HUE und den Mähroboter per IFTTT sowie 50 1-Wire Sensoren in der VISU anzeigen und steuern will, kann dies so tun.

Ich denke das passende Wording für die Anknüpfungspunkte an einem Visu-Widget ist noch nicht definiert. Aber offensichtlich sollte man nicht KO benutzen, da dies bei KNX-fokussierten Usern zu Fehlinterpretationen führt.

In dem Eigenschaftendialog steht "Datenverbindung" und dann "Wert setzen" usw. Es handelt sich hier um VISU Objekte (genau genommen um "VISU Widget Objekte" in Abgrenzung zu "VISU Instanz Objekte" weil wir zwei Objektsysteme für die VISU haben).

Im KNX Subsystem nennen wir diese vollständig gerne "KNX Universalobjekte" oder "KNX Objekte", wobei wir auch "KNX Applikationsobjekte" haben (z.B. für Uhrzeit, die also fest verknüpft und nicht Universal sind).

So, jetzt schweifen wir aber vom Thema ab.

Ich denke, die Frage des TE wurde mehr als beantwortet.

lg

Stefan