Urlaubsmodus für Shelly-Geräte mit Zeitplan gesucht

    Hallo Zusammen,

    Ich habe bei mir diverse Shelly-Geräte welche mit Zeitplan betrieben werden ... vorrangig TRVs, aber auch Plug S und Shelly 1.

    Nun würde ich gern den Zeitplan für die Dauer von Abwesenheiten definiert aussetzen.

    Die TRVs bieten zu mindest verschiedene Profile an zwischen welchen man wechseln kann. Das hat den Vorteil, dass ich nicht jedes "Ereignis" (= Änderung der Solltemperatur) einzeln ausschalten muss.

    Bei den 1ern und beim PlugS gibt es diese Profile allerdings leider nicht.

    Den Sollzustand stellt in meinem Fall meine Fußbodenheizungssteuerung von Homematic IP dar.

    Dort Tippe ich auf Urlaubsmodus, Beginn und Ende definieren (Datum + Uhrzeit) und gebe die Solltemperatur an.

    So Ähnlich würde ich es mir für bei den Shellys auch wünschen.

    Gibt es sowas eventuell schon ... blosd unter anderem Namen?

    Habt ihr vielleicht einen kompakten workaround ... evtl. auf Basis von webhooks?

    Macht es Sinn dies mal als feature-request an Shelly heranzutragen?

    Danke

    Ungetestet aber ziemlich wahrscheinlich funktionstüchtig:

    In irgendeinem Frontend (Bedienungsoberfläche) einen Schalter für Abwesenheit oder "Urlaub" bereitstellen.

    Wird der virtuelle Schalter auf ein/aktiv gestellt, zwei (oder mehr?) Nachrichten per HTTP oder MQTT oder ??? an alle betreffenden Shellies senden, die

    1. deren Scheduling deaktiviert und
    2. die Urlaubswerte einstellen

    Wird der Schalter auf aus/inaktiv gestellt, per Nachricht das Scheduling auf den betreffenden Shellies aktivieren.

    Ich täte es mit Node RED - in Homematic afaik RedMatic - und MQTT lösen, per HTTP dürfte es aber auch gelingen, falls kein MQTT zur Verfügung steht.

    Btw. ähnliches habe ich per Node RED für meine lokalen Heizungssteuerungen so gelöst. Mein System ist gemischt mit TRVs und Shelly 1 + Addon realisiert. Allerdings nutze ich das Scheduling nur in den TRVs.

    Nachtrag:

    Die Urlaubswerte lassen sich in einem Konfigurationsknoten leicht verwalten und von dort holen, sowohl global als auch Flow bezogen. Optional können solche Daten persistent gespeichert (Dateisystem) und beim starten von Node RED in die Konfiguration geladen werden.

    An Cloud-/Szenen-Benutzer (insbesondere für Regelungen): Was erwartest du, wenn Internet oder Cloud sabotiert werden? Nicht nur dafür meine kleine Skripteinführung  8)

    Die einzig existierende Konstante ist der Wandel. Oft liegt die größte Schwierigkeit darin, das Anliegen des Klienten zu verstehen.

    Einmal editiert, zuletzt von eiche (31. Dezember 2022 um 07:59)

    Habe dazu jetzt was gefunden ... das Zauberwort heißt "Szenen".

    Dort kann man für mehrere Geräte - in meinem Fall TRVs - den Zeitplan in Abhängigkeit von verschiedenen Bedingungen umstellen

    Eine Bedingung können Zeitereignisse sein ... also genau das was ich benötige.

    Vorsicht!

    Wenn eine solche Einstellung möglichst sicher funktionieren soll, warne ich vor der Verwendung einer Cloud bzw. eines externen Assistenten.

    Wenn ein externer Assistent (bspw. Cloud) ausfällt oder fehlerhaft arbeitet, ist die Zuverlässigkeit dahin.

    Deshalb implementiere ich Aktionen, die möglichst funktionssicher/ausfalltolerant arbeiten sollen, so nahe wie möglich am Gerät (Aktor / Sensor).

    Gimmicks, die nur schön oder angenehm sind, sind auch in einem externen Assistenten brauchbar aufgehoben.

    Aus diesen Gründen lasse ich auch Datenaufzeichnungen zu Hause speichern, was aber weniger zwingend erscheint, weil solche Speicherungen i.d.R. keine Funktionssicherheit herstellen.

    Das ist selbstverständlich nur ein Hinweis. ;)

    An Cloud-/Szenen-Benutzer (insbesondere für Regelungen): Was erwartest du, wenn Internet oder Cloud sabotiert werden? Nicht nur dafür meine kleine Skripteinführung  8)

    Die einzig existierende Konstante ist der Wandel. Oft liegt die größte Schwierigkeit darin, das Anliegen des Klienten zu verstehen.