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
