[Zeit|Wochentag] in myUtils an weitere Funktion übergeben und nachher auswerten

[tschoegge80]

Hallo zusammen

In einem doif kann man ja als Bedingung z. B. [05:00-21:59|8] angeben.
Ich möchte mir nun gerne in myUtils.pm eine eigene Funktion bauen und z. B. [05:00-21:59|8] an eine weitere Funktion in myUtils übergeben.
Die übergebene Zeit und Wochentag soll in einer if Bedingung nachher geprüft werden.

Hier grob wie ich es machen möchte:

myUtils_Func1()
{
    myUtils_Func2l("[05:00-21:59|8]")
}

myUtils_Func2($)
{
   my ($myTime) = @_;

   if($myTime) {}
}

Wenn ich es nicht als String übergebe, kommt eine Fehlermeldung, da es diese Schreibweise nicht akzeptiert.
Geht diese Auswertung so einfach wie im doif oder muss ich da selber alles abfragen?

Gruss und Danke

Jörg

[Ellert]

Geht diese Auswertung so einfach wie im doif

Nein.

muss ich da selber alles abfragen?

Ja.

Welches Problem möchtest Du auf diese Weise lösen??

[tschoegge80]

Hallo Ellert

Danke für Deine Antwort.

Kurzfassung:
Ich möchte prüfen, ob die aktuelle Zeit und der Tag im angegebenen Bereich ist und dann die Heizung dementsprechend steuern.
Es soll aber den Temperaturwert für diesen Zeitraum bei der Auswertung verwenden.


Hier noch die ganze Geschichte, falls jemand wissen möchte was ich versuche zu machen:
Ich habe bei mir drei Infrarotheizungen im Einsatz.
Diese Steuere ich über EnOcean Eltako FSR61VA-10A und Klimasensoren.

Ich habe pro Raum drei voreingestellte Temperaturen (Wochentage, Absenk, Wochenende)
In den Badezimmern noch eine spezielle Funktion, damit am Morgen beim duschen oder bevor man baden möchte, die Temperatur höher als üblich eingestellt werden kann.
Diese Funktion wird nach einer gewissen Zeit wieder automatisch abgeschaltet und es geht zurück in den Normalmodus.
Geplant ist noch kurze und längere Abwesenheiten zu berücksichtigen (Permanent Absenktemperatur).

Damit ich nicht die ganze Logik in einem doif unterbringen muss und dies noch pro Heizung, habe ich mir gedacht, ich mache mir eine eigene Funktion.
Ein at ruft dann regelmässig die erste Funktion auf. Dort sind alle Heizungen registriert. Mit den gewünschten Werten als übergabeparameter.
In der zweiten Funktion sollen dann die übergebenen Parameter geprüft werden und entsprechen die Heizung ein- oder ausgeschaltet werden.

Ich stehe noch am Anfang mit FHEM. Ob meine Funktion eine gute Idee ist, wollte ich daher testen.
Hab in der commandref folgenden Text im doif gefunden "Für die Zeitberechnung wird der Perlinterpreter benutzt, daher sind für die Berechnung der Zeit keine Grenzen gesetzt" und daher gedacht, dass
dies eine Perl Funktion ist, welche ich direkt übernehmen kann, um diese Schreibweise zu überprüfen.
Schaue nun wie ich es umsetzen kann, um dies auszuwerten. Für Ideen bin ich natürlich offen.

Grüsse Jörg

[Ellert]

Verstehe ich Dich richtig, Du hast schon eine Steuerung als Perl-Funktionen und möchtest diese erweitern mit

prüfen, ob die aktuelle Zeit und der Tag im angegebenen Bereich ist und dann die Heizung dementsprechend steuern.
Es soll aber den Temperaturwert für diesen Zeitraum bei der Auswertung verwenden.

, dabei möchtest Du die Zeitspanne in DOIF Syntax übergeben also: [<Beginn>-<Start>|<Wochentage>].

Wenn das DOIF-Modul geladen ist, dann sind im DOIF definierten Funktionen öffentlich, diese Funktionen kannst Du nutzen, z.B. "ReadingSecDoIf($$)" um die Zeit seit der letzten Änderung eines Readings zu ermitteln.

Wenn Du jedoch ohnehin gute Perl-Kenntnisse hast, dann kannst Du das ebenso gut mit den Perlfunktionen time, timelocal, und localtime lösen. Der Vergleich von Zeitpunkten ist im Sekundenformat einfacher als im HH:MM-Format.

Damit ich nicht die ganze Logik in einem doif unterbringen muss

Das ist der Zweck des DOIF, es dürfen auch mehrere sein.

Ein at ruft dann regelmässig die erste Funktion auf. Dort sind alle Heizungen registriert ...

Das Polling ist eigentlich kontraproduktiv zu FHEM, da Du, je nach Umfang und Art  Deiner Funktionen FHEM blockieren könntest (Schleifen, Warten, ...).

FHEM arbeitet mit Ereignissen und darauf ist auch DOIF abgestimmt.

([10:00-20:00]) ist nur wahr, wenn die aktuelle Zeit zwischen 10 und 20 Uhr liegt. Um 10 erzeugt ein Timer ein Ereignis und setzt die Bedingung auf wahr und um 20 Uhr erzeugt ein weiterer Timer ein Ereignis, das die Bedingung unwahr werden lässt.

Über längere Zeiträume musst Du das ganze Datum  einbeziehen:

Code Auswählen Erweitern

([[Start_du:hm]] and ([Start_du:Y] == $year) and ([Start_du:M] == $month) and ([Start_du:D] == $mday))
   (({Log 1, "Start"}))
DOELSEIF ([Stop_du:hm]] and ([Stop_du:Y] == $year) and ([Stop_du:M] == $month) and ([Stop_du:D] == $mday) or [Start_du] or [Stop_du])
   (({Log 1, "Stop"}))
Start_du, Stop_du sind 2 Dummys mit den Readings
hm im Format HH:MM
Y das Jahr im passenden Format zu $year
M der Monat " " " " $month
D  der Tag " " " " $mday

Die Dummys kannst Du komfortabel im Frontend ändern und musst es nicht in einer Registrierfunktion der 98_myUtils.pm.

mit dem Attribut cmdState 1|0 zeigt der Status des DOIF ob die aktuelle Zeit innerhalb der durch die beiden Dummys bestimmten Zeispanne liegt. Das kannst Du auch in einer Perl-Funktion abfragen, oder in einem anderen DOIF.

Eine feste Zeitspanne zur Temperaturabsenkung hat allerdings nur einen geringen Automatisierungsgrad, da sie durch Benutzereingriff festgelegt werden muss und unflexibel ist.

Besser ist es eine Anwesendheitsbestimmung zu nutzen. Im einfachsten Fall mit Taster: der Letzte schaltet auf abwesend, der Erste auf anwesend oder mit Geofencing, Bluetooth Tag, LAN-Ping, intelligentem Schlüsselbrett, usw.

Ich hoffe, ich habe den Kern Deiner Frage irgendwie gestreift und es hiflt ein wenig.