Verständnisfrage zum DOIF-Modul (Bug oder Feature?)

[mcbird]

Moin FHEM'ler,

ich habe die Hausautomation auf das Außengehege unserer Schildkröten erweitert und überwache jetzt die Temperaturentwicklung im Frühbeet und im Schutzhaus. Dabei steuere ich auch die Heiztechnik (Lampe und Matte) im Frühbeet über FHEM.

Erstes Problem

Die Heizlampe steuere ich dabei über folgendes DOIF-Konstrukt

Code Auswählen Erweitern

# Schaltung der Heizlampe im Frühbeet im Zeitraum 07:30-20:00 Uhr bei unter 23 Grad EIN / bei über 28 Grad AUS

define DI_turtle_heatinglamp DOIF ([?07:30-20:00] and [Wetterstation_Turtle_Home:temperature]<23) (set Steckdose_Powermeter_Portabel_Sw on) DOELSEIF ([?07:30-20:00] and [Wetterstation_Turtle_Home:temperature]>28) (set Steckdose_Powermeter_Portabel_Sw off)
attr DI_turtle_heatinglamp alias Heizlampe unter 23 Grad EIN / bei über 28 Grad AUS
attr DI_turtle_heatinglamp group Steckdosen - Zeitschaltung
attr DI_turtle_heatinglamp icon light_on-for-timer
attr DI_turtle_heatinglamp room 6.1 Schildkröten,9.4 Notifications


Spätestens um 20:30 Uhr gibt es dann noch mal das Kommando zum Abschalten – egal wie der letzte Status der Heizlampe war.

Code Auswählen Erweitern

define Heatlamp_OFF at *20:30 set Steckdose_Powermeter_Portabel_Sw off
attr Heatlamp_OFF alias Zeitschaltung - Steckdose (Schildkröten - Wärmelampe) NOTAUS
attr Heatlamp_OFF group Steckdosen - Zeitschaltung
attr Heatlamp_OFF icon light_off-for-timer
attr Heatlamp_OFF room 6.1 Schildkröten,9.3 AT-Jobs

Jetzt habe ich dabei folgendes Problem ...

Wenn die Heizlampe am Abend über den AT-Job abgeschaltet wird dann schaltet das DOIF ,,DI_turtle_heatinglamp" die Lampe trotz Temperaturen von unter 23°c um 7:30 Uhr nicht wieder ein. Wenn aber die Heizlampe am Abend vom DOIF ,,DI_turtle_heatinglamp" abgeschaltet wurde, dann funktioniert auch das Einschalten am Morgen!

Warum ist das so? Ist das ein Bug oder ein Feature? Was muss ich anders machen?

Zweites Problem

Ich lasse mir via DOIF / Pushover ab 8:00 Uhr alle 45 Minuten einen "Wetterbericht" zusenden.

Code Auswählen Erweitern

# Schildorado Wetterbericht via Pushnachricht

define DI_push_temperatur DOIF ([08:00-19:00] and [+00:45]) (set pushmsg msg 'Aktuelles Wetter im Schildorado' 'Temperaturen im Frühbeet: [Wetterstation_Turtle_Home:temperature] Grad / Schildkrötenhaus: [Temperatur_Feuchtesensor_2:temperature] Grad. Aussentemperatur von [Wetterstation_Aussen:temperature] Grad im Schatten. Status Wärmelampe: [Steckdose_Powermeter_Portabel_Sw:state] / Heizmatte: [Steckdose_Portabel:state]')
attr DI_push_temperatur alias Schildorado Wetterbericht via Pushnachricht
attr DI_push_temperatur do always
attr DI_push_temperatur group Alert-Pushnachricht
attr DI_push_temperatur icon message_mail
attr DI_push_temperatur room 6.1 Schildkröten,9.3 AT-Jobs

Für mein Verständnis sollte der Job das erst Mal um 8:45 Uhr getriggert werden und dann alle 45 Minuten wieder. Aber der Job wird jedes Mal um 8:29 Uhr getriggert und dann alle weiteren 45 Minuten!

(http://www.weblicht.de/img/push.PNG)

Wieso, weshalb, warum? Bug oder Feature?

Vielen Dank für eure Hilfe und Grüße aus dem Norden,

Daniel

[Ralli]

Problem 1:

Code Auswählen Erweitern


define DI_turtle_heatinglamp DOIF ([?07:30-20:00] and [Wetterstation_Turtle_Home:temperature]<23) (set Steckdose_Powermeter_Portabel_Sw on) DOELSEIF ([?07:30-20:00] and [Wetterstation_Turtle_Home:temperature]>28) (set Steckdose_Powermeter_Portabel_Sw off) DOELSEIF ([20:30]) (set Steckdose_Powermeter_Portabel_Sw off)


So brauchst Du kein at mehr und hast den Zustandswechsel, der erforderlich ist, damit morgens wieder eingeschaltet wird.

Problem 2:
Könnte mit der (falschen) Timer-Initialisierung nach einem shutdown-restart von fhem zusammenhängen.

[mcbird]

Hallo Ralli,

vielen Dank für deine Antwort.

Das mit dem nötigen Zustandswechsel im Kontext des DOIF-Konstrukts hatte ich schon "befürchtet" - das schränkt den Einsatz doch leider etwas stark ein. Ich hatte gehofft, dass der Zustand nicht im eigenen Kontext gehalten, sondern expliziert am Objekt angefragt wird. Jetzt führt eine externe Zustandsänderung zur Fehlinterpretation.

Das mit dem Timer verstehe ich nicht – aktuell boote ich den Raspberry / FHEM öfter durch und somit scheint sich die Timer-Initialisierung konstant zu verschlucken. Gibt es einen zentralen Timer-Dienst oder hat jeder DOIF-Instanz seine eigene Timerinstanz laufen?

Die Implementierung scheint mir hier jedenfalls ein wenig unglücklich umgesetzt zu sein.

Danke und Gruß,

Daniel

[Ralli]

Das schränkt überhaupt nicht ein - ist im Gegenteil ein gut nutzbares Feature.

Wenn Du es so nicht willst, beschäftige Dich mit dem Attribut do always (siehe commandref).

Das mit der Timer-Initialisierung nach einem shutdown restart ist Damian bekannt und wird in der nächsten Version (hoffentlich und wahrscheinlich) behoben sein.

[mcbird]

Das auslösende DOIF ist das [Wetterstation_Turtle_Home:temperature] Reading und damit wird der Zustand des Aktors "Steckdose_Powermeter_Portabel_Sw" auf "on" oder "off" gesetzt. Warum hat der Aktor-Zustand, welcher überhaupt nicht Teil der DOIF Bedingung ist, einen Einfluss auf die Ausführung?

Da sollte laut Definition und meinem Verständnis auch kein "do always" helfen - der Zustand des Aktors gehört da einfach nicht rein, denn er kann nicht garantiert werden.

Grüße,

Daniel

[Ralli]

Das ist auch nicht so. Ich hab's Dir oben schon geschrieben, was da passiert.

1) Heute morgen schaltet das DOIF mit cmd_1 ein
2) Heute abend schaltet ein at aus
3) Morgen früh schaltet das DOIF nicht ein, weil es immer noch als state cmd_1 hat.

Also nochmal: Du musst einen Zustandswechsel herbeiführen - so wie ich Deine Def verändert habe - oder ein do always setzen.

[Damian]

Das ist auch nicht so. Ich hab's Dir oben schon geschrieben, was da passiert.

1) Heute morgen schaltet das DOIF mit cmd_1 ein
2) Heute abend schaltet ein at aus
3) Morgen früh schaltet das DOIF nicht ein, weil es immer noch als state cmd_1 hat.

Also nochmal: Du musst einen Zustandswechsel herbeiführen - so wie ich Deine Def verändert habe - oder ein do always setzen.

Wenn du das Ausschalten über das gleiche DOIF-Modul realisiert, statt über ein at, wie Ralli dir schon vorgeschlagen hast, dann änderst du den Status, besser den Zustand des Moduls (wir reden hier nicht von irgendwelchen Aktoren) und dann kann cmd_1 wieder kommen (ohne do always).

Das Konzept der Zustandsverwaltung des DOIF-Moduls geht über einen einfachen notify bzw. at hinaus, bitte noch mal gründlich die Commandref zu DOIF studieren, auch wenn sie inzwischen recht umfangreich geworden ist.

Gruß

Damian

[mcbird]

Das habe ich auch verstanden - ich schalte ein DOIF-Command und nicht den Aktor und der letzte DOIF-Command Zustand ist dabei ausschlaggebend ob das Command noch einmal ausgeführt wird. Ich werde das wie vorgeschlagen umsetzten. Danke! Ich würde mir nur wünschen, dass bei einer "Zeitraumschaltung" wie [?07:30-20:00] das DOIF-Command beim Eintritt in den Zeitraum erneut ausgeführt wird.

Nach der Logik:

Merke dir in dem Zeitraum 07:30-20:00 Uhr den Command-Zustand, nach 20:00 Uhr setzte den Zustand auf "undefined" und setzte dann um 07:30 Uhr den Zustand wieder entsprechend der DOIF-Bedingung.

Vielen Dank und Gruß,

Daniel

[Damian]

Ich würde mir nur wünschen, dass bei einer "Zeitraumschaltung" wie [?07:30-20:00] das DOIF-Command beim Eintritt in den Zeitraum erneut ausgeführt wird.

Nach der Logik:

Merke dir in dem Zeitraum 07:30-20:00 Uhr den Command-Zustand, nach 20:00 Uhr setzte den Zustand auf "undefined" und setzte dann um 07:30 Uhr den Zustand wieder entsprechend der DOIF-Bedingung.

Das würde auch passieren, wenn man es "richtig" definiert. Man braucht einfach nur einen DOELSE-Fall ohne Ausführungsteil dran zu hängen, siehe Erklärung von Brockmann:

http://forum.fhem.de/index.php/topic,38930.msg311170.html#msg311170

Gruß

Damian