Seite 1 von 2
'virtuelle' Schalter für Visu
Verfasst: Sa Nov 16, 2019 4:30 pm
von bluegaspode
Ich wollte schon immer mal folgendes umsetzen, bin mir aber unsicher, wie das mit den aktuellen Möglichkeiten sinnvoll geht:
- ich habe einen Timer, der die Weinachtsbeleuchtung ein/ausschaltet
- das ganze soll aber nur in der Weinachtszeit aktiviert sein - es reicht mir das manuell festzulegen - soll aber über einen Visu-Button passieren.
Für einen Visu-Button brauche ich eine KNX-Adresse auf die ich Werte schreiben kann aber auch eine Adresse, die auf Read-Request reagiert (falls die Visu mal neu gestartet wird).
Im alten Logikprozessor des Wiregate gab es dafür die "reply_to_read_requests=>1", die ich bisher genutzt hatte.
Kann ich was ähnliches auch mit der Logikengine des Timberwolf umnsetzen?
Das mit dem Timer später ist dann die einfachere Aufgabe. Wenn ich es richtig verstanden habe, nehme ich eine AND-Logik, mit Eingangswert '1' und triggere die mit einem Trigger-Eingang zu einer gewünschten Uhrzeit. Über einen 'Inhibit' Eingang könnte ich die Logik sperren -> basierend auf dem virtuellen Button in der Visu.
Re: 'virtuelle' Schalter für Visu
Verfasst: Sa Nov 16, 2019 6:36 pm
von StefanW
bluegaspode hat geschrieben: ↑Sa Nov 16, 2019 4:30 pmKann ich was ähnliches auch mit der Logikengine des Timberwolf umnsetzen?
Read-Requests in DIESER Form, also angefordert, werden derzeit noch nicht unterstützt.
Was der KNX Stack natürlich kann ist, wenn man per ETS die Objekte mit entsprechenden Flags versieht, dass beim booten des Stacks dann die Objekte durch Read-Requests geholt werden. Aber das findet nur beim Boot statt.
Ansonsten basiert KNX - vom Aufbau des Standards her - eben gerade NICHT auf Pollen, sondern auf Senden bei Wertänderung und gelegentlichem zyklischen Senden. Häufiges Pollen führt - je nach Größe der Anlage - zu einem überfüllten Bus und damit verzögerten Reaktionen.
Wir haben aber verstanden, dass dem ein oder anderen Anwender das Design des KNX Standard herrlich egal ist und er selbst darüber bestimmen möchte, dass er ihn auch totpollen kann und daher solche Funktionen gewünscht werden. Wir haben das in Planung, wenn wir den Stack einer Erweiterung / Überarbeitung unterziehen. Das kann noch ein paar Monate dauern.
lg
Stefan
Re: 'virtuelle' Schalter für Visu
Verfasst: Sa Nov 16, 2019 6:43 pm
von Robert_Mini
Hallo!
Stefan - in dem Fall liegst du falsch!!!
Einer der Vorteile eures zertifizierten Stacks ist die Tatsache, dass Objekte von Bus lesbar sind.
D.h. beim Start der Visu können genau diese GAs auch gelesen werden. Nach einem Restart der CometVisu sind so die virtuellen Schalter auch aktuell!!!
Für den Reboot des TWS fehlt da noch ein persistentes Glied, da denke ich noch nach.
Das Thema knxread aus einer Logik ist eine andere Thematik.
Lg
Robert
Re: 'virtuelle' Schalter für Visu
Verfasst: Sa Nov 16, 2019 6:44 pm
von Chris M.
Was hier benötigt wird ist genau das, wofür ich am WireGate dieses Plugin geschrieben hatte:
https://knx-user-forum.de/forum/öffentl ... #post16344
Ich dachte/hoffte das dass mit dem TWS Persistenz der Logik Engine gehen sollte. Bin hier aber nicht tief genug drinnen um das beurteilen zu können.
Re: 'virtuelle' Schalter für Visu
Verfasst: Sa Nov 16, 2019 6:49 pm
von Robert_Mini
@Chris M.: Siehe oben.
Robert
Re: 'virtuelle' Schalter für Visu
Verfasst: Sa Nov 16, 2019 7:12 pm
von StefanW
Robert_Mini hat geschrieben: ↑Sa Nov 16, 2019 6:43 pmEiner der Vorteile eures zertifizierten Stacks ist die Tatsache, dass Objekte von Bus lesbar sind.
ja, klar von außen kann der Stack natürlich schon gelesen werden.
Robert_Mini hat geschrieben: ↑Sa Nov 16, 2019 6:43 pmDas Thema knxread aus einer Logik ist eine andere Thematik.
Ja, hab das falsch erfasst, war in Gedanken schon bei einer Visu, die von innen über Objekte zugreift und nicht mehr über einen eibd arbeitet.... haben wir ja noch nicht,
lg
Stefan
Re: 'virtuelle' Schalter für Visu
Verfasst: Sa Nov 16, 2019 7:23 pm
von bluegaspode
Es geht konkret um die CometVisu du halt einen 'virtuellen' Schalter anzeigen soll, der über KNX geschrieben/gelesen werden kann.
Über KNX kann ich das dann natürlich auch mit dem Logik-Editor verknüpfen.
@Chris M. meinst du dieses Plugin läuft noch im Wiregate-Plugin-Container?
Ansonsten ist halt die Frage: wenn ich den Ausgang einer Logik mit einem KNX-Objekt verbinde. Was passiert mit einem KNX-READ auf dieser Adresse?
Erkennt der Timberwolf, dass dieses KNX-Objekt mit einer Logik (oder anderem Objekt) verbunden ist und beantwortet den READ-Request mit dem letzten Wert der Logik/Objekts?
Irgendwie muss sich die Visu initial ja die Werte holen.
Das wäre ja ebenso relevant, wenn eine Visu irgendein Berechnungsergebnis einer Logik anzeigen möchte.
Oder den letzten Wert eines WireGate Sensors?
Wenn die Visu gestartet wird, nachdem die Logik, der Sensor den Wert das letzte mal publiziert hat, muss sie den Wert ja auch ermitteln können, ohne zu warten, dass der Wert irgendwann mal wieder auf dem Bus auftaucht?
Re: 'virtuelle' Schalter für Visu
Verfasst: Sa Nov 16, 2019 7:30 pm
von Robert_Mini
Wenn du für den Schalter oder das Logikergebnis ein KNX Objekt anlegst und das L-Flag in der ETS setzt, dann holt sich die CV diese Werte mit einem read-request ab.
Alles out of the box
Robert
Re: 'virtuelle' Schalter für Visu
Verfasst: Sa Nov 16, 2019 7:36 pm
von Chris M.
@bluegaspode ich würde die aktuellste Version nehmen, zu finden unter
https://github.com/OpenAutomationProjec ... /StateSave
Spontan wüsste ich keinen Grund warum das im Container nicht laufen sollte.
Ziel sollte natürlich sein, dass mit einer TWS Logik zu ersetzen.
Grundsätzlich holt sich die "Visu-Anzeige" erst mal den Wert aus dem Cache im knxd, erst wenn der dort (nicht mehr) vorliegt, dann kommt ein Read Request. D.h. beim Öffnen der Visu im Browser muss nicht mal unbedingt ein Read-Request kommen.
Re: 'virtuelle' Schalter für Visu
Verfasst: Sa Nov 16, 2019 8:07 pm
von EarlBacid
Beim öffnen des Browsers nicht, aber es kam in letzter Zeit ja (zum Glück) des öfteren vor, dass es updates am Timberwolf und/oder der CometVisu gab, sodass am Ende der Docker und damit auch der knxd neu gestartet wurde.
Im Ergebnis habe ich anschließend eine Visu, bei der die Hälfte aller Schaltflächen einen undefinierten Zustand haben, weil die Objekte entweder sich entweder nur sehr selten ändern (tag/nacht, Fensterstatus, jahreszeit) oder gar nur von der Visu gesetzt werden (temp sollwertverschiebung, Diverse Sperrobjekte) und somit nie von einem anderen Teilnehmer niemals gesendet werden.
Hierfür wäre eine Möglichkeit, Objekte persistent und readable zu erzeugen ein gewaltiger Vorteil, und ich wüsste nicht, wie dieses Problem eleganter gelöst werden könnte. Derzeit muss ich nach jedem Neustart einmal alle Schaltflächen in der Visu betätigen um sie mit neuen werten zu initialisieren, wobei der letzte wert vom Bus, der dann z.b. Im Heizungsaktor aktiv war überschrieben wird.
Vg
Earl