KNX Data Secure Unterstützung
für KNX Logger und KNX Busmonitor

KNX Diagnose Monitor, Import des ETS Projektes deutlich beschleunigt, Suche in der Navigation
Mehr Informationen dazu hier im Forum

Insider Version 6 zur 4.5 jetzt für alle Mitglieder des Insider Clubs installierbar
Alle Infos zum Update im Timberwolf Wiki

[Problem] [V4.0.1] Status eines Schalten-Widgets: falsche Darstellung in der Detailanzeige

Hier informieren wir über die Timberwolf Visu (die frühere Arbeitsbezeichnung war "Instant Visu"). Dies ist die im Timberwolf Server ab V4 enthaltene Visualisierung, die sich vor allem dadurch kennzeichnet, dass diese zum einen besonders einfach einzurichten ist und zum anderen durch die hohe Integration deutlich erweiterte Leistungsmerkmale bietet.
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten
Benutzeravatar

Ersteller
speckenbuettel
Reactions:
Beiträge: 384
Registriert: Mo Jun 27, 2022 9:30 am
Hat sich bedankt: 298 Mal
Danksagung erhalten: 220 Mal

[V4.0.1] Status eines Schalten-Widgets: falsche Darstellung in der Detailanzeige

#1

Beitrag von speckenbuettel »

Hallo,

ich verwende ein Schalten-Widget, um über die Detailanzeige meine Alarmanlage (ABB Sicherheitsmodul SCM/S1.1) scharf bzw. unscharf zu schalten.

Die Wert-Setzen-Quelle ist verknüpft mit dem Status-KO des Sicherheitsmoduls, das Wert-Setzen-Ziel ist verknüpft mit dem Schaltbefehl.

Wenn ich nun über die Detailanzeige die Anlage scharf schalte und die Scharfschaltung aus irgendeinem Grund nicht funktioniert, dann steht beim nächsten Öffnen der Detailanzeige der Schalter trotzdem auf "Ein":
Bild

Obwohl sich der Status der Anlage nicht geändert hat, das entsprechende KNX-Objekt ist weiterhin false:
Bild

So sehen die Verknüpfungen des Widgets aus:
Bild


Ich würde eigentlich erwarten, dass bei jedem Öffnen der Detailanzeige der Status des Schalters gemäß der Wert-Setzen-Quelle angezeigt wird.

Das ist ja nichts anderes als würde ich z. B. mit dem Widget einen KNX-Aktor bedienen, der geschaltet wird und der ein Statusobjekt zurückgibt.
Wenn der Aktor aus irgendwelchen Gründen nicht schaltet, dann ändert sich auch das Statusobjekt nicht.

Die Anzeige (verknüpft über Wert-Anzeige) wird übrigens korrekt dargestellt, diese wechselt nicht auf scharf.

Ich habe dieses Phänomen gerade mit Widgets auf der Alarmanlagenseite meiner Visu des öfteren gemacht, aber heute habe ich etwas Muße, das Verhalten systematisch nachzustellen und zu dokumentieren.

Hat jemand eine Idee, woran die falsche Darstellung (in der Detailanzeige) liegen könnte?

Vielen Dank und viele Grüße
Falk
Vielen Dank und viele Grüße
Falk

TWS 3500M ID:810 - VPN aktiv - Reboot nach Absprache
1-Wire, KNX (MDT u. a.), EnOcean (Eltako u. a.), Gira TKS, ekey multi

ms20de
Elaborated Networks
Elaborated Networks
Reactions:
Beiträge: 1267
Registriert: Sa Aug 11, 2018 9:14 pm
Hat sich bedankt: 358 Mal
Danksagung erhalten: 696 Mal

#2

Beitrag von ms20de »

Hallo Falk,

wenn ich den Fall richtig verstanden habe, dann würde dir aktuell eine Und Logik weiterhelfen.
Den Eingang der Logik bildet KNX 1713 und KNX 1723, der Ausgang wird alleinig mit dem Eingang von Wert Setzen verbunden.
Nur wenn eingeschaltet wurde und der Aktor eingeschaltet zurückmeldet, dann wird auch der Schalter in der VISU auf den Ein-Zustand gesetzt.

Es ist geplant in der VISU für den Sende-Assistenten eine Konfiguration anzubieten, für den Fall wenn der gesendete Wert nicht den Rückmelde-Werte entspricht. Von einfacher Übernahme des Wertes bis zum Auslösen eines Fehlerzustandes kann dies nach konkreter Einbausituation alles sein.

Viele Grüße,
Matthias
Zuletzt geändert von ms20de am Mo Aug 12, 2024 12:16 pm, insgesamt 2-mal geändert.
[ Timberwolf Entwicklung ]

TWS 2400 ID:102 VPN offen, Reboot auf Nachfrage
TWS 3500 ID:695 VPN offen, Bitte kein Reboot ohne Absprache

gbglace
Reactions:
Beiträge: 4088
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1415 Mal
Danksagung erhalten: 1901 Mal

#3

Beitrag von gbglace »

Die interne Umschaltfunktion und dessen Wert zu verwenden ist ja OK, so lange keine externe Verbindung besteht. Sowie aber eine externe Verbindung besteht sollte dann auch nur noch das angezeigt werden was da angeliefert wird und nicht mehr die eigene Bedienung.

Sollte warum auch immer (Fehler auf der Signalstrecke oder Logik im Zielgerät), keine Reaktion erfolgen darf sich das eben an der Visu nicht von sich aus Ändern, wenn man auf OFF drückt.

Ein Plausibilitätsabgleich Sende-Wert vs Statuswert ist interessant aber kann auch viel Verwirrung stiften.
Alle Ziele mit Ein-/Ausschaltverzögerungen, Treppenlichtfunktionen oder grundsätzlich weitere Bedienstellen neben diesem Visu-Widget TWS, führen ja zwangsweise zu Abweichungen.

Und alle Verzögerer haben dann eben den Knopf noch auf ON auch wenn OFF gedrückt wurde und die Ausschaltverzögerung im Aktor läuft. Den Status vom Aktor bekommt man dann halt erst nach deren Ablauf geliefert und dann darf das Widget auch auf OFF wechseln.

Die Knöpfe der Visu mit Sendeverzögerungen versehen bin ich unschlüssig. Da man zumindest im Ziel KNX mit sowas keine saubere Trennung mehr hat wo was passiert. Parametrierung Aktor (ein Ausschaltverzögerung) vs eine TWS-Logik oder ETS-Logik mit Verzögerern vs ein Parameter am Visu-Knopf.
Grüße Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#PV 43,2 kWh Akku; 3x VE MP2 5000; 6,7 kWp > 18 Panele an 4x HM1500 + 1 HM800 WR; Open-DTU
Benutzeravatar

Ersteller
speckenbuettel
Reactions:
Beiträge: 384
Registriert: Mo Jun 27, 2022 9:30 am
Hat sich bedankt: 298 Mal
Danksagung erhalten: 220 Mal

#4

Beitrag von speckenbuettel »

Hallo Matthias,

vielen Dank für den Tipp. Die Logik hilft erstmal weiter.

Die Idee mit dem Sende-Assistenten ist gut. In manchen Fällen würde es ebenfalls ausreichen, wenn das Widget für die Anzeige den Wert vom Dispatcher abholen kann. Vermutlich ist das technisch eher aufwendig, aber wenn z. B. nach einer gewissen Zeit nach einem Schaltbefehl kein neuer Zustand kommt, würde eine aktive Abfrage des Quell-Objekts zumindest dafür sorgen, dass der korrekte Zustand angezeigt wird.

Das ist m. E. besser als ein Plausibilitätsabggleich in der Visu. Im Idealfall kann man das Abfragen des Status für jedes Widget aktivieren oder deaktivieren, um dem von Göran angesprochenen Problem aus dem Weg zu gehen. Überall dort, wo irgendeine Art von gewollter Verzögerung eingebaut ist, sei es durch eine Logik, eine Schaltverzögerung im Aktor oder eben eine Treppenlichtfunktion, würde eine automatische Korrektur bzw. Abfrage natürlich zu Verwirrung und teilweise ungeplantem Verhalten führen.

Vielen Dank und viele Grüße
Falk
Vielen Dank und viele Grüße
Falk

TWS 3500M ID:810 - VPN aktiv - Reboot nach Absprache
1-Wire, KNX (MDT u. a.), EnOcean (Eltako u. a.), Gira TKS, ekey multi
Antworten

Zurück zu „Timberwolf Visu“