Hallo Zusammen,
ich habe einen Timer der jeden 2.Tag auslöst so installiert:
([([9:00]+2*86400)]) (set Bewaesserung on-for-timer 900)
das funktioniert auch einwandfrei:
2024.09.07 09:00:00 3: [Shelly_Set] calling for device Bewaesserung with command 'on-for-timer' and 1 parameters: 900
Bewässerung erfolgt für 15 Minuten.
Leider erscheint im log massenweise folgende Fehlermeldung:
2024.09.07 12:03:52 3: [Shelly_status] Bewaesserung: Error in callback, update in 60 seconds
2024.09.07 12:03:52 1: [Shelly_status] Device Bewaesserung has Error 'Error: Timeout reading', state is set to 'Error: Network'
???
Grüße Andi
Die Meldungen kommen nicht vom DOIF-Modul. Vermutlich hat es etwas mit deinem Shelly-Schalter etwas zu tun.
Danke für die Antwort. Hast recht das war der Shelly. Es war nur ein blöder Zufall, dass genau nachdem ich von täglicher Bewässerung (mit at) auf 2 tägige (mit DOIF) umgestellt habe die Meldungen kamen.
Ich hab jetzt auf neue Firmware upgedated und bisher läufts.
Sorry für die blöde Anfrage :-\
Alle zwei Tage müsste die Definition so aussehen:
([([9:00]+86400)])
Denn um Punkt neun, wird das Modul bereit 86400 für den nächsten Tag aufaddieren.
Zitat von: Damian am 07 September 2024, 16:45:42Alle zwei Tage müsste die Definition so aussehen:
([([9:00]+86400)])
Denn um Punkt neun, wird das Modul bereit 86400 für den nächsten Tag aufaddieren.
Hallo Damian,
ich kannte diese Option noch nicht und hab daher in der commandref nachgeschaut und bin fündig geworden.
Die Definition liest sich etwas sperrig, zumindest ist es für mich etwas gewöhnungsbedürftig. Persönlich ziehe ich das vor:
$yday%2 == 0Damit wird auch jeden 2. Tag eine Bedingung wahr; eine weitere Bedingung muss daneben aber auch existieren, die mit "and" verknüpft wird.
Viele Grüße Gisbert
ja, eigentlich habe ich Berechnung von Zeiten dafür programmiert, um den nächsten Schaltzeitpunkt dynamisch berechnen zu können. Natürlich kann man eine feste Zahl von Sekunden drauf addieren. Da es keine Beschränkung der Größe gibt, lässt sich der Zeitpunkt beliebig weit in die Zukunft verschieben. Allerdings kommt man aus dem Takt, wenn das Device neu gestartet wird, wenn man über 24h draufaddiert, da der erste Schaltpunkt bei Addition z. B. von 84600, doch am nächsten Tag stattfindet.
Es sind noch andere Dinge möglich, die nicht dokumentiert sind, weil sie im Programm nicht abgefangen wurden und dadurch unbeabsichtigt ebenfalls funktionieren.
z. B. alle 99 Stunden [+99:00], 100 geht aber schon nicht, da nur zwei Stellen für Stunden vorgesehen sind.
mit ([09:00] and $yday%2 == 0) würde man eher im Takt bleiben, auch wenn das System neu gestartet wird, da hier jeden Tag geprüft wird, dafür hat man jeden Tag einen Zeittrigger.
Hallo Damian,
es funktioniert aber mit
([([9:00]+2*86400)])
Schaltet alle 2 Tage ::)
OK, dann funktioniert es besser als ich dachte. Dann könnte man diese Lösung sogar allgemein empfehlen :)
Man kann sogar auch sowas angeben:
([([09:00]+2*[24:00])])
Dass ein Tag 24 Stunden hat, weiß jeder. Wie viel Sekunden es sind, weiß nicht jeder.
oder sogar:
([([09:00]+[48:00])])
dass es das Gleiche ist wie:
([57:00])
sage ich jetzt nicht laut, da es nicht sonderlich gut verständlich ist.
Es ist schon fast wie in der AI-Welt, wo die Programme mehr leisten, als man erwartet hat :)
Zitat von: Damian am 08 September 2024, 10:21:58Man kann sogar auch sowas angeben:
([([09:00]+2*[24:00])])
Dass ein Tag 24 Stunden hat, weiß jeder. Wie viel Sekunden es sind, weiß nicht jeder.
...
Ich habe diese Lösung in die Commandref aufgenommen: https://fhem.de/commandref_DE.html#DOIF_Zeitsteuerung_alle_X_Tage
Zitat von: Damian am 08 September 2024, 10:21:58Dass ein Tag 24 Stunden hat, weiß jeder. Wie viel Sekunden es sind, weiß nicht jeder.
Deshalb gibt es in FHEM die Konstanten
use constant {
DAYSECONDS => 86400,
HOURSECONDS => 3600,
MINUTESECONDS => 60
};