ElabNET Technik Forum

EarlBacid hat geschrieben: ↑Sa Nov 16, 2019 8:07 pm Hierfür wäre eine Möglichkeit, Objekte persistent und readable zu erzeugen ein gewaltiger Vorteil

Nicht Vorteil - das ist ein Muss!

Für jeden "Zustand" (im Sinne der Regelungstechnik; auf Englisch: "State") muss es exakt eine Quelle geben die den kennt und dafür zuständig ist.
Beim Schaltaktor ist das simpel. Der kann auf "beliebig viele" GAs hören (z.B. eine für den Kanal selbst, eine für den Raum und außerdem ein Alles-Aus), aber es gibt nur eine GA die den Zustand des Schaltkanals enthält. Oft (und am saubersten) ist das dass Rückmelde-Objekt, kann aber ggf. auch mit der Schalt-GA zusammengefasst sein (dann ist das die erste GA in der ETS, alle anderen kommen dann danach).
Die GA für den Zustand braucht dann auch das Lese-Flag.

Wenn das so ist, dann wird die Visu auch den richtigen Wert anzeigen, ggf. aber erst minimal später, wenn der Zustand erst per Read abgefragt werden muss.

Wenn man nun Logiken hat, so gibt es hier auch Zustände. Z.B. den Temperatur-Soll-Wert beim Heizungsregler. Aber auch nicht ganz so offensichtliches, wie bei mir "Erzwinge-Wochenende" über das ich die Wohnung in den Wochenend-Modus zwingen kann um z.B. bei einem Urlaubstag auch unter der Woche den Rollladen erst hoch fahren zu lassen wenn ich ausgeschlafen habe.
Nun braucht es einen Master, der diesen Zustand speichert und jedem der es wissen will (-> Read Telegram) auch mitteilen kann. Das verlinkte StateSave-WireGate-Plugin macht genau dies.
Bei der TWS-LE gibt es inzwischen auch eine Persistenz, bei der ich hoffe, dass die dies kann. Und den Zustand natürlich auch über einen Neustart hinweg behält, nicht dass nach einem Stomausfall um 3 Uhr ich zu früher Zeit durch den Rollladen an meinem Urlaubstag geweckt werde

Robert_Mini hat geschrieben: ↑Sa Nov 16, 2019 7:30 pm 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

Genial.
Das funktioniert tatsächlich!

Habe

• neue Gruppenadresse angelegt, DPT 1.001
• neues Objekt in der TWS-App aktiviert und Gruppenadresse zugewiesen (Das Objekt hat per Default alle Flags gesetzt)
• per ETS Wert 1 geschrieben
• per ETS Wert gelesen -> es kommt die 1 zurück.

Nach ein bißchen nachdenken, fällt mir auf dass der Timberwolf Importer das 'L' Flag evtl. ein bißchen zu radikal gesetzt hat.
So sind bei mir z.B. ein paar Status-GAs von diversen Schaltaktoren verknüpft worden. Die soll der TWS ja aber nur empfangen, aber nicht verwalten.

Starte ich einen Read-Request auf so eine Status GA, bekomme ich zwei Antworten

• einmal vom Aktor
• einmal vom Timberwolf

D.h. ich werden nun das L Flag nur noch auf den Objekten belassen, die dem Timberwolf auch 'gehören'

• alle Objekte die mit 1-Wire verknüft sind
• meine neuen Objekte für binäre Zustände
• GAs, welche die Ergebnisse von Logiken enthalten

Ja das mit dem L ist letztlich auch an anderer Stelle aufgefallen und die Standardaktivierung für das L wird demnächst angepasst.

bluegaspode hat geschrieben: ↑Sa Nov 16, 2019 9:02 pm Genial.
Das funktioniert tatsächlich!

Um im Object Editor sieht man zu jeder Zeit den Wert des letzten Telegramms.

Was noch fehlt: Persistenz über einen Neustart hinweg.
Ich denke aber bereits nach, wie man hier die vorhandene Persistenz im LE verwenden könnte, so dass für ausgewählte Objekte ausschließlich nach dem Neustart der letzte gespeicherte Wert gesendet wird.

@S. Kolbinger: mir fehlt im Moment die Lösung den Neustart zu erkennen.
Up-Time des Servers als Teil des Zeitbausteins würde mir schon genügen.

Lg
Robert

Lg
Robert