Watchdog mit zeitverzögerter Ausführung

[RaspiCOC]

Hallo,

mein System mit RPI + COC steuert insgesamt 12 FHT80b. Das wird schon richtig eng im Bezug auf die 1% Regel. Vermutlich deshalb verstummt der eine oder andere FHT80 auch schon vor seiner regulären Verstummungszeit...

Ich habe also 12 Watchdogs eingerichtet:

define wd_EG_WOH_SEN watchdog EG_WOH_SEN:measured-temp.* 02:00 SAME set EG_WOH_SEN time

Wenn also ein FHT sich zwei Stunden nicht mehr gemeldet hat, bekommt er einen kleinen Tritt mit einer Zeitübertragung. Problem ist nur. dass wenn die Zeitaussendung kurz vor der vollen Stunde passiert, dass dann gern mal die Stunde auf dem FHT falsch gestellt wird.

Beispiel: 11:55 wir der Watchdog getriggert
12:30 ist die Abarbeitung der Warteschlange soweit, dass der COC die Zeit raussendet. Minuten zieht er dann ja nach, aber nicht die Stunde. Der FHT wird dann also auf 11:30 gestellt, was natürlich Mist ist.

Frage: Kann ich die Ausführung des getriggerten Watchdogs irgend wie auf die erste Minute nach der nächsten vollen Stunde pausieren lassen?

Also, irgendwie so:

define wd_EG_WOH_SEN watchdog EG_WOH_SEN:measured-temp.* 02:00 SAME at [current_hour +1]:01 set EG_WOH_SEN time

Freue mich auf einen Vorschlag!

[Rince]

Es kann an der aktuellen Uhrzeit liegen, dass ich dich nicht ganz verstehe.

Du hast 12 Watchdogs.
Die reagieren darauf, wenn sich die Temperatur 2 Stunden nicht verändert hat

Dann kommt ein Notify, welches eigentlich die Temperatur wissen will, und damit es die bekommt, setzt du im Thermostat die Zeit neu

Und weil du so viele von den Teilen hast, müssen einige der Zeit neu setzen Befehle warten. Was dann, wenn ihr Funktelegramm an der Reihe ist, dazu fürt, dass die Zeit nimmer stimmt?


Ist das so in etwa richtig?

Und jetzt willst du die Ausführung der Notifies in die nächste Stunde verschieben?

[RaspiCOC]

Ich denke, genau so ist es.

Das Gesamtsystem ist wegen der 1%-Regel natürlich schon ziemlich am Limit. Wenn dann der einzelne FHT mal ein paar Tage nicht aktiv vom COC angefunkt worden ist, stellt er ja nach so 4 / 5 Tagen den Sendebetrieb in Richtung COC ein. Es kommen dann ja nur noch die Aktuatoren-Befehle an, denn die laufen ja zwischen FHT und FHT8V autonom alle 2 Minuten (wo ich im übrigen auch gern die Periodizität auf 4 Minuten ändern würde, wenn es denn ginge, denn die belasten ja die 1%-Regel auch erheblich).

Meldet sich also ein FHT mit der measured temp. länger als 2 Stunden nicht (bewusst 2 Stunden, denn in diesem Zeitfenster sollte sich ein FHT ja melden, wenn er die Sendung nicht eingestellt hat), dann geht eben ein "set FHT-Name time" raus. Und bei der Funklast kann das dann eben auch mal dauern, was dann eben dazu führt, dass die falsche Zeit übertragen wird, wenn der Befehl aus der Warteschlangenabarbeitung erst in der Folgestunde rausgeht.

Ich würde also gern schauen, dass der Befehl grundsätzlich erst eine Minute nach der nächsten vollen Stunde abgesetzt wird, um dem COC eine Chance zu geben, das innerhalb einer Stunde abzuwickeln.

[Rince]

Du hast 4 oder 5 Tage Zeit, um die Teile mal aktiv anzusprechen?

Das Gesamtsystem ist wegen der 1%-Regel natürlich schon ziemlich am Limit. Wenn dann der einzelne FHT mal ein paar Tage nicht aktiv vom COC angefunkt worden ist, stellt er ja nach so 4 / 5 Tagen den Sendebetrieb in Richtung COC ein.

Dann ist doch überflüssig, alle 2 Stunden die Zeit zu setzen, sondern es würde ausreichen das alle 4 Tage zu machen?

Gerade, wenn dein System eh am Limit der 1% Regel ist.


Wäre es da nicht schlauer, sich einen Zeitpunkt mit potentiell wenig Funklast (so 1-4 Uhr Nachts) zu suchen, und dann so alle 3 Tage mal die 12 Befehle innerhalb der 3 Stunden abzufeuern?


Ich hab nix slow RF mäßiges im Einsatz, von da her bin ich vermutlich nicht der beste Ratgeber für dein Problem.

[RaspiCOC]

Vielleicht habe ich das im Ausgangspost nicht klar genug beschrieben, aber es geht mir genau darum, die Funklast so niedrig wie möglich zu halten.

Der Watchdog prüft doch nur alle 2 Stunden, ob der [temperatur]-Wert sich geändert hat. Wenn nicht (und das ist ja schon mit hoher Wahrscheinlichkeit genau dann der Fall, wenn die Temperatur nicht neu übermittelt worden ist), dann schickt der FHEM dem FHT die Zeit. Das sollte in einem perfekt eigependelten System - ohne große Steuerungseingriffe durch FHEM - eben i.d.R. maximal alle 4 / 5 Tage passieren. Dann sendet der FHT wieder und gut ist. Das stellt ja alles kein Problem dar.

Wie auch hier im Forum zu lesen ist, zieht FHEM zwar die Minuten nach (also korrigiert die Minuten, wenn der Befehl nicht sofort abgesetzt werden kann), jedoch eben nicht die Stunden. D.h. [set FHT_DEV time] um 12:58 führt mit nahezu 100% Wahrscheinlichkeit dazu, dass der FHT die Zeit erst um 13:0x übermittelt bekommt und zwar bekommt er dann 12:0x übermittelt und schon geht der FHT eine Stunde nach.

Daher meine Frage, ob ich die Ausführung des getriggerten Watchdogs bis eine Minute nach der nächsten vollen Stunde pausieren lassen kann. Also, Triggerung und 12:58, send FHT_DEV time um 13:01 --> eine Stunde Zeit um den Befehl abzusetzen.

[Groby]

Du könntest etwas abenteuerliches mit at basteln:

Code Auswählen Erweitern


{
if ($min>50)
{
my $m = sprintf('%02d',(61-$min)); 
{fhem("define FHT_x at +00:$m:00 set FHT xx;;")};
}
else
{
set FHT xx;
}
}


Für den Code übernehme ich keine Garantie 

MfGroby

[RaspiCOC]

Wenn ich das richtig verstehe (und ich bin noch blutiger Anfänger), dann würde ich jetzt so ungefähr dies in die fhem.cfg packen:

Code Auswählen Erweitern


define wd_EG_WOH_SEN watchdog EG_WOH_SEN:measured-temp.* 02:00 SAME {if ($min>15)
{
my $m = sprintf('%02d',(61-$min)); 
{fhem("define EG_WOH_SEN at +00:$m:00 set EG_WOH_SEN time;;")};
}
else
{
set EG_WOH_SEN time;
}
}



oder?

Passieren würde dann folgendes: Der FHT hat seit 2 Stunden nichts mehr von sich hören lassen (ausser natürlich Actuator x%), der Watchdog wird getriggert. Ist die aktuelle Zeit <= 15 Minuten der aktuellen Stunde wird im else-Teil das set FHT time direkt ausgelöst. Ist die aktuelle Zeit > 15 Minuten der aktuellen Stunde, wird die erste Bedingung erfüllt und eine einmalige (?) in der Zukunft liegende Übertragung der Zeit getriggert. Also z.B. Watchdog um 12:16 Uhr getriggert --> define EG_WOH_SEN at +00:45:00 set EG_WOH_SEN time --> Ausführung um 13:01.

Habe ich das richtig verstanden? (Das wäre genau das, was ich suche! Vielen Dank!)

[Groby]

Die Formel mit ">50" und "61-$min" bedingt, dass von xx:51:xx-xx:59:xx alles um xx:01:00 per AT ausgeführt wird. Wenn Du mit ">15" arbeitest, funktioniert es nicht mehr. Dann würde der Event um xx:16:00 den AT um xx:45:00 auslösen (61-16=45)...

">50" deshalb, weil Du geschrieben hast das der Befehl bis xx:0x:00 abgearbeitet wird. Deswegen bin ich von 9 Min Bearbeitungszeit ausgegangen. Im Umkehrschluss muss alles ab xx:51:00 um xx:01:00 ausgeführt werden.

Alle anderen Minuten können direkt verarztet werden und Du kannst Du die ">15" durch ">50" ersetzen. Ergebnis:

Min=01-50 - direkt
Min=51-59 - per at um xx:01:xx

ggf. solltest Du bei den Sek. pro watchdog noch eine Verzögerung einbauen:

FHT1 xx:01:00
FHT2 xx:01:04
FHT3 xx:01:08

MfGroby

[RaspiCOC]

Ups, ja, da habe ich nicht nachgerechnet. Werde das mal ausprobieren. Werde die Funktion in 99_myutils.pm packen und dann aus der fhem.cfg aufrufen in der Watchdog-Definition.

[Groby]

Macht definitiv Sinn.

Wenn Du $NAME übergibst, kann eine SUB alle 12 watchdogs verarzten