Ich habe für meine Frau mehrere Watchdogs gebastelt, die sie nach 10 Minten daran erinnern, die Fenster zu schließen, weil wir sonst auch mal gerne 12 Grad im Zimmer haben.
Diese Wachdogs haben alle Namen mit *.WD
Im Sommer sind diese natürlich unnötig, weshalb ich sie zum April deaktiviere und im Oktober wieder aktiviere (set [a-z]+\.wd active)
Ich würde diesen Vorgang gerne automatisieren, habe es mit AT versucht: define Fenster_laut at 2023-10-01T08:00:00 set [a-z]+\.wd active - aber wie könnte ich dies für jedes Jahr wiederholen lassen, oder gibt es einen besseren Weg als über AT zu gehen?
Viele Dank und viele Grüße
Markus
Hallo Markus,
quick & dirty mit at (und nicht so schön da es jeden Tag startet und prüft ob das Datum passt):
*00:00:00 {if($month==10 && $mday==01) {fhem("set [a-z]+\.wd active")}}
Ich würde zB. das Modul HOMEMODE nutzen. Das bietet dafür CDMs für die Jahreszeiten.
Es gibt aber bestimmt noch etliche andere Möglichkeiten...
VG Sebastian
Hallo Sebastian,
vielen Dank für die schnelle und hilfreiche Antwort.
Das mit $month ist eine gute Idee - aber wie Du selbst schreibst, unnötiger Balast, da das Kommando jeden Tag ausgeführt wird. Über fhem("set [a-z]+\.wd active" dürfte es glaube ich aber nicht funktionieren, da es ja ein Konsolenbefehl ist, oder sehe ich das falsch?
HOMEMODE kenne ich noch gar nicht - vielen Dank für den Tip.
Viele Grüße
Markus
Nimm ein Calendar-device, dann kannst Du die jährliche Wiederholung einfach im Ereignis definieren.
Zitat von: juelich am 08 Oktober 2023, 17:45:36aber wie Du selbst schreibst, unnötiger Balast, da das Kommando jeden Tag ausgeführt wird.
Du glaubst ernsthaft, dass ein set...inactive dafür sorgt, dass Dein at nicht trotzdem jeden Tag ausgeführt wird? Glaubst Du vielleicht auch, dass ein Zitronenfalter Zitronen faltet?
Das set...inactive sorgt lediglich dafür, dass der im at hinterlegte Ausführungsteil nicht ausgeführt wird. Das at wird trotzdem gemäß seiner timespec IMMER ausgeführt, nur halt mit unterschiedlichem Ergebnis.
Wäre das nicht so, könnte ein wiederholendes at ja niemals seine nächste Ausführungszeit berechnen.
Noch ein Tipp: attr <device> disable 0|1 ist besser als set <device> active|inactive, weil das Setzen des Attributes tatsächlich in der Konfiguration landet und nicht nur im statefile.
Zitat von: betateilchen am 08 Oktober 2023, 18:43:48Zitat von: juelich am 08 Oktober 2023, 17:45:36aber wie Du selbst schreibst, unnötiger Balast, da das Kommando jeden Tag ausgeführt wird.
Du glaubst ernsthaft, dass ein set...inactive dafür sorgt, dass Dein at nicht trotzdem jeden Tag ausgeführt wird? Glaubst Du vielleicht auch, dass ein Zitronenfalter Zitronen faltet?
Da ich kein Zoologe bin kann ich letzteres nicht beurteilen - der erste Teil geht offensichtlich am von mir geschriebenen vorbei 😉.
Das "set inactive" hat nichts mit dem AT-Kommando bzw. Device zu tun.
Auf inactive gesetzt sollen zeitgesteuert meine Watchdogs gesetzt werden und im Herbst wieder aktiviert werden.
Das Aktivieren bzw. deaktivieren mache ich bisher per Hand und ich würde das gerne zeitgesteuert automatisieren. Dazu suche ich die beste Möglichkeit. AT ist die eine, die Nutzung meines Kalenderdevices eine andere. Vielleicht gibt's ja noch mehr.
Viele Grüße
Markus
Wäre es nicht besser sich nicht am Datum, sondern z.B. an der Aussentemperarur zu orientieren?
Zitat von: juelich am 08 Oktober 2023, 20:17:22Das "set inactive" hat nichts mit dem AT-Kommando bzw. Device zu tun.
Auf inactive gesetzt sollen zeitgesteuert meine Watchdogs gesetzt werden und im Herbst wieder aktiviert werden.
Es ist völlig egal, in welchem device Du das inactive setzt. Mein Hinweis bezog sich eher auf Deine Bedenken bezüglich "Ballast", wenn täglich geprüft werden soll, ob der "passende" Monat erreicht ist. Auch ein auf "inactive" gesetzter Watchdog wird immer noch arbeiten, er führt eben nur den Ausführungsteil nicht aus. Aber er prüft bei jeder erreichten Bedingung, ob er aktiv oder inaktiv ist - das kannst Du nicht beeinflussen. Deshalb ist es völlig wurscht, ob Du den Monat auch noch zusätzlich prüfst, das belastet FHEM nicht messbar zusätzlich.
Aber da Du ja auch nach Alternativen gefragt hattest, habe ich Dir ja bereits die Variante mit dem Calendar device vorgeschlagen. So steuere ich meine Heizung in der Wohnung. Und da ist es auch definitiv so, dass FHEM, solange es gar keinen Kalendereintrag gibt, um etwas auszuführen, auch tatsächlich nichts zu tun hat, außer den Kalender ggf. im angegebenen Interval neu einzulesen, falls man Änderungen im Kalender vorgenommen hat.
Zitat von: betateilchen am 08 Oktober 2023, 21:50:39Auch ein auf "inactive" gesetzter Watchdog wird immer noch arbeiten, er führt eben nur den Ausführungsteil nicht aus. ...
Aber da Du ja auch nach Alternativen gefragt hattest, habe ich Dir ja bereits die Variante mit dem Calendar device vorgeschlagen. So steuere ich meine Heizung in der Wohnung.
Das mit den inaktiven Devies habe ich nicht gewusst - gut zu wissen. Bisher kann ich aber nicht fesstellen, dass das System dadurch zu sehr überlastet wird. Wäre das denn auch s, wenn eine Device auf disable gesetzt wird?
Ich arbeite auch mit mehreren Kalendern, zwei davon steuern die Heizung im Wohn- und Kinderzimmer(n). Einen dritten Kalender habe ich, wo ich als Betreff einen beliebigen Befehl reinschreiben kann, der dann über fhem("Befehl$") ausgeführt wird. Genau das wollte ich auch für meine Watchdogs so machen, habe allerdings immer eine Fehlermeldung bekommen. Deshalb bin ich wieder von dieser Variante weg.
Ich glaube, das lag am nichtmaskierten "/", ich habe leider die richtige Schreibweise nicht herausbekommen - entschuldige meine Dummheit.
Viele Grüße
Markus
Zitat von: juelich am 08 Oktober 2023, 23:33:56Wäre das denn auch s, wenn eine Device auf disable gesetzt wird?
Es macht keinen Unterschied im Ergebnis, ob man mit set inactive oder attr disable arbeitet. Intern wird eine Funktion "IsDisabled()" aufgerufen, die beides prüft.
Bezüglich Deines nicht funktionierenden Befehls aus dem Kalender, poste doch mal ein Beispiel, dann kann man besser helfen.
Zitat von: betateilchen am 09 Oktober 2023, 09:19:04Zitat von: juelich am 08 Oktober 2023, 23:33:56Wäre das denn auch s, wenn eine Device auf disable gesetzt wird?
Bezüglich Deines nicht funktionierenden Befehls aus dem Kalender, poste doch mal ein Beispiel, dann kann man besser helfen.
Es ist halt doof, wenn man uwar schon seit Jahren vor sich hinprogrammiert, aber leider immer noch Probleme mit den verschieden Ebenen PERL und FHEM hat :-\
Der Fehler war ganz einfach: Auf der Konsole muss ja der Punkt mit "/" maskiert werden, in FHEM natürlich nicht.
Mit dem simplen Kalendereintrag set [a-z]+.wd inactive klappte jetzt alles wie gewünscht.
Damit ist das Kalendermodul tatsächlich die einfachste Lösung und ich kann den Thread hier schließen.
Obwohl ich zugeben muss, dass die vorgeschlagene Lösung, die Aktivierung / Deaktivierung von der Außentemperatur abhängig zu machen auch einen gewissen Charme hat. Da muss ich mal drüber grübeln, ob ich das mit dem Wettermodul hinbekomme...
Vielen Dank für die Hilfe!
Viele Grüße
Markus
Ich hatte meine Heizung nach Über- bzw. Unterschreiten der Durchschnittstemperatur der letzten 7 Tage geschaltet.
SO, vielen Dank noch einmal an alle, die sich beteiligt haben!
ich glaube, ich habe jetzt eine tolle Lösung gefunden, die sich an der Außentemperatur orientiert - und den Fensteralarm nur im Herbst und Winter aktiviert, und ihn aber temporär deaktiviert, wenn es draußen außergewöhnlich warm sein sollte:
define Fensterwatch DOIF
{
if (([06:00] or [12:00] or [18:00]) and ($month > 9 or $month < 4))
{
my $temp = ReadingsVal("Wetter","temperature","0");
if ($temp < 18)
{fhem(" set [a-z]+.wd active")};
if ($temp > 19)
{fhem(" set [a-z]+.wd inactive")};
}}
Am 1. April wird eder Alarm einmalig per kalendereintrag deaktiviert, damit er ab dann auf jeden Fall ausgeschaltet ist, auch wenn es noch zu kalt sein sollte.
Vielleicht gibt es ja noch elegantere Lösungen, aber zumindest funktioniert es!
Also noch einmal vielen Dank
Viele Grüße
Markus