Hallo,
ich habe bei mir einige Geräte, die selten nicht sofort ansprechen, sondern mitunter einen zweiten Aufruf brauchen.
Dazu habe ich mir eine Lösung für at gebastelt, die ich hier mit euch teilen will.
Falls es andere Vorschläge gibt, gerne ergänzen.
Hier ein Beispiel:
Internals:
DEF *22:00 {
if ("ja" eq ReadingsVal("Tag", "Urlaub", "")) {
fhem("set WohnzimmerRolladenVorne closes;sleep 10;set KuecheRolladen closes;sleep 10;set EsszimmerRolladen closes;sleep 10;set WohnzimmerRolladenLinks closes;sleep 10;set WohnzimmerRolladenRechts closes");
fhem("set Aussenlicht off;set CouchLampe off;set EsszimmerLampe off");
fhem("sleep 40;set LEDGarderobe off;set PlugWeihnachten off");
fhem("set PlugUrlaub off");
if (ReadingsVal("Tag", "Aussenbewaesserung", "") eq "inaktiv") {
fhem("set Aussensteckdose off");
}
my $hm = sprintf("%02d:%02d", $hour, $min);
if ($hm lt "22:01") {
fhem("sleep 300; set atAbwesend2200 execNow");
}
}
}
NAME atAbwesend2200
PERIODIC yes
RELATIVE no
REP -1
STATE Next: 22:00:00
TIMESPEC 22:00
TRIGGERTIME 1603137600
TRIGGERTIME_FMT 2020-10-19 22:00:00
TYPE at
READINGS:
2020-10-19 01:52:05 state Next: 22:00:00
Attributes:
room Kalender
Wichtig sind hier die letzten Zeilen:
my $hm = sprintf("%02d:%02d", $hour, $min);
if ($hm lt "22:01") {
fhem("sleep 300; set atAbwesend2200 execNow");
}
Nachteil dieser Lösung ist, dass man den Namen des at für das execNow wiederholen muss und auch die Startzeit zwischen dem DEF und unten in der Abfrage synchron halten muss.
Also ich würde ja beheben WARUM die Geräte nicht sofort reagieren!
Um was für Geräte/System handelt es sich!?
Gibt es dort sowas wie "repeatCmd" o.ä. (immer noch besser als dein at-Konstrukt)!?
Wenn du es schon so komisch haben willst, warum packst du dann deine "Schaltorgie" nicht in eine sub in myUtils und rufst sie einfach 2x (zeitverzögert) auf!?
https://wiki.fhem.de/wiki/99_myUtils_anlegen
Was anderes machst du doch jetzt auch nicht.
(dein at-Konstrukt ist ja quasi deine "Sub" ;) )
Und die Abfrage:
my $hm = sprintf("%02d:%02d", $hour, $min);
if ($hm lt "22:01") {
ist doch unnötig, weil: das at wird um 22:00 getriggert. Deine Verzögerungen laufen (wenn ich mich nicht "verzählt" habe) ca. 40s also ist IMMER früher als 22:01, daher kannst du das execNow auch gleich ausführen!?
Oder hab ich da was übersehen!?
Gruß, Joachim
Hallo,
das "if ($hm lt "22:01") {" ist beim ersten Durchlauf durch das at erfüllt und wird damit ausgeführt. Wenn er dann aber 300 Sekunden später nochmal reinläuft, dann nicht mehr. Also genau eine Wiederholung.
Mit zur Pausenzeit passenden Vergleichen sind auch mehr als 1 Wiederholung möglich.
Und es handelt sich um EnOcean Rolladenschaltungen. Eigentlich sollen die verlustfrei arbeiten, tun sie leider nicht immer.
Das mit dem sub in myUtils würde gehen, dann brauche ich aber 2 ats wegen der Wiederholung und das eine sub.
Sind also drei Stellen, die gepflegt werden wollen und wo man dann auch den Zusammenhang sehen muss, dass diese drei zusammen hängen.
Und zusätzlich bin ich ein Freund von Inline-Code, in Subs habe ich nur wenige, komplexe Routinen.
Der Vorteil des Inlinings ist für mich, dass mir FHEM wunderbar alle Stellen auflistet, an denen ein Device genutzt wird, bei myUtil geht das nicht.
Ist also reine Geschmacksache und weniger Entitäten in fhem, warum ich diese Lösung für mich gut finde.
Zitat von: jhohmann am 19 Oktober 2020, 11:51:47
Hallo,
das "if ($hm lt "22:01") {" ist beim ersten Durchlauf durch das at erfüllt und wird damit ausgeführt. Wenn er dann aber 300 Sekunden später nochmal reinläuft, dann nicht mehr. Also genau eine Wiederholung.
Mit zur Pausenzeit passenden Vergleichen sind auch mehr als 1 Wiederholung möglich.
Ja, das stimmt nat. Hatte ich übersehen ;)
Das "Konstrukt" ist aber auch "eigenartig" ;)
Zitat von: jhohmann am 19 Oktober 2020, 11:51:47
Und es handelt sich um EnOcean Rolladenschaltungen. Eigentlich sollen die verlustfrei arbeiten, tun sie leider nicht immer.
Das mit dem sub in myUtils würde gehen, dann brauche ich aber 2 ats wegen der Wiederholung und das eine sub.
Sind also drei Stellen, die gepflegt werden wollen und wo man dann auch den Zusammenhang sehen muss, dass diese drei zusammen hängen.
Und zusätzlich bin ich ein Freund von Inline-Code, in Subs habe ich nur wenige, komplexe Routinen.
Der Vorteil des Inlinings ist für mich, dass mir FHEM wunderbar alle Stellen auflistet, an denen ein Device genutzt wird, bei myUtil geht das nicht.
Ist also reine Geschmacksache und weniger Entitäten in fhem, warum ich diese Lösung für mich gut finde.
Ah EnOcean.
Die sollten aber mit Rückmeldung arbeiten.
Wie hast du konfiguriert!?
Aber du hast recht: geschmackssache. Ich trenne leiber Code/Programmierung und Konfiguration... (finde ich eben übersichtlicher)
Das mit den 3 Stellen stimmt nicht. Auch dafür gibt es eine Lösung ;)
Ich rufe (zur Überprüfung) auch per "defmod at" innerhalb einer Sub die selbe Sub noch mal auf. Du kannst ja als Parameter den aktuellen Durchlaufwert mitgeben und so sogar mehrfach aufrufen per definiertem Zähler etc. (es gibt, wie so oft, viele Möglichkeiten)...
Gruß, Joachim
EnOcean ist ganz normal per USB Stick in FHEM vorhanden und die Rolladenaktoren sind darüber angemeldet.
Wenn ich das Thema vertiefen wollte, dann im korrekten Forum und nicht hier ;). Diese Variante ist ja unabhängig von irgendwelchen konkreten Systemen.
Falls es nicht zu viele Umstände macht, würde mich deine Lösung mit dem defmod interessieren.
Danke für deine Rückmeldungen
Jürgen
Klar.
Das habe ich mal für jemanden im Forum "gebastelt":
sub my_DimmUp($$$$)
{
my ($Device, $DimStep, $DimEnd, $WaitTime) = @_;
my $ActDimValue = ReadingsNum($Device, "dim", 0);
my $AtName = "atDimTimerFor" . $Device;
my $AtTime = "+00:00:0" . $WaitTime;
Log3(undef, 3, "my_DimmUp Device: $Device DimStep: $DimStep DimEnd: $DimEnd WaitTime: $WaitTime");
if($ActDimValue > $DimEnd)
{
Log3(undef, 3, "my_DimmUp reached the end.");
return;
}
$ActDimValue += $DimStep;
fhem("setreading $Device dim $ActDimValue");
fhem("delete $AtName"); # bin nicht sicher, ob das sein muss/darf
fhem("defmod $AtName at $AtTime {my_DimmUp(\"$Device\", $DimStep, $DimEnd, $WaitTime)}");
Log3(undef, 3, "my_DimmUp timer $AtName with $AtTime started.");
}
hier etwas abgespeckt:
sub CallLoop($)
{
my ($LoopCount) = @_;
my $LoopEnd = 5;
if($LoopCount > $LoopEnd)
{
return;
}
$LoopCount++;
# do what is necessary
fhem("defmod atNext +00:00:10 {CallLoop($LoopCount)}");
}
Erster Aufruf halt unter Mitgabe des Startwertes...
Ich habe auch Routinen in der Art, die ich erstmalig durch ein notify aufrufe und dann (u.U.) wiederholend durch ein at (defmod in der Sub)...
Wenn intern unterschiedlich "gehandelt" werden soll, dann gebe ich als "Modus" (Parameter) eben "notify" oder "at" mit ;)
Gruß, Joachim
Das ist ja ein spaßiger Zufall.
Ein Problem mit Hochdimmen hatte ich vor kurzem im Forum gestellt, aber auf die Schnelle hat sich da niemand gemeldet.
Da hatte ich auch mit einem at und sub gespielt, es aber nicht zu laufen bekommen.
Kurz darauf habe ich für mich eine andere Lösung gefunden.
https://forum.fhem.de/index.php/topic,115067.0.html (https://forum.fhem.de/index.php/topic,115067.0.html)
Bei FHEM führen viele, viele Wege nach Rom oder ins Nirvana ;D.
Zitat von: MadMax-FHEM am 19 Oktober 2020, 12:13:42
Ah EnOcean.
Die sollten aber mit Rückmeldung arbeiten.
Wenn es um Geräte mit Rückmeldung geht, würde ich sowas immer mit einem watchdog lösen.
Ist zwar jetzt nicht unbedingt das Thema, aber wenn ich was neues lernen kann.
Wie würde so etwas denn per Watchdog überwachen können?
Der Ablauf wäre doch wie folgt:
Ich möchte zum Zeitpunkt X meine Rolläden runter-/oder hochfahren.
Wenn dann zum Zeitpunkt X+1 Sekunde sich nichts tut, mach es nochmal.
Woher soll der Watchdog wissen, dass er nun um X+1 eingreifen soll, wenn bei X nichts passiert ist.
Also müsste ich in meinem at jetzt einen Watchdog aktivieren, der was tut? Weil, dauerhaft darf der Watchdog nicht arbeiten.
Und wann schalte den Watchdog wieder ab? Mit einem anderen at mit X+20?
Bitte die commandref zum Modul watchdog lesen.
https://commandref.fhem.de/#watchdog
Die Commandref habe ich mir schon angeschaut und auch einige wenige davon bei mir am Laufen, z.B. Fenster offen Nachrichten.
Die reagieren auf Events und warten, dass in einer gewissen Zeit etwas anderes passiert (oder eben nicht).
Wie hilft mir das hier, wenn irgendwas in FHEM einem Rolladen das Kommando schickt: "Fahr runter".
Das Device reagiert aber nicht und damit gibt es auch kein Start-Event, auf dem der Watchdog reagieren soll.
Also löst er nicht aus und es passiert nichts.
Das habe ich auch, wenn mein at nur einmal läuft und nichts passiert.
Das würde hier nur funktionieren, wenn alleine das Absetzen eines Befehls an ein Gerät ein Event auslösen würde, und dann der Watchdog auslöst, wenn das Kommando versackt.
Zitat von: jhohmann am 19 Oktober 2020, 18:05:59
Das Device reagiert aber nicht und damit gibt es auch kein Start-Event, auf dem der Watchdog reagieren soll.
Also löst er nicht aus und es passiert nichts.
Ein Start-Event kann auch der Start des at oder ein set Befehl sein.
Kam gestern nicht mehr dazu, dass auszuprobieren.
Aber es geht tatsächlich, auf ein at als Event zu reagieren. Wieder was gelernt.
Jetzt muss ich mir nur überlegen, wie ich das verwenden kann.
Danke