neues Modul DOIF

[ostseehuepfer]

Hey,

sorry ja klar muss ich es erst akivieren

Code Auswählen Erweitern

Internals:
   DEF        ([Verbrauch_WAMA_Wh:power]<3) (set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '',set Waschmaschine off)
   NAME       di_Waschmaschine
   NR         213
   NTFY_ORDER 50-di_Waschmaschine
   STATE      ???
   TYPE       DOIF
   Condition:
     0          ReadingValDoIf('Verbrauch_WAMA_Wh','power','')<3
   Devices:
     0           Verbrauch_WAMA_Wh
     all         Verbrauch_WAMA_Wh
   Do:
     0          set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '',set Waschmaschine off
   Helper:
     last_cond  -1
     last_timer 0
     sleeptimer -1
   Readings:
     0          Verbrauch_WAMA_Wh:power
Attributes:
   wait       300

[Damian]

Hey,

sorry ja klar muss ich es erst akivieren

Code Auswählen Erweitern

Internals:
   DEF        ([Verbrauch_WAMA_Wh:power]<3) (set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '',set Waschmaschine off)
   NAME       di_Waschmaschine
   NR         213
   NTFY_ORDER 50-di_Waschmaschine
   STATE      ???
   TYPE       DOIF
   Condition:
     0          ReadingValDoIf('Verbrauch_WAMA_Wh','power','')<3
   Devices:
     0           Verbrauch_WAMA_Wh
     all         Verbrauch_WAMA_Wh
   Do:
     0          set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '',set Waschmaschine off
   Helper:
     last_cond  -1
     last_timer 0
     sleeptimer -1
   Readings:
     0          Verbrauch_WAMA_Wh:power
Attributes:
   wait       300

und Fehlverhalten nachstellen und dann list ... posten

[ostseehuepfer]

Hier die Antwort nicht wundern hab ne 50 Watt Glühbirne dran gehängt anstelle der Wama

Code Auswählen Erweitern

Internals:
   DEF        ([Verbrauch_WAMA_Wh:power]<3) (set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '',set Waschmaschine off)
   NAME       di_Waschmaschine
   NR         213
   NTFY_ORDER 50-di_Waschmaschine
   STATE      cmd_2
   TYPE       DOIF
   Readings:
     2014-08-03 18:29:05   last_cmd        2
     2014-08-03 18:29:05   last_cmd_event  Verbrauch_WAMA_Wh
     2014-08-03 18:39:56   last_error      set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '';set Waschmaschine off: OK
     2014-08-03 18:39:56   next_wait_timer no wait_timer
     2014-08-03 18:29:05   state           cmd_2
   Condition:
     0          ReadingValDoIf('Verbrauch_WAMA_Wh','power','')<3
   Devices:
     0           Verbrauch_WAMA_Wh
     all         Verbrauch_WAMA_Wh
   Do:
     0          set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '',set Waschmaschine off
   Helper:
     last_cond  1
     last_timer 0
     sleepdevice Verbrauch_WAMA_Wh
     sleeptimer -1
   Readings:
     0          Verbrauch_WAMA_Wh:power
Attributes:
   wait       300

[Damian]

Hier die Antwort nicht wundern hab ne 50 Watt Glühbirne dran gehängt anstelle der Wama

Code Auswählen Erweitern

Internals:
   DEF        ([Verbrauch_WAMA_Wh:power]<3) (set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '',set Waschmaschine off)
   NAME       di_Waschmaschine
   NR         213
   NTFY_ORDER 50-di_Waschmaschine
   STATE      cmd_2
   TYPE       DOIF
   Readings:
     2014-08-03 18:29:05   last_cmd        2
     2014-08-03 18:29:05   last_cmd_event  Verbrauch_WAMA_Wh
     2014-08-03 18:39:56   last_error      set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '';set Waschmaschine off: OK
     2014-08-03 18:39:56   next_wait_timer no wait_timer
     2014-08-03 18:29:05   state           cmd_2
   Condition:
     0          ReadingValDoIf('Verbrauch_WAMA_Wh','power','')<3
   Devices:
     0           Verbrauch_WAMA_Wh
     all         Verbrauch_WAMA_Wh
   Do:
     0          set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '',set Waschmaschine off
   Helper:
     last_cond  1
     last_timer 0
     sleepdevice Verbrauch_WAMA_Wh
     sleeptimer -1
   Readings:
     0          Verbrauch_WAMA_Wh:power
Attributes:
   wait       300

    "2014-08-03 18:29:05   last_cmd        2"  besagt, dass der Verbrauch über 3 Watt war. Das ist aber nicht die Fehlersituation nach der wir suchen.

Also mach die Lampe aus und warte, dass zwei mal die Meldung kommt, das Wait-Attribut kannst du für den Test löschen, dann geht´s schneller.

Ich sehe auch unter last_error eine Meldung, da sollte eigentlich nichts stehen, vielleicht ist das die Ursache.

Gruß

Damian

[Damian]

OK. Das Problem ist wohl die Tatsache, das set pushmsg ... einen Returnwert, offenbar das "OK" liefert, was als Fehler interpretiert wird. Dadurch wird der Zustand für das Kommando intern im DOIF-Modul nicht gesetzt und daher das Kommando jedesmal wiederholt. Das werde ich in der nächsten Version korrigieren. Nichtdestotrotz sollte set pushmsg ... sich wie alle anderen FHEM-Befehle verhalten und nicht als Returnwert "OK" liefern, wenn alles ok ist.

Ich bin gerade dabei die nächste Version 1.6 fertig zu stellen, solange musst du dich gedulden oder mit Autor von pushmsg ansprechen, dass er das "ok" rausnimmt ansonsten wirst du immer eine Fehlermeldung im Log sehen.

Gruß

Damian

[ostseehuepfer]

Hey,

super danke für die Info. Was meinst du wann die neue Version erscheint? Nur ca. will kein Stress machen.

Grüße

[Damian]

Hey,

super danke für die Info. Was meinst du wann die neue Version erscheint? Nur ca. will kein Stress machen.

Grüße

Die ist etwas umfangreicher, das kann noch paar Tage dauern.

Als Entschädigung für deinen Zeitaufwand, nimm erst mal diese. Aber wie gesagt die Logeinträge mit dem OK-Returnwert wird es trotzdem geben, aber das ist wie gesagt nicht meine Baustelle.

Gruß

Damian

Edit: Datei wurde entfernt

[ostseehuepfer]

Danke !!! Nehme mal an damit bekomme ich keine weiteren doppelten Nachrichten?

Grüße

[Damian]

Danke !!! Nehme mal an damit bekomme ich keine weiteren doppelten Nachrichten?

Grüße

Sollte so sein. 

Gruß

Damian

[ostseehuepfer]

OK wird gleich getestet Danke!!!!!

Läuft Vielen Vielen Dank !!!

[Damian]

OK wird gleich getestet Danke!!!!!

Läuft Vielen Vielen Dank !!!

Dann lösche bitte noch den Post Nr. 305. Der bläht hier den Thread unnötig auf.

Gruß

Damian

[Brockmann]

Eine Beobachtung zum praktischen Umgang mit DOIFs, die ich einfach mal loswerden muss:
(am besten erstmal ganz durchlesen, ich brauche keine "Lösung", sondern möchte das Problem zur Diskussion stellen)

In den letzten Tagen musste ich mit meiner Konfiguration ziemlich herumbasteln (ich hatte es irgendwie geschafft, Geräte ohne Typ zu haben, wodurch mein Log mit Fehlermeldungen prall gefüllt wurde, aber das hatte nichts mit DOIFs zu tun). Ich habe diverse Objekte, gelöscht, umbenannt, kopiert, unter dem alten Namen neu definiert usw. Dabei sind mir ein paar Besonderheit im Umgang mit DOIFs aufgefallen. Ich bin mir nicht sicher, ob das Spezialitäten von DOIF sind, aber bei anderen Modulen ist es mir so zumindest noch nicht begegnet.

Grundlegendes "Problem" dabei ist die Prüfung beim Definieren eines DOIFs. Das DOIF wird ja quasi direkt ausprobiert und getestet, ob alle referenzierten Objekte vorhanden sind usw. Nur dann wird das DOIF auch tatsächlich definiert. Soweit, so gut.

Allerdings findet dieser Prozess bei jedem Einlesen der fhem.cfg (sprich bei jedem Neustart) erneut statt. Auch hier wird die Plausibilität geprüft und die DOIFs werden nicht definiert, wenn diese nicht gegeben ist.

Was bedeutet das in der Praxis?

   
• Man definiert ein völlig plausibles, korrektes DOIF, wo beispielsweise ein Bedingung wie ([Wetter:temperature] < 24) drin steht.
• Irgendwann später löscht man - warum auch immer - das Objekt Wetter. Soweit noch kein Problem. Das DOIF funktioniert dann selbstverständlich nicht mehr, aber es gibt zumindest eine Fehlermeldung, die darauf hinweist. Falls man also bemerkt, dass das DOIF nicht mehr wie erwartet funktioniert, kann man erfahren, warum das so ist.
• Vielleicht bekommt man es aber nicht mit und behebt das Problem nicht. Aber irgendwann speichert man mal wieder die Konfiguration per Save config. Auch noch kein Problem.
• Irgendwann macht man einen Neustart. Auf den ersten Blick immer noch kein Problem, es sei denn man achtet auf die dabei auftretende Fehlermeldung, dass ein DOIF nicht definiert werden konnte, weil der darin referenzierte Wetter-Wert fehlt.Das sieht man aber nur, wenn man die "Startseite" von FHEM öffnet und nicht direkt einen bestimmten Raum oder ein Dashboard oder Floorplan.
• Früher oder später merkt man vielleicht, dass das DOIF sich nicht mehr an der gewohnten Stelle findet und nicht mehr tut, was es soll. Noch ist aber nichts verloren, denn in der fhem.cfg steht der Code für das DOIF bis jetzt noch drin.
• Aber nur solange, bis man nach dem Neustart das erste Mal Save config anklickt. Dann wird die aktuelle Konfiguration in der fhem.cfg gespeichert. Da das DOIF nicht (mehr) dazu gehört, fliegt es nun aus der fhem.cfg. Nun ist also auch der Code des DOIFs verloren, außer selbstverständlich im Backup, das man sinnvollerweise angelegt hat. 

Im worst case hat man aber weder Fehlermeldungen noch das Fehlen des DOIFs bemerkt, immer mal wieder Save config geklickt und hin und wieder einen Neustart durchgeführt. Dann wundert man sich eben eines Tages, was eigentlich aus diesem komplexen DOIF geworden ist, das man für irgendeinen Sonderfall mühsam programmiert hatte.

Nebenbei: Es gibt noch eine spezielle Variante dieses Ablaufs, wo man noch weniger Chancen hat, etwas zu bemerken: wenn man ein referenziertes Objekt löscht und gleich anschließend unter demselben Namen neu erstellt. Das klappt erstmal problemlos und das DOIF arbeitet ordnungsgemäß weiter. Aber nur bis zum nächsten Neustart. Denn da das refenzierte Objekt NACH dem DOIF (neu)definiert wurde, steht es in der fhem.cfg nun HINTER dem DOIF. Es ist also noch nicht bekannt, wenn das DOIF definiert werden soll -> Fehlermeldung, DOIF wird nicht definiert und fliegt beim nächsten Save config aus der fhem.cfg. Warum das passiert ist völlig logisch und nachvollziehbar. Aber intuitiv ist es trotzdem irgendwie nicht, oder?


Nun hat mich dieses Verhalten nicht vor unüberwindbare Hindernisse gestellt. Ich habe es schnell bemerkt und mich darauf eingestellt. Außerdem mache ich vor umfangreicheren Änderungen auch immer eine Sicherung der fhem.cfg, so dass ich "verlorenen" Code schnell wiederherstellen konnte. Ich befürchte nur, dass weniger versierte Benutzer mit diesem Verhalten ihre Schwierigkeiten bekommen könnten. Wenn DOIF in den "FHEM-Kanon" aufgenommen und von immer mehr Leuten eingesetzt wird, könnten sich also Fehlermeldungen wie "Hilfe, mein DOIF ist verschwunden" häufen.

Für mich stellt sich aber auch grundlegend die Frage, ob es wirklich sinnvoll ist, das Definieren von DOIFs zu verweigern, wenn diese die Plausibilitätsprüfung nicht bestehen. Die Alternative wäre, wie auch jetzt eine Fehlermeldung auszugeben, das DOIF aber trotzdem in die Konfiguration aufzunehmen (zumindest wenn sich der Fehler auf die Referenzen bezieht und nicht auf Klammerung o. ä.).  Es funktioniert dann selbstverständlich nicht richtig, bis es korrigiert wurde. Aber genau das Phänomen tritt jetzt ja auch auf, wenn man einem DOIF im laufenden Betrieb ein referenziertes Objekt "unter dem Hintern weglöscht". Das Leben geht weiter, nur das DOIF tut halt nicht, was es soll und meldet statt dessen einen Fehler.

[Damian]

Eine Beobachtung zum praktischen Umgang mit DOIFs, die ich einfach mal loswerden muss:
(am besten erstmal ganz durchlesen, ich brauche keine "Lösung", sondern möchte das Problem zur Diskussion stellen)

In den letzten Tagen musste ich mit meiner Konfiguration ziemlich herumbasteln (ich hatte es irgendwie geschafft, Geräte ohne Typ zu haben, wodurch mein Log mit Fehlermeldungen prall gefüllt wurde, aber das hatte nichts mit DOIFs zu tun). Ich habe diverse Objekte, gelöscht, umbenannt, kopiert, unter dem alten Namen neu definiert usw. Dabei sind mir ein paar Besonderheit im Umgang mit DOIFs aufgefallen. Ich bin mir nicht sicher, ob das Spezialitäten von DOIF sind, aber bei anderen Modulen ist es mir so zumindest noch nicht begegnet.

Grundlegendes "Problem" dabei ist die Prüfung beim Definieren eines DOIFs. Das DOIF wird ja quasi direkt ausprobiert und getestet, ob alle referenzierten Objekte vorhanden sind usw. Nur dann wird das DOIF auch tatsächlich definiert. Soweit, so gut.

Allerdings findet dieser Prozess bei jedem Einlesen der fhem.cfg (sprich bei jedem Neustart) erneut statt. Auch hier wird die Plausibilität geprüft und die DOIFs werden nicht definiert, wenn diese nicht gegeben ist.

Was bedeutet das in der Praxis?

   
• Man definiert ein völlig plausibles, korrektes DOIF, wo beispielsweise ein Bedingung wie ([Wetter:temperature] < 24) drin steht.
• Irgendwann später löscht man - warum auch immer - das Objekt Wetter. Soweit noch kein Problem. Das DOIF funktioniert dann selbstverständlich nicht mehr, aber es gibt zumindest eine Fehlermeldung, die darauf hinweist. Falls man also bemerkt, dass das DOIF nicht mehr wie erwartet funktioniert, kann man erfahren, warum das so ist.
• Vielleicht bekommt man es aber nicht mit und behebt das Problem nicht. Aber irgendwann speichert man mal wieder die Konfiguration per Save config. Auch noch kein Problem.
• Irgendwann macht man einen Neustart. Auf den ersten Blick immer noch kein Problem, es sei denn man achtet auf die dabei auftretende Fehlermeldung, dass ein DOIF nicht definiert werden konnte, weil der darin referenzierte Wetter-Wert fehlt.Das sieht man aber nur, wenn man die "Startseite" von FHEM öffnet und nicht direkt einen bestimmten Raum oder ein Dashboard oder Floorplan.
• Früher oder später merkt man vielleicht, dass das DOIF sich nicht mehr an der gewohnten Stelle findet und nicht mehr tut, was es soll. Noch ist aber nichts verloren, denn in der fhem.cfg steht der Code für das DOIF bis jetzt noch drin.
• Aber nur solange, bis man nach dem Neustart das erste Mal Save config anklickt. Dann wird die aktuelle Konfiguration in der fhem.cfg gespeichert. Da das DOIF nicht (mehr) dazu gehört, fliegt es nun aus der fhem.cfg. Nun ist also auch der Code des DOIFs verloren, außer selbstverständlich im Backup, das man sinnvollerweise angelegt hat. 

Im worst case hat man aber weder Fehlermeldungen noch das Fehlen des DOIFs bemerkt, immer mal wieder Save config geklickt und hin und wieder einen Neustart durchgeführt. Dann wundert man sich eben eines Tages, was eigentlich aus diesem komplexen DOIF geworden ist, das man für irgendeinen Sonderfall mühsam programmiert hatte.

Nebenbei: Es gibt noch eine spezielle Variante dieses Ablaufs, wo man noch weniger Chancen hat, etwas zu bemerken: wenn man ein referenziertes Objekt löscht und gleich anschließend unter demselben Namen neu erstellt. Das klappt erstmal problemlos und das DOIF arbeitet ordnungsgemäß weiter. Aber nur bis zum nächsten Neustart. Denn da das refenzierte Objekt NACH dem DOIF (neu)definiert wurde, steht es in der fhem.cfg nun HINTER dem DOIF. Es ist also noch nicht bekannt, wenn das DOIF definiert werden soll -> Fehlermeldung, DOIF wird nicht definiert und fliegt beim nächsten Save config aus der fhem.cfg. Warum das passiert ist völlig logisch und nachvollziehbar. Aber intuitiv ist es trotzdem irgendwie nicht, oder?


Nun hat mich dieses Verhalten nicht vor unüberwindbare Hindernisse gestellt. Ich habe es schnell bemerkt und mich darauf eingestellt. Außerdem mache ich vor umfangreicheren Änderungen auch immer eine Sicherung der fhem.cfg, so dass ich "verlorenen" Code schnell wiederherstellen konnte. Ich befürchte nur, dass weniger versierte Benutzer mit diesem Verhalten ihre Schwierigkeiten bekommen könnten. Wenn DOIF in den "FHEM-Kanon" aufgenommen und von immer mehr Leuten eingesetzt wird, könnten sich also Fehlermeldungen wie "Hilfe, mein DOIF ist verschwunden" häufen.

Für mich stellt sich aber auch grundlegend die Frage, ob es wirklich sinnvoll ist, das Definieren von DOIFs zu verweigern, wenn diese die Plausibilitätsprüfung nicht bestehen. Die Alternative wäre, wie auch jetzt eine Fehlermeldung auszugeben, das DOIF aber trotzdem in die Konfiguration aufzunehmen (zumindest wenn sich der Fehler auf die Referenzen bezieht und nicht auf Klammerung o. ä.).  Es funktioniert dann selbstverständlich nicht richtig, bis es korrigiert wurde. Aber genau das Phänomen tritt jetzt ja auch auf, wenn man einem DOIF im laufenden Betrieb ein referenziertes Objekt "unter dem Hintern weglöscht". Das Leben geht weiter, nur das DOIF tut halt nicht, was es soll und meldet statt dessen einen Fehler.

ja, ich muss mal schauen, was passiert, wenn man trotz eines fehlendem Devices das Modul anlegt.

Gruß

Damian

[Damian]

OK. In der nächsten Version wird man ein DOIF-Modul trotz eines fehlenden Devices anlegen können. Zur Laufzeit gibt´s dann entsprechende Meldungen im Log, als auch unter last_error, wie bereits jetzt schon bei fehlenden Readings. Zusätzlich werden Events vorhandener Readings und Internals (z. B. STATE) jeweils als Reading des Moduls protokolliert. Das dürfte eine mögliche Analyse bei Problemen erleichtern (siehe Screenshot). Das Device bbb ist bei mir nicht existent.

Gruß

Damian

[Simon74]

Hallo,
ich würde gerne im DOELSEIF Teil einen "at" Eintrag definieren, jedoch nur wenn dieser "at" noch nicht vorhanden ist.
Ich habe es mal so versucht, was nicht funktioniert:

Code Auswählen Erweitern

DOIF (wenn dies und das) (tu das) DOELSEIF ([wz.led.off] ne "") (define wz.led.off at +00:15 set t5.wz.bs1.b:FILTER=STATE!=off off)

Wie gehts richtig ?