[DISKUSSION] Umsetzungsgedanken zu einer einfachen ZSU

[Chris M.]

Noch was anderes was für eine ZSU wichtig ist, was evtl. auf den ersten Blick übersehen wird und an dem einige Implementierungen (insb. bei NodeRed) scheitern:

Die Uhr muss Zustands- und nicht Event-Basiert sein.

D.h. zu jedem Zeitpunkt muss die Uhr wissen "welchen Wert" sie gerade hat und nicht nur zu den Schalt-Events den neuen Wert senden.
Nur so ist es möglich, dass unmittelbar nach einem Reboot der richtige Wert gesendet wird, der durchaus ein anderer sein kann als der letzte Wert der verschickt wurde (Reboot hat sich über einen eingestellten Zeitpunkt hinweg gezogen). Außerdem kann so ohne großen Aufwand auf Lese-Telegramme korrekt geantwortet werden.

[blaubaerli]

Hallo zusammen,

ich hatte mich ja schon mehrfach zum Thema Kalenderintegration geäussert. Das spielt m.E. unmittelbar in die ZSU-Diskussion hinein.

Es gibt da mehrere Themengruppen die adressiert gehören:

• Einfache zeitbasierte Termine
• Zeitfenster
• algorithmisch bestimmbare Termine (z.B. sonnenstandsabhängig)
• Alle nicht algorithmisch greifbaren Sondertermine (nächster Urlaubstag, oder nächster Schwimu-Besuch mit automatisch abgesenkter Temp im Gästerzimmer )
• statische, oder dynamische Offsets zu den bisher genannten Terminen

Wie schon erwähnt, kann das allein mit den Feiertagen schon ein Drama werden. Da was eigenes stricken zu wollen wäre wohl schlicht wenig sinnvoll. Da ist der Gedanke, ob man nicht "einfach" einen CALDAV-Container via App-Steuerung integrieren könnte. Dann kann jeder mit dem Kalenderfrontend seiner Wahl und den Abos seiner Wahl die erforderlichen Sonderevents im Kalender integrieren.

Wenn man das dann ohnehin macht, dann ist die Frage, welche der anderen Dinge man da auch mit unterbringen kann. Ich denke dann jetzt sogar mal so radikal weiter, dass man dann eine explizite ZSU im TWS womöglich sogar rauskicken könnte.

Also Gedanken darüber machen, wie man ggf. die Einträge im Kalender generiert bekommt und diese dann über eine Kalenderintegration für die Logikengine erreichbar machen. Die Herausforderung bei diesem Ansatz sind da sicher die algorithmisch bestimmbaren Termine.

Wer dann die ganz komplexen Dinge mag, kann sich ein ICS-File generieren im Kalender hochladen und fertig.

Aber Uhrzeiten und besondere Events Im Kalender eintragen, dass sind Dinge, dass auch für nicht TWS-erfahrene Familienmitglieder lösbar sind.

Ich will aber gar nicht daran denken, was bei noch nicht sauber umgesetztem Berechtigungssystem abgeht, wenn der pubertierende Sprössling Zugriff auf die Oberfläche des Wolfes bekommt...

Beste Grüße
Jens

[starwarsfan]

Hallo miteinander, hallo Chris

D.h. zu jedem Zeitpunkt muss die Uhr wissen "welchen Wert" sie gerade hat und nicht nur zu den Schalt-Events den neuen Wert senden.
Nur so ist es möglich, dass unmittelbar nach einem Reboot der richtige Wert gesendet wird, der durchaus ein anderer sein kann als der letzte Wert der verschickt wurde (Reboot hat sich über einen eingestellten Zeitpunkt hinweg gezogen). Außerdem kann so ohne großen Aufwand auf Lese-Telegramme korrekt geantwortet werden.

Bist Du Dir da sicher? Wenn die Zeitschaltuhr fünf Schaltvorgänge übersprungen hat, dann werden diese nach dem Reboot direkt nachgeholt? Also eine "Nachzeitpunktnachholschaltuhr"?
Also ich möchte das auf keinen Fall so haben! Eine Zeitschaltuhr soll zu definierten Zeitpunkten Schaltfunktionen auslösen. Damit möchte ich aber nicht, dass sie aus welchen Gründen auch immer "übersprungene" Schaltvorgänge "nachholt".

[starwarsfan]

Hallo miteinander,

nur so als Diskussionsanregung und für diejenigen, welche die Edomi-ZSU nicht kennen, hier eine Kurzbeschreibung derselben.

In der Visu habe ich bspw. dieses Widget:

2021-03-27_Zeitschaltuhr01.png

Das ist die ZSU für R2D2, unseren Staubsauger. Der startet also Mo/Mi/Fr um 9:00 Uhr. Will ich nun einen weiteren Eintrag hinzufügen, tipp auf das + und dann sieht das so aus:

2021-03-27_Zeitschaltuhr02.png

Oben links Zeit eingeben, gewünschten Tag selektieren und wenn es ein Zeitraum sein soll, dann auch noch Start- bzw. Ende-Tag/Monat/Jahr eingeben. Diese Einträge sind jeweils optional. Im obigen Beispiel also jeden Dienstag um 16:00 Uhr. In der Zeile darunter wird ein vorab konfiguriertes Makro ausgewählt, welches zu diesem Zeitpunkt ausgeführt werden soll. In dem Fall gibt's nur "Roborock starten" aber das können beliebig viele sein, welche dann hinten dran völlig unterschiedliche Aktionen durchführen.

[Chris M.]

D.h. zu jedem Zeitpunkt muss die Uhr wissen "welchen Wert" sie gerade hat und nicht nur zu den Schalt-Events den neuen Wert senden.
Nur so ist es möglich, dass unmittelbar nach einem Reboot der richtige Wert gesendet wird, der durchaus ein anderer sein kann als der letzte Wert der verschickt wurde

Bist Du Dir da sicher? Wenn die Zeitschaltuhr fünf Schaltvorgänge übersprungen hat, dann werden diese nach dem Reboot direkt nachgeholt? Also eine "Nachzeitpunktnachholschaltuhr"?

Nein, natürlich sollen nicht auf einen Schlag alle Werte kommen die sich zwischenzeitlich aufgestaut haben.
Aber ich will, dass wenn die Logik neu startet der zu diesem Zeitpunkt gültige Wert geschickt wird.

Beispiel, einfache Regel die ab 6 Uhr "An" und ab 9 Uhr "Aus" festlegt:
So lange die Logik läuft kommt offensichtlich um 6 Uhr 1x ein "An" und später um 9 Uhr das "Aus".
Jetzt kommt um 3 Uhr ein Lese-Telegramm auf die der ZSU zugehörigen GA, dann soll mit einem "Aus" geantwortet werden (eigentlich auch noch simpel, aber daran scheitern schon manche)
Und wenn um 5:55 Uhr der Strom bis 6:05 Uhr ausfällt und der TWS danach neu startet, dann soll (wenn konfiguriert) mit dem Start ein "An" Telegramm verschickt werden.