FHEM Forum

Zitat von: hexenmeister am 21 Mai 2014, 20:53:31
Ist wohl das, wofür ich zuerst dein IF Modul gehalten habe.  Klingt interessant.

Zitat von: hexenmeister am 21 Mai 2014, 22:45:19
Wird IMHO sehr nürzlich sein.
Interessant ist natürlich, wie hoch der Ressourcenverbrauch sein wird.

Gutes Gelingen!

Grüße,

Alexander

ZitatDen wirst du nicht messen können

Zitat von: Invers am 24 Mai 2014, 10:30:06
Ist mindestens so revolutionär wie Dashboard. Das wird unheimlich viele Dinge vereinfachen.
Ich erinnere mich noch an die Diskussion zum IF-Modul. Spätestens jetzt, durch die daraus entstandene Weiterentwicklung, ist der Nutzen (den ich nie angezweifelt habe) bewiesen.
Ist natürlich nur meine persönliche Meinung als Laie. Aber ich bin trotzdem begeistert und freue mich drauf.

ZitatSo ist das oft im Leben: gäbe es IF nicht, würde es DOIF auch nicht geben, denn den ganzen Parsermechanismus kann ich weitgehend übernehmen und dieser ist nicht trivial zu programmieren.

Zitat von: Bennemannc am 26 Mai 2014, 19:30:19
Hallo Damian,
Warum lagerst Du den Code, der in beiden Module gebraucht wird nicht in ein eigenes Modul aus?
Das würde die Sache strukturierter machen und das ausgelagerte Modul könnte auch von anderen Programmierern genutzt werden.

Gruß Christoph

Zitat von: kkoeniger am 25 Juni 2014, 12:38:11
Hatte ich auf der Befehlszeile eingegeben bzw dann bei den Internals weitergearbeitet.

In der config sieht es wie folgt aus, wobei nach dem DOIF anstelle der wetterstation stehen sollte [netatmo_M02:00:00:01:38:78:temperature] :

define DI_markise DOIF ([wetterstation:temperature] > 20 and ($hms gt "11:15" and $hms lt "18:35" and !$we)) (set markiese 70) DOELSEIF\
([wetterstation:rain] > 0 or [wetterstation:windSpeed] > 10) (set markiese off) DOELSE\
(set markiese off)

Zitat von: Invers am 25 Juni 2014, 10:20:52

DI_Kuehlschrank cmd_3, was ist das?

Wäre es nicht übersichtlicher, die Schaltbedingung anzuzeigen?
Also statt DI_Kuehlschrank cmd_1 - Anzeige = 7.5
DI_Kuehlschrank cmd_2 - Anzeige = 6.5

Oder ist da jetzt von mir was falsch interpretiert worden?

Zitatcmd_3 ist bei dir der imaginäre DOELSE-Fall (dritter Fall bei dir), den du nicht definiert hast, dieser wird auch angezeigt - steht so in der Doku.

Zitat von: Invers am 25 Juni 2014, 15:50:16
Meinst du mit Doku den Post 1? oder hab ich was verschlafen?


Ansonsten verstanden, danke.

Zitat von: kkoeniger am 25 Juni 2014, 16:26:55
Sorry - wieder der Lästige ;)

Jedesmal wenn ich händische Änderungen an der fhem.cfg (natürlich an anderer Stelle) vornehme, sind die DOIF-Defines in Fehm verschwunden. Fehlermeldung zB nach einem rereadcfg:

"0
DI_qion DOIF: unknown reading: strommess:energy
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
DI_markise DOIF: unknown reading: netatmo_ter:temperature
Please define DI_markise first
Please define DI_markise first
Please define DI_markise first
Please define DI_markise first
Please define DI_markise first
Please define DI_markise first
Please define DI_markise first "

Auch nach einem shutdown+restart oder einem reboot meines Raspi sind die Defines verschwunden.

Zitat von: kkoeniger am 25 Juni 2014, 16:43:37
Was mache ich falsch? :'(

Zitat von: kkoeniger am 25 Juni 2014, 16:50:28
Scheint aber nicht unbedingt etwas damit zu tun haben, wenn die Fehler auch nach einem Reboot auftauchen.

• Hardreset Raspi (Strom aus)
• define in die Befehlszeile von Fhem eingefügt
• attr definiert
• Save config angeklickt, Bestätigungemeldung erschien, fhem.cfg nichts gemacht
• Fhem shutdown restart
• warten bis Fhem wieder läuft, Fhem mit room aufgerufen
• keine Fehlermeldung, aber vom define ist absolut nichts zu sehen ! (nicht im Room, nicht in der config)
• fhem shutdown restart
• nur das define in die Befehlszeile von Fhem eingefügt, keine attr definiert
• Save config angeklickt, Bestätigungemeldung erschien, fhem.cfg nichts gemacht, das DOIF ist im room unsorted zu sehen
• Fhem shutdown restart
• warten bis Fhem wieder läuft
• diesmal nicht direkt einen room aufgerufen, sondern url:port/fhem?
• Errormeldung:Error messages while initializing FHEM:
  configfile: 0
  DI_qion DOIF: unknown reading: strommess:energy
  statefile: Please define DI_qion first
  Please define DI_qion first
• das DOIF ist im room unsorted NICHT zu sehen
• die config nicht in Fhem, sondern über einen FTP angschaut (dort auch nicht gespeichert), das define steht noch ganz unten
• Save config angeklickt, Bestätigungemeldung erschien
• die config nicht in Fhem, sondern über einen FTP angschaut. Das define, vor 5 sec noch ganz untenstehend ist nun weg.

Zitat von: kkoeniger am 26 Juni 2014, 08:58:38
Auch nach einem neuerlichen Eingeben des define (im room unsorted zu sehen) mit anschließendem Save config in der fhem-Befehlszeile ist das Modul DOIF nicht aufgelistet:

Gleiches übrigens nach einem reload 98_DOIF.pm (und ja, fhem ist owner des Moduls).

Konklusio für mich: auch wenn ich die fhem.cfg nicht berühre, erhalte ich Fehlermeldungen und das define verschwindet.

Zitat von: kkoeniger am 26 Juni 2014, 12:48:48
nach shutdown restart:

Error messages while initializing FHEM:
configfile: 0
DI_qion DOIF: unknown reading: strommess:energy
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first
Please define DI_qion first"

So wie ich das jetzt interpretiere, findet FHEM das Modul 98_DOIF.pm einfach nicht, obwohl fhem der owner ist und das Oktal 666. Das Modul selbst hatte ich schon wiederholt ins directory kopiert.

Ich überlege jetzt weiter, wie ich das beheben kann.

ZitatIch kenne nicht die programmierten FHEM-Abläufe bei der Auswertung der fhem.cfg...

Zitat von: rudolfkoenig am 27 Juni 2014, 08:47:16
Oder man verwendet die FILTER (http://fhem.de/commandref.html#devspec) Funktion der devspec :)

Zitat von: kkoeniger am 27 Juni 2014, 10:57:08
Beim nachstehenden define

Code Auswählen Erweitern

define DI_qion DOIF ([kkathome] eq "zu Hause" and [Solar:AC.Power] > 300) (set WZLeiste_Socket_3 on) DOELSEIF ([kkathome] eq "ausser Haus")(set WZLeiste_Socket_3 off) DOELSEIF ([Solar:AC.Power] <= 300) (set WZLeiste_Socket_3 off) DOELSE (set WZLeiste_Socket_3 off)
erhalte ich schon bei der Definition Fehler:
"ERROR:
0 DI_qion DOIF: unknown reading: Solar:AC.Power Please define DI_qion first Please define DI_qion first Please define DI_qion first Please define DI_qion first Please define DI_qion first Please define DI_qion first Please define DI_qion first"

Kann es sein, dass der "." im reading "AC.Power" die Ursache ist? Das reading ist vom device, kann es daher nicht ändern.

Zitat von: Invers am 27 Juni 2014, 09:56:16
Bisher lief alles mehrere Tage einwandfrei, auch nach diversen Neustarts der Box und auch von fhem.
Habe seit heutigem fhem-Update folgende Fehlermeldungen beim shutdown/restart :

Code Auswählen Erweitern

2014.06.27 09:52:20.666 1: define DI_Kuehlschrank DI_Kuehlschrank DOIF ([TMP_Kuehl:temperature] >= 7.5) (set Kuehlschrank on) DOELSEIF ([TMP_Kuehl:temperature] <= 6.5)  (set Kuehlschrank off): DI_Kuehlschrank DOIF: unknown reading: TMP_Kuehl:temperature
2014.06.27 09:52:20.700 1: define DI_Links_Auto_AnAus DI_Links_Auto_AnAus DOIF ([BM_Aussen:brightness] <170 and [BinIchDa] eq "present")(set Links on) DOELSEIF ([BM_Aussen:brightness] >169 and [BinIchDa] eq "present")(set Links off): DI_Links_Auto_AnAus DOIF: unknown reading: BM_Aussen:brightness
2014.06.27 09:52:20.735 1: define DI_Lampe_Korridor_Auto_AnAus DI_Lampe_Korridor_Auto_AnAus DOIF ([BM_Aussen:brightness] <165 and [BinIchDa] eq "present")(set Lampe_Korridor  on) DOELSEIF ([BM_Aussen:brightness] >164 and [BinIchDa] eq "present")(set Lampe_Korridor  off): DI_Lampe_Korridor_Auto_AnAus DOIF: unknown reading: BM_Aussen:brightness
2014.06.27 09:52:20.769 1: define DI_TVLICHT_hinten_Auto_AnAus DI_TVLICHT_hinten_Auto_AnAus DOIF ([BM_Aussen:brightness] <133 and [BinIchDa] eq "present")(set TVLICHT_hinten on) DOELSEIF ([BM_Aussen:brightness] >132 and [BinIchDa] eq "present")(set TVLICHT_hinten off): DI_TVLICHT_hinten_Auto_AnAus DOIF: unknown reading: BM_Aussen:brightness
2014.06.27 09:52:20.805 1: define DI_TVLICHT_vorne_Auto_AnAus DI_TVLICHT_vorne_Auto_AnAus DOIF ([BM_Aussen:brightness] <124 and [BinIchDa] eq "present")(set TVLICHT_vorne on) DOELSEIF ([BM_Aussen:brightness] >123 and [BinIchDa] eq "present")(set TVLICHT_vorne off): DI_TVLICHT_vorne_Auto_AnAus DOIF: unknown reading: BM_Aussen:brightness
2014.06.27 09:52:20.836 1: Including ./log/fhem.save
2014.06.27 09:52:21.883 1: configfile: DI_Kuehlschrank DOIF: unknown reading: TMP_Kuehl:temperature
Please define DI_Kuehlschrank first
Please define DI_Kuehlschrank first
DI_Links_Auto_AnAus DOIF: unknown reading: BM_Aussen:brightness
Please define DI_Links_Auto_AnAus first
Please define DI_Links_Auto_AnAus first
DI_Lampe_Korridor_Auto_AnAus DOIF: unknown reading: BM_Aussen:brightness
Please define DI_Lampe_Korridor_Auto_AnAus first
Please define DI_Lampe_Korridor_Auto_AnAus first
DI_TVLICHT_hinten_Auto_AnAus DOIF: unknown reading: BM_Aussen:brightness
Please define DI_TVLICHT_hinten_Auto_AnAus first
Please define DI_TVLICHT_hinten_Auto_AnAus first
DI_TVLICHT_vorne_Auto_AnAus DOIF: unknown reading: BM_Aussen:brightness
Please define DI_TVLICHT_vorne_Auto_AnAus first
Please define DI_TVLICHT_vorne_Auto_AnAus first

2014.06.27 09:52:22.034 0: Server started with 179 defined entities (version $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $, os linux, user root, pid 1744)
2014.06.27 09:52:22.285 1: HMLAN_Parse: HMLAN new condition ok



Was kann ich tun?

Zitat von: rudolfkoenig am 27 Juni 2014, 08:47:16
Oder man verwendet die FILTER (http://fhem.de/commandref.html#devspec) Funktion der devspec :)

Zitat von: Klaus Rubik am 27 Juni 2014, 13:58:22
Hallo Damian,

ab wann planst du das Modul mittels update zur Verfügung zu stellen?

Viele Grüße

klaus

Zitat von: cwagner am 27 Juni 2014, 15:03:44
Hallo Damian,


danke - sen-sa-tio-nell!!

Einziger Nachteil: Ich fürchte, ein zwei Thresholds entfallen, die ich gebaut hatte, um andere Thresholds ereignisgesteuert zu verändern und dadurch hole ich Dich dann doch nicht in der Threshold-Nutzung ein. Und bei DOIF bin ich ja erst bei einem... :-)

Wirklich großartig, was Du zu FHEM beiträgst.

Christian

Zitat von: Damian am 27 Juni 2014, 15:10:33
Und es sollte natürlich ein allgemeines Interesse für ein Modul da sein, bevor man es eincheckt.

Zitat von: Bombjack am 28 Juni 2014, 21:32:09
Das Modul ist klasse, aber ich bekomm´s nicht hin  :-\ Ziel ist eine automatische Beschattung auf der Südseite, das Rollo soll bei Temperaturen > 20, lt. Twilight Compasspoint Sonne im Süden und einigen Wetter Conditions auf 20% herunterfahren, dann wieder hoch wenn die Sonne im Westen steht.

Mit folgendem Code ist die Jalousie vorhin auf 20% runtergefahren:

Code Auswählen Erweitern

define DI_sz_Jalousie DOIF ([MeinWetter:temp_c] > 20 and [myTwilight:compasspoint] =~ m/south/i and ([MeinWetter:condition] eq "sonnig" or [MeinWetter:condition] eq "heiter" or [MeinWetter:condition] =~ m/klar or [MeinWetter:condition] eq "teilweise wolkig")) (set sz_Jalousie 20) DOELSEIF ([myTwilight:compasspoint] eq "west") (set sz_Jalousie on)

Jetzt haben wir allerdings nach 21 Uhr und folgende Readings sind aktuell: temp_c = 15, compasspoint = west-northwest, condition = Nieselregen. Warum um alles in der Welt löst die Bedingung aus?

Zitat von: Bombjack am 28 Juni 2014, 22:08:59
Nein, das ist ja das seltsame. Das Rollo ist einige Minuten nach dem define (vermutlich als Yahoo Wetter aktualisiert wurde) auf 20% gefahren,  Status war cmd_1.

Zitat von: Bombjack am 28 Juni 2014, 22:26:45
Da es sich um unser Schlafzimmmer Rollo handelt, habe ich das DOIF jetzt erstmal wieder rausnehmen müssen. Sonst gibt´s gleich Ärger mit meiner Frau ;) Ich probier das morgen nochmal und gebe dann Feedback.

Ich fange ja gerade erst an mit FHEM und PERL, ist der DOIF Ausdruck für das beschriebene Ziel denn grundsätzlich in Ordnung? Das die zweite Bedingung nur bei einem Twilight Event auslöst, ist schon okay denke ich. Das Rollo soll ja einfach nur wieder hoch wenn die Sonne im Westen steht und nicht unten stehen bleiben.

ZitatDas sollte für die Problemstellung kein Problem sein. Nach deiner Definition kann der Rolladen nicht unten sein, weil nach deiner Aussage z. Zt. compasspoint gleich  "west-northwest" und nicht gleich "west" ist und für den DOELSE-Fall hast du nichts definiert.

ZitatTesten kannst du übrigens immer zuerst an Aktoren (Dummys oder Lampen), die mit deiner Frau nicht kollidieren :)

Zitat von: Bombjack am 28 Juni 2014, 23:04:39
Kann ich das DOIF Modul irgendwie dazu bewegen einige Statusmeldungen auszugeben, insbesondere welche Readings verarbeitet werden wenn ein Event feuert?

Zitatkommt beim nächsten größeren Update :)

Zitat von: Bombjack am 28 Juni 2014, 23:26:09
Klingt gut  :)

Also, das mit dem Dummy habe ich hinbekommen. Gleiches Problem wie vorher: Nach dem ersten Twilight Event ist der DOIF Status cmd_1, wie kann denn das sein bei den Bedingungen?

Code Auswählen Erweitern

Internals
CFGFN
DEF
([MeinWetter:temp_c] > 20 and [myTwilight:compasspoint] =~ m/south/i and ([MeinWetter:condition] eq "sonnig" or [MeinWetter:condition] eq "heiter" or [MeinWetter:condition] =~ m/klar or [MeinWetter:condition] eq "teilweise wolkig")) (set DI_dummy 20) DOELSEIF ([myTwilight:compasspoint] eq "west") (set DI_dummy on)
NAME
DI_set_dummy
NR
99
NTFY_ORDER
50-DI_set_dummy
STATE
cmd_1
TYPE
DOIF
Readings
state
cmd_1
2014-06-28 23:18:47

ZitatDu kannst die erste Bedingung bis auf eine oder zwei Abfragen reduzieren und testen und dann immer weiter ausbauen, bis du ein Fehlverhalten feststellst, dann hast du die Fehlerquelle lokalisiert.

Zitat von: Bombjack am 29 Juni 2014, 01:57:07
Und warum wird dadurch der gesamte cmd_1 Block wahr?

Zitat2014.06.28 23:28:22 1: Including fhem.cfg
2014.06.28 23:28:22 3: telnetPort: port 7072 opened
2014.06.28 23:28:25 3: WEB: port 8083 opened
2014.06.28 23:28:25 3: WEBphone: port 8084 opened
2014.06.28 23:28:25 3: WEBtablet: port 8085 opened
2014.06.28 23:28:25 2: eventTypes: loaded 199 events from ./log/eventTypes.txt
2014.06.28 23:28:26 3: Opening CUL_0 device /dev/ttyACM0
2014.06.28 23:28:27 3: Setting CUL_0 baudrate to 38400
2014.06.28 23:28:27 3: CUL_0 device opened
2014.06.28 23:28:27 3: CUL_0: Possible commands: BCFiAZEGMKURTVWXefmltux
2014.06.28 23:28:27 2: Switched CUL_0 rfmode to HomeMatic
2014.06.28 23:28:35 1: define SonnenschutzAuto SonnenschutzAuto DOIF ([Aussen_Temp:temperature]> 25 and $hms gt "12:00" and $hms lt "17:45") (set WZ_RL_West_links 14%, set WZ_RL_West_mitte 15%,set WZ_RL_West_rechts 15%) DOELSEIF (([Aussen_Temp:temperature]< 24 and $hms gt "12:00" and $hms lt "17:45") or ($hms lt "12:00" or $hms gt "17:45")) (set WZ_RL_West_links on, set WZ_RL_West_mitte on,set WZ_RL_West_rechts on): SonnenschutzAuto DOIF: unknown reading: Aussen_Temp:temperature
2014.06.28 23:28:35 3: Please define SonnenschutzAuto first
2014.06.28 23:28:35 1: Including ./log/fhem.save
2014.06.28 23:28:36 1: configfile: SonnenschutzAuto DOIF: unknown reading: Aussen_Temp:temperature
Please define SonnenschutzAuto first
statefile: Please define SonnenschutzAuto first
Please define SonnenschutzAuto first
2014.06.28 23:28:36 1: usb create starting
2014.06.28 23:28:37 1: usb create end
2014.06.28 23:28:37 2: Error messages while initializing FHEM: configfile: SonnenschutzAuto DOIF: unknown reading: Aussen_Temp:temperature Please define SonnenschutzAuto first statefile: Please define SonnenschutzAuto first Please define SonnenschutzAuto first
2014.06.28 23:28:37 0: Server started with 97 defined entities (version $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $, os linux, user fhem, pid 2039)
2014.06.28 23:28:39 3: Device Aussen_Temp added to ActionDetector with 000:10 time

Zitat von: AndyOne am 29 Juni 2014, 08:46:00
Hallo Damien,

ich habe auch ein Problem die DOIF Schaltung Rebootsicher zu bekommen. Ich sehe den Eintrag für meinen SonnenschutzAuto in der fhem.cfg wenn ich "Save Config" mache, aber beim Laden gibt es dann doch Fehler und es wird nicht geladen. Gestern hatten wir einen Stromausfall, ich poste mal das Logfile nach dem wir wieder Strom hatten. Den DOIF Befehl musste ich heute aus einer externen Sicherung wieder in die Befehlszeile schreiben.

VG Andy

Zitat von: Bombjack am 29 Juni 2014, 01:57:07
Ich wollte damit "klar" und "überwiegend klar" abfangen,

ZitatUnd warum wird dadurch der gesamte cmd_1 Block wahr?

Zitatregex lernen ! ;)
( http://www.myregextester.com/ )

Zitat von: Groby am 30 Juni 2014, 17:08:55
Hallo Damian,

ich bekomme mit v1.1 folgende Fehlermeldungen:

Code Auswählen Erweitern


2014.06.30 16:52:02.289 1: readingsUpdate(DI_RolloBuero,last_error,no error) missed to call readingsBeginUpdate first.
2014.06.30 16:52:02.288 1: readingsUpdate(DI_RolloBuero,last_cmd_event,RolloBueroT) missed to call readingsBeginUpdate first.
2014.06.30 16:52:02.287 1: readingsUpdate(DI_RolloBuero,last_cmd,2) missed to call readingsBeginUpdate first.
2014.06.30 16:52:02.286 1: readingsUpdate(DI_RolloBuero,state,Sun2) missed to call readingsBeginUpdate first.


Dabei fällt mir auf, dass "DI_RolloBuero,state,Sun2" eigentlich "DI_RolloBuero,state,sun2" heissen müsste...

MfGroby

Zitat von: Groby am 30 Juni 2014, 17:08:55
Hallo Damian,

ich bekomme mit v1.1 folgende Fehlermeldungen:

Code Auswählen Erweitern


2014.06.30 16:52:02.289 1: readingsUpdate(DI_RolloBuero,last_error,no error) missed to call readingsBeginUpdate first.
2014.06.30 16:52:02.288 1: readingsUpdate(DI_RolloBuero,last_cmd_event,RolloBueroT) missed to call readingsBeginUpdate first.
2014.06.30 16:52:02.287 1: readingsUpdate(DI_RolloBuero,last_cmd,2) missed to call readingsBeginUpdate first.
2014.06.30 16:52:02.286 1: readingsUpdate(DI_RolloBuero,state,Sun2) missed to call readingsBeginUpdate first.


Zitat von: sentinel1 am 01 Juli 2014, 02:22:34
Hallo Damian,

ich habe eine Frage zu einer def.

Code Auswählen Erweitern

define eingang_auto DOIF ([00:30] and [keymatic_eingangstuer] eq "unlocked" and &we) (set keymatic_eingangstuer lock)

warum steht bei next_timer=02.07.2014 00:30:00 ,ich möchte die Tür am Wochenende um 00:30 abschließen?

Gruß
Claudiu

Zitatich habe folgendes DI definiert:

Code: [Auswählen]
($hms ge "06:00" and $hms le "08:15" and [Message] eq"0") (set Message 1) DOELSEIF
($hms ge "07:15" and $hms le "08:15" and [Message] eq"1") (set Message 2) DOELSEIF
($hms gt "08:15" and [Message] eq"2") (set Message 0)

Zitat von: Jens_B am 01 Juli 2014, 08:40:38
Du solltest zwischen eq und den Anführungszeichen ein Leerzeichen machen. So wie es auch in den Beispielen gezeigt ist....

Zitat von: Jens_B am 01 Juli 2014, 09:12:10
na dann ... vielleicht muß dann noch das

Code Auswählen Erweitern

attr DI do always

hinzugefügt werden? Damit auch immer getriggert wird?

Zitat von: Jens_B am 01 Juli 2014, 10:27:35
Hm, die Katze will sich anscheinend nicht selbst in den Schwanz beißen;)


Gesendet von meinem iPhone mit Tapatalk

Zitat von: Groby am 01 Juli 2014, 11:46:02
Nicht ganz, da die einzelnen Bedingungen unterschiedlich sind...

Da [Message] aber Bestandteil aller Bedingungen ist, sollten m.E. die anderen Bedingungen aus diesem DI erneut geprüft werden. Entweder im gleichen Durchgang oder erneut triggern...

Zitat von: Damian am 01 Juli 2014, 07:35:57
Zeitangaben werden immer täglich ausgeführt. Diese sind dann aber in Kombination mit anderen Bedingungen (z. B. $we) wahr oder eben nicht.

Es muss aber heißen $we und nicht &we - es ist eine Variable, genauso wie $hms für Zeitabfragen.

Gruß

Damian

Zitat von: Damian am 01 Juli 2014, 12:49:14
Edit: Funktioniert übrigens beim notify genauso, denn bei:

Code Auswählen Erweitern

define no notify t_dummy set t_dummy 1

wird t_dummy nur einmal auf 1 gesetzt, auch hier hättest du sonst schnell einen Endlos-Loop.

Zitat von: Groby am 01 Juli 2014, 13:34:47
ohne entsprechende Filter ja, aber bei:

Code Auswählen Erweitern


define no notify Message:(a) set Message b


Erzeugt ein set Message a über den notify ein set Message b inklusive der beiden Events...

MfGroby

Zitat von: Damian am 01 Juli 2014, 13:39:31
ja, genauso wie beim DOIF wird man Event a und b im Event-Monitor sehen, das selbst erzeugte Event set Message b wird aber nicht mehr beim notify ankommen.

Zitat von: Groby am 01 Juli 2014, 13:50:46
stimmt.

Wirklich schade, denn es wäre das letzte Puzzle für die Rollo Steuerung "All-in-one" gewesen...

Zitat von: Damian am 30 Juni 2014, 19:34:10
Sollte nicht mehr kommen: Version 1.2 im ersten Post.

Zitat von: Damian am 01 Juli 2014, 13:52:50
Das sind aber Mechanismen von FHEM, ich glaube nicht, dass sich Rudi auf Rekursionen einlässt. Dann dürfte die Hälfte der FHEM-Installationen loopen.

Zitat von: Groby am 01 Juli 2014, 15:36:31
Hallo Damian,

ich konnte es nicht lassen. Nicht schön, aber so geht's:

Code Auswählen Erweitern


($hms ge"07:00" and $hms le"16:00" and [Message]eq"0")
(set Message 1,{if(Value("M1")ne""){fhem("delete MI")}},define MI at +00:00:01 trigger Message *) DOELSEIF


Zitat von: Damian am 01 Juli 2014, 12:49:14
Das selbst verursachte Event kommt beim Modul nicht an.

Womöglich wird so etwas von FHEM unterbunden (muss ich mir noch genau anschauen), ansonsten könnte man schnell Loops bauen derart:

Zitat von: satprofi am 01 Juli 2014, 15:59:34
Wie verhält sich DOIF wenn man statt "and" "or" verwendet?
Könnte man dann DOELSIF weglassen?

Zitat von: Damian am 01 Juli 2014, 15:45:21
Wenn du jetzt die Syntax von DOIF im Schlaf beherrschst, dann kannst du elegant auch den IF-Befehl nutzen :)

Code Auswählen Erweitern

(set Message 1,IF ([M1] ne "") (delete MI), define MI at +00:00:01 trigger Message *)

Zitat von: satprofi am 01 Juli 2014, 16:59:41
kurze nachfrage bzgl. attr wait 300:300

bedeutet das nach eintreffen eines triggers fix 300sec gewartet wird oder dazwischen trotzdem noch geprüft wird.
beispiel: ein event fällt unter einen wert, jetzt kommt trigger, innerhalb der wartezeit steigt wert aber wieder an, und bedingung wäre weiterhin erfüllt. bleibt dann alles beim alten oder wird trotzdem geschalten?

Zitat von: Groby am 01 Juli 2014, 17:04:45
Damian,

theoretisch ja -> praktisch leider nein:

Code Auswählen Erweitern


DI_RolloBuero DOIF: unknown Device: M1


Außerdem habe ich beim Rumspielen mit "define" ein Problem beim Parsen von DOIF gefunden, sodass ich sogar "shutdown restart" machen musste. Also irgendetwas mit "{}" "()" ";;" usw. muss das ausgelöst haben:

Code Auswählen Erweitern


2014.07.01 15:10:56.254 3: Garage_timer: unknown attribute Message. Type 'attr Garage_timer ?' for a detailed list. -> hat nichts damit zu tun!!!!
2014.07.01 15:10:16.124 3: M1: unknown attribute Message. Type 'attr MI ?' for a detailed list. -> x.ter DOIF Versuch


MfGroby

Zitat von: Damian am 01 Juli 2014, 17:28:03
Wenn die Bedingung für cmd1 wahr wird, dann wird der timer auf 300 Sekunden gesetzt (erste Angabe bei wait), wenn vor dem Ablauf durch einen Trigger wieder cmd1 wahr wird, dann wird timer nicht verlängert. Wenn vor dem Ablauf Bedingung für cmd2 wahr wird, dann wird der Timer für cmd1 gelöscht und der Timer für cmd2 gestartet (zweite Angabe bei wait), falls definiert, wie bei dir, usw. Auf diese Weise lässt das erreichen, was man sonst über watchdog machen würde.

Gruß

Damian

Zitat von: Damian am 01 Juli 2014, 17:35:37
Wenn der Parser-Fehler nachvollziehbar ist, dann kann ich erst etwas unternehmen.

Zitat von: satprofi am 01 Juli 2014, 17:43:27


aber es wartet nicht mal die 5 min ab,   last_cmd_event Pac 2014-07-01 17:38:37  , und um 17:40 wurde geschalten.

Zitatich habe seit Gestern Abend folgende Fehlermeldung in der FHEM.log

^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at fhem.pl line 3556.

Das einzige was ich Gestern neu gemacht habe war deine Version 1.2. Oder gibt es eine Idee was das sein könnte.

Zitat von: kkoeniger am 02 Juli 2014, 11:06:34
Wenn ich "attr disable 1" setze, so bleibt das letzte State unverändert entsprechend dem last_cmd stehen. Ware es nicht sinnvoller "disabled" anzuzeigen?

Zitat von: Jens_B am 02 Juli 2014, 08:38:30
Das liegt möglicherweise daran, das Du irgendwo in einer oder mehreren Deiner Definitionen für einen regex Ausdruck nur "*" statt ".*" gesetzt hast.

Hat mit dem DOIF Modul zunächst erstmal nicht direkt was zu tun, möchte ich meinen.

Gruß
Jens

Zitat von: Damian am 02 Juli 2014, 11:08:51
ja, kommt auf die todo-Liste für´s nächste Release :)

...

Zitat von: satprofi am 02 Juli 2014, 14:44:40
hallo.
wie wird eigentlich eine negative zahl ausgewertet?
habe hier eine < 100 , aber der zustand wird nicht angezeigt, tatsächlicher wert -200 .

ich denke da ist etwas grösseres im argen, weil letzter cmd war < 2000.

Code Auswählen Erweitern


([Ueberschuss] > 2000 and $hms gt "08:00" and $hms lt "22:00") (set LED_02 led green) DOELSEIF ([Ueberschuss] < 2000 and $hms gt "08:00" and $hms lt "22:00") (set LED_02 led orange) DOELSEIF ([Ueberschuss] < 100 and $hms gt "08:00" and $hms lt "22:00") (set LED_02 led red) DOELSE (set LED_02 led off)


[edit]
hallo.
ich habe das ganze mit IF gelöst, DOIF dürfte nicht für solche Probleme optimal sein.

gruss

Zitat von: Brockmann am 03 Juli 2014, 09:30:33
Ich habe eine grundsätzliche Verständnisfrage zum DOIF.

Ich möchte bei eintretender Dämmerung, aber nicht vor 17:00 Uhr, eine Lampe einschalten, wenn jemand zu Hause ist. Das würde ich nach meinem Verständnis von DOIF so umsetzen:

Code Auswählen Erweitern

define Light_ctrl DOIF (LICHT_STATUS eq "Daemmerung" and $hms gt "17:00" and HAUS_STATUS eq "Anwesend")
(set Licht on) DOELSE (set Licht off)

Was passiert, wenn die Dämmerung schon um 16:30 Uhr eintritt? Die Bedingung $hms gt "17:00" ist da noch nicht erfüllt, also würde korrekterweise nicht geschaltet.
Aber wird dann intern ein Timer gesetzt, der um 17:00:01 Uhr erneut prüft, ob nun alle Bedingungen (noch) erfüllt sind? Oder macht das DOIF in diesem Fall einfach nichts mehr, bis es erneut extern angestossen wird, beispielsweise durch eine Änderung bei HAUS_STATUS?
Oder anders gefragt: Wird die Lampe im 17:00:01 Uhr eingeschaltet, wenn schon vorher Dämmerung eingetreten ist oder bleibt sie aus?

Ich würde eigentlich die erste Variante erwarten. Wenn nicht, wie könnte ich das DOIF in einem solchen Fall anders gestalten, um die gewünschte Funktionalität zu erreichen?
Aus den Beispielen im ersten Post konnte ich das so nicht ableiten.

Zitat von: Jens_B am 03 Juli 2014, 10:17:53
Ich habe jetzt auch mal eine Frage zu DOIF:
Ich würde gern meine Terrassenbeleuchtung einschalten, wenn twilight im aktevent "ss_weather" hat, und die Beleuchtung soll wieder ausgeschaltet werden, wenn 2 bestimmte Rollladen abends geschlossen werden. Leider funktioniert das nicht so wirklich, weil natürlich das Akt_event sich danach noch wieder ändert...
Wie mache ich es mit DOIF richtig, damit das so funktioniert wie ich es mir vorstelle?

Achja, der Schalter draußen ist ein Homematic.

Gruß
Jens

Zitat von: Jens_B am 03 Juli 2014, 10:17:53
Ich habe jetzt auch mal eine Frage zu DOIF:
Ich würde gern meine Terrassenbeleuchtung einschalten, wenn twilight im aktevent "ss_weather" hat, und die Beleuchtung soll wieder ausgeschaltet werden, wenn 2 bestimmte Rollladen abends geschlossen werden. Leider funktioniert das nicht so wirklich, weil natürlich das Akt_event sich danach noch wieder ändert... Hm. Im Logfile habe ich zudem dann ziemlich viele Schaltversuche in Bezug auf meine Beleuchtung:
mein Code sieht folgendermaßen aus:

Code Auswählen Erweitern

([ROLLLADEN_KUECHE] eq "zu" and [ROLLLADEN_WZ_4] eq "zu")  (set LICHT_TERRASSE_KUECHE aus) DOELSEIF ([mytwilight:aktEvent] eq "ss_weather" and $hour > 15) (set LICHT_TERRASSE_KUECHE an) DOELSEIF ([LICHT_TERRASSE_KUECHE] ne "aus") (set LICHT_TERRASSE_KUECHE aus)

Wie mache ich es mit DOIF richtig, damit das so funktioniert wie ich es mir vorstelle?

ZitatIch kenne nicht alle Bedingungen, die bei dir in der Realität vorkommen können, daher mal Folgendes unter Vorbehalt:

Code: [Auswählen]
([mytwilight:aktEvent] eq "ss_weather" and ($hour > 15 or [16:01])) (set LICHT_TERRASSE_KUECHE an) DOELSEIF ([ROLLLADEN_KUECHE] eq "zu" and [ROLLLADEN_WZ_4] eq "zu" and $hour > 15) (set LICHT_TERRASSE_KUECHE aus)

Wenn die Rollläden vor 16:00 Uhr schon unten waren, dann passiert hier allerdings nichts.

Du kannst auch im DOELSEIF-Fall noch eine Zeitangabe zum Triggern angeben, wenn du zum Ausschalten des Lichtes auf Nummer sicher gehen willst.

Gruß

Damian

Zitat von: Damian am 03 Juli 2014, 11:11:09
Die Abfrage bei dir wird also ausgewertet, wenn LICHT_STATUS oder HAUS_STATUS ein Event sendet. Das bedeutet, wenn Dämmerung und vor 17:00 stattgefunden hat und HAUS_STATUS vorher schon anwesend war, dann wird nach 17:00 nichts passieren. Wenn du sicherstellen willst, dass auch nach 17:00 geprüft wird, dann musst du das mit Hilfe einer Zeitangabe berücksichtigen. z. B.

Code Auswählen Erweitern

define Light_ctrl DOIF (([LICHT_STATUS] eq "Daemmerung" or [17:01])  and $hms gt "17:00" and [HAUS_STATUS] eq "Anwesend")
(set Licht on) DOELSE (set Licht off)

Zitat von: Brockmann am 03 Juli 2014, 14:18:56
Aber wenn durch das [17:01] um 17:01 Uhr getriggert wird, ist dieser Teil der OR-Klammer doch wahr, oder?
Würde so nicht einfach um 17:01 Uhr geschaltet werden, selbst wenn noch gar keine Dämmerung ist?

Zitat von: Damian am 03 Juli 2014, 14:25:17
Du hast Recht, mein Fehler. Es muss viel mehr heißen:

Code Auswählen Erweitern

define Light_ctrl DOIF (([LICHT_STATUS] eq "Daemmerung")  and ($hms gt "17:00" or [17:01]) and [HAUS_STATUS] eq "Anwesend")
(set Licht on) DOELSE (set Licht off)

Zitat von: satprofi am 03 Juli 2014, 16:04:26
mit DOIF leider nicht

Code Auswählen Erweitern


([Klima_SZ] eq "off" and $hms gt "08:00 and lt "22:00") (set LED_04 led green) DOELSE (set LED_04 led off)


Zitat von: Brockmann am 03 Juli 2014, 15:10:34
Ja, so sollte es gehen. Zwar nicht ganz so elegant wie erhofft. Aber Deine Bedenken bzgl. Schleifen durch Selbsttriggern kann ich nachvollziehen.

Danke für die Hinweise.

Zitat von: Brockmann am 03 Juli 2014, 16:22:29
Was soll das DOIF denn bewirken?
Wenn zwischen 08:00 Uhr und 22:00 Uhr der Status von KLIMA_SZ auf "off" wechselt, wird die LED angeschaltet.
Wenn zwischen 08:00 Uhr und 22:00 Uhr der Status von KLIMA_SZ auf irgendwas anderes wechselt, wird die LED ausgeschaltet.
Nicht mehr, nicht weniger.

In jedem Fall tut das DOIF nur etwas, wenn sich am Status von Klima_SZ etwas ändert.
Es tut nichts um 08:00 Uhr und nichts um 22:00 Uhr, falls Du das erwartest.

Zitat von: satprofi am 03 Juli 2014, 17:13:54
mehr habe ich auch nicht erwartet, aber leider schaltet die Led nur wenn ich sie manuell schalte.
DOIF leider nicht.
Oder wird die led nur einmal ausgeschaltet, danach erst wieder am nächsten tag nach 8:00h ?
Kann es auch sein, das DOIF zwischenzeitlich manuell getätigte commandos nicht erkennt und nur seinen letzten last_cmd_event auswertet?

Zitat von: Damian am 03 Juli 2014, 17:01:52
ja, vielleicht lasse ich mir noch etwas für Zeitintervalle einfallen.

Zitat von: satprofi am 03 Juli 2014, 18:21:06
Heisst das, das während eines neustartes von fhem ein zwischenzeitliches event nicht von DOIF erkannt wird? wie kann man eine abfrage der verschiedenen state´s regelmässig erwirken?

Zitat von: satprofi am 03 Juli 2014, 18:41:14
Sorry fürs unverständnis.

Ich habe einige readings die einen actor über DOIF schalten. Wenn jetzt eine bedingung wahr ist wird geschalten, ok. aber was passiert wenn zwischenzeitlich ein anderes reading den state wechselt? egal ob autom. od. manuell? erkennt DOIF dies?

ebenso wenn fhem eine "pause" einlegt, in der zwischenzeit ein state umswitcht?

mein vorhaben ist, eine klima autom. schalten zu lassen, aber vielleicht zwischenzeitlich manuell einzugreifen, per fhem.
aber zur zeit wird nach dem manuellen eingriff von DOIF nichts mehr unternommen, und wenn es nur die Abfrage der raumtemperatur ist, die eigentlich die klima über DOIF schaltet.

Zitat von: Brockmann am 03 Juli 2014, 18:32:07
Vielleicht denkst Du über das Thema Intervalle auch etwas grundlegender nach. Sowohl bei DOIF als auch IF wäre es toll, wenn man Intervalle direkt angeben könnte, etwa
(40 < [Bad:humidity] < 70) oder vielleicht auch in einer anderen Syntax, wenn das einfacher handbar ist. Das macht den Code intuitiver und besser lesbar, finde ich.
(Mir ist klar, dass das durch Verwenden von Perl-Ausdrücken schon jetzt möglich ist, aber das macht es eben nicht intuitiver und lesbarer.)

Die Idee, beim Definieren von statischen Uhrzeit diese bei Erreichen jeweils einmal zu triggern, finde ich gut. Allerdings macht das einen kleinen, aber feinen Unterschied.
Jetzt-Zustand: Wenn im Zeitraum Z Bedingung B eintritt, führe Aktion A aus.
Dann-Zustand: Wenn Bedingung B gegeben ist, führen im Zeitraum Z Aktion A aus.

Ich bin mir nicht sicher, aber ich denke, es gibt für beide Varianten sinnvolle Anwendungsszenarien.

Zitat von: Damian am 03 Juli 2014, 22:06:25
Ich werde mich hüten selbst logische Abfragen auszuwerten, dass habe ich bereits beim THRESHOLD-Modul versucht. Über eine AND bzw. OR-Verknüpfung bin ich nicht gekommen. Die Besonderheit des DOIF-Moduls wie auch beim IF ist, dass ich die Eigenschaften eines Interpreters (hier Perl) ausnutze. Und genau diese Eigenschaft macht die Sache recht flexibel.

Zitat von: Brockmann am 03 Juli 2014, 22:46:30
Es ginge ja nicht so sehr darum, selbst logische Abfragen auszuwerten, sondern dem Benutzer das Definieren von Intervallen möglichst einfach zu machen.
(40 < [Bad:humidity] < 70) müssten ja nur intern in ([Bad:humidity] > 40 and [Bad:humidity] < 70) umgesetzt und so an den Interpreter weitergereicht werden.
Aber mag sein, dass ich da zu simpel denke und sich das nicht so ohne weiteres umsetzen lässt.

Zitat von: Damian am 03 Juli 2014, 13:01:51
Ich kenne nicht alle Bedingungen, die bei dir in der Realität vorkommen können, daher mal Folgendes unter Vorbehalt:

Code Auswählen Erweitern

([mytwilight:aktEvent] eq "ss_weather" and ($hour > 15 or [16:01])) (set LICHT_TERRASSE_KUECHE an) DOELSEIF ([ROLLLADEN_KUECHE] eq "zu" and [ROLLLADEN_WZ_4] eq "zu" and $hour > 15) (set LICHT_TERRASSE_KUECHE aus)

Wenn die Rollläden vor 16:00 Uhr schon unten waren, dann passiert hier allerdings nichts.

Du kannst auch im DOELSEIF-Fall noch eine Zeitangabe zum Triggern angeben, wenn du zum Ausschalten des Lichtes auf Nummer sicher gehen willst.

Gruß

Damian

Zitat von: Jens_B am 04 Juli 2014, 09:05:43
Muss ich in der Definition das mit der Uhrzeit [16:01] drin haben?
Oder würde es reichen einfach nur abzufragen ob $hour > 15 ist?

Zitat von: Damian am 03 Juli 2014, 22:50:39
Parser ist eine Wissenschaft für sich.
Ich kümmere mich z. Zt. nur um "eckige Klammern" und schaue, ob zu jeder Klammer auf eine Klammer zu existiert, und kümmer mich in der Abfrage sonst um nichts :)

Zitat von: Brockmann am 04 Juli 2014, 10:02:53
Das [16:01] sorgt dafür, dass das DOIF um 16:01 einmal getriggert wird.
Das deckt den Fall ab, dass ss_weather vor 16:00 Uhr erfolgt. Dann würde das DOIF sonst nämlich gar nicht schalten.

Zitat von: MaJu am 04 Juli 2014, 13:59:47
Warum kommen hier so lange Pausen rein bzw. wie bekomme ich die raus?

Zitat von: RoBra81 am 04 Juli 2014, 15:16:47
Hallo,

ich habe mein Treppenhauslicht mit notifies gebaut und wollte das nun testweise mit DOIF umbauen. Dabei bin ich auf folgendes Problem gestoßen: Sobald der Bewegungsmelder eine Bewegung erkennt, wird das Licht eingeschaltet und ein at für das Ausschalten definiert, sofern dieses noch nicht existiert anderenfalls wird es modifiziert. Und hier liegt mein Problem: zur Definition des DOIF exisitiert das notify natürlich noch nicht, was bei der Definition von DOIF einen Fehler generiert und kein DOIF definiert.

Gibt es hierfür eine Lösung?

Ronny

Zitat von: MaJu am 04 Juli 2014, 13:59:47

Das Problem: Das Relais wird mehr als nur 0,01 Sekunden gehalten, sondern etwa 5 Sekunden. Vorher hatte ich für jede Lampe ein eigenes Notify, da hatte es halbwegs funktioniert (es war nie mehr als 1 Sekunde).
Und: Wenn ich den alle Lampen schalte und deshalb für alle Lampen der Schaltbefehl kommt, dann werden nacheinander erst alle Relais angezogen, kurz gewartet, und danach nacheinander wieder losgelassen. Die Relais sind damit ca. 10 Sekunden unter Strom. Die Stromstoßschalter quittieren das mit einem kräftigen Brummton, der nicht gesund klingt.

Warum kommen hier so lange Pausen rein bzw. wie bekomme ich die raus?

Zitat von: RoBra81 am 04 Juli 2014, 15:44:36
Hier mein notify:

Code Auswählen Erweitern


define OG.hf.BM.Treppe.not.inaktiv notify OG.hf.BM.Treppe.*51200.* IF (!$defs{'OG.hf.LI.Treppe.at.off'})
(
  define OG.hf.LI.Treppe.at.off at +00:00:05 set OG.hf.LI.Treppe off,
  attr OG.hf.LI.Treppe.at.off room Hausflur
)
ELSE
(
  IF ([OG.hf.LI.Treppe.at.off:&TRIGGERTIME] - time < 5)
  (
    modify OG.hf.LI.Treppe.at.off +00:00:05
  )
)
;
IF (!$defs{'OG.hf.LI.Schuhschrank.at.off'})
(
  define OG.hf.LI.Schuhschrank.at.off at +00:00:10 set OG.hf.LI.Schuhschrank off,
  attr OG.hf.LI.Schuhschrank.at.off room Hausflur
)
ELSE
(
  IF ([OG.hf.LI.Schuhschrank.at.off:&TRIGGERTIME] - time < 10)
  (
    modify OG.hf.LI.Schuhschrank.at.off +00:00:10
  )
)


... und folgendes DOIF wollte ich daraus machen:

Code Auswählen Erweitern


define OG.hf.LI.Xxx.DI DOIF ([OG.hf.BM.Treppe:sensor] eq "51200")
(
  IF (!$defs{'OG.hf.LI.Treppe.at.off'})
  (
    define OG.hf.LI.Treppe.at.off at +00:00:05 set OG.hf.LI.Treppe off,
    attr OG.hf.LI.Treppe.at.off room Hausflur
  )
  ELSE
  (
    IF ([OG.hf.LI.Treppe.at.off:&TRIGGERTIME] - time < 5)
    (
      modify OG.hf.LI.Treppe.at.off +00:00:05
    )
  )
  ,
  IF (!$defs{'OG.hf.LI.Schuhschrank.at.off'})
  (
    define OG.hf.LI.Schuhschrank.at.off at +00:00:10 set OG.hf.LI.Schuhschrank off,
    attr OG.hf.LI.Schuhschrank.at.off room Hausflur
  )
  ELSE
  (
    IF ([OG.hf.LI.Schuhschrank.at.off:&TRIGGERTIME] - time < 10)
    (
      modify OG.hf.LI.Schuhschrank.at.off +00:00:10
    )
  )
)
DOELSEIF ([OG.hf.BM.Treppe:sensor] eq "0")
(
  set Test an
)

Zitat von: RoBra81 am 04 Juli 2014, 15:44:36
Hier mein notify:

ZitatAllerdings tauchen die Events immer doppelt im Log auf, jemand eine Idee warum?

Zitat([MeinWetter:temp_c] > 20 and [myTwilight:compasspoint] =~ m/south/i and [sz_Jalousie] eq "on" and ([MeinWetter:condition] eq "sonnig" or [MeinWetter:condition] eq "heiter" or [MeinWetter:condition] eq "teilweise wolkig"))

Zitat von: Damian am 04 Juli 2014, 16:20:07
Ist schon lustig zu sehen, was ihr da so alles programmiert. So hast du mit DOIF kaum einen Vorteil gegenüber einem notify. Wann liefert bei dir der Sensor 51200 und wann 0?  So etwas sollte man eigentlich als Zweizeiler hinbekommen.

Gruß

Damian

ZitatNein, nicht immer.

ZitatDas passiert aber wenn von den Bedingungen mehr als eine triggert (und das ist zwangsläufig der Fall) und dann auch noch wahr ist.

Zitat von: Damian am 04 Juli 2014, 15:41:02
Schau zunächst wie lange die Pausen sind, wenn du in der Kommandozeile Folgendes eingibst:

Code Auswählen Erweitern

IF (1) (set PIFACE 0 1,sleep 0.01,set PIFACE 0 0)

Zitat von: RoBra81 am 04 Juli 2014, 17:56:14
Hat mich auch eine Menge Gehirnschmalz gekostet  :)

Ich kann ja mal das ganze Szenario posten, damit es verständlicher wird: Ich habe im Flur zwei Lampen, einen Bewegungsmelder und zwei Taster. Wenn der Bewegungsmelder eine Bewegung erkennt (Sensor 0) wird über ein Notify (das habe ich hier nicht gepostet) das Licht in Abhängigkeit von der Dämmerung angemacht und gegebenenfalls vorhandene Timer (at) die das Licht ausschalten würden gelöscht, wenn diese eine Restzeit kleiner 10 bzw. 5 Sekunden haben (beide Lampen haben einen eigenen Ausschalttimer, da ich diese unterschiedlich lange anlassen möchte). Erkennt der Bewegungsmelder keine Bewegung mehr wird mit dem gezeigten notify ein Timer (at) definiert, um die Lichter auszuschalten. Dies passiert aber ebenfalls nur, wenn noch kein Timer definiert ist oder dieser eine Restzeit kleiner 10 bzw. 5 Sekunden hat. Hintergrund ist, dass ich über die Taster  ebenfalls das Licht anschalten und Timer zum abschalten definiere, die für 1 bzw. 30 Minuten laufen (kurzer oder langer Tastendruck).

Der Grund, dass ich hierfür diese ausgefallenen ("lustigen") notifies nutze ist, dass ich Homematic-Devices (CUL) nutze, die kein on-for-timer unterstützen...

Zitat von: Bombjack am 04 Juli 2014, 18:02:53
Wenn ich das weglasse gibt es auch mehrfach Schaltbefehle, da die MyTwilight Aktualisierungsintervalle recht kurz sind.

Zitat von: Damian am 05 Juli 2014, 09:08:29
on-for-timer funktioniert bei mir auch bei HM-Devices (mit HM-LAN-Adapter). Wird wohl softwareseitig gelöst sein.

ZitatIch habe Wired-Devices (HMW_LC_Sw2_DR) an HM485, da gibt's kein on-for-timer...

Zitat von: RoBra81 am 05 Juli 2014, 10:53:38
Ich habe Wired-Devices (HMW_LC_Sw2_DR) an HM485, da gibt's kein on-for-timer...

ZitatMal angenommen, on-for-timer würde irgendwann gehen

Zitat von: RoBra81 am 05 Juli 2014, 16:34:25
Die Homematic wired Geräte sind imho nicht in CUL_HM drin sondern haben ein eigenes Modul. Mal angenommen, on-for-timer würde irgendwann gehen, bekäme ich den heraus, ob und wie lange der Timer schon läuft? Das brauche ich ja für mein Szenario...

ZitatIch werde mir noch etwas für DOIF einfallen lassen, dass man auch solche Fälle ohne on-for-timer mit einer Zeile erledigen kann, so zu sagen, als Gegenstück zu wait.

Zitat von: Puschel74 am 05 Juli 2014, 17:32:28
Hallo,
Steht dir natürlich frei das zu tun  ;)

Ich würde aber eher favorisieren das on-/off-for-timer in die jeweiligen Device-Module mit aufgenommen wird.
Dann haben auch diejenigen etwas davon die weder IF noch DOIF verwenden und du musst Dir nicht noch zusätzlich Gedanken machen.

Grüße

Zitatja, on-for-timer würde allerdings je nach Gerätetyp (insb. FS20) ein Kommando an das Gerät schicken und unnötig Traffic produzieren, das würde bei DOIF nicht passieren.

Zitat von: Puschel74 am 05 Juli 2014, 17:40:58

Wenn ich ein FS20-Device mit on-for-timer einschalte läuft im Device die Zeit ab.
FHEM sendet kein off mehr an das Gerät also nur ein! Sendebefehl.

Zitat von: Puschel74 am 05 Juli 2014, 17:56:37
Hallo,

ah, das meinst du.

Ja das stimmt.
Daher habe ich das in meinen Codes bereits abgefangen  ;)

Grüße

ZitatDaher habe ich das in meinen Codes bereits abgefangen

Zitat von: Puschel74 am 05 Juli 2014, 21:45:31
Hallo,

daswar mal wieder etwas zu kurz gedacht von mir.

Ich hab die Meldezeiten der Bewegungsmelder auf die on-for-timer-Zeiten der Aktoren abgestimmt.
Wenn der Aktor on-for-timer 120 Sekunden hat dann meldet der Bewegungsmelder frühestens nach 115 Sekunden wieder wenn er noch eine Bewegung erkennt.
Ich hab auch Aktoren die on-for-timer 1920 Sekunden haben (FS20 kann nur so "krumme" Werte wenn es länger geht) - der Badezimmerventilator ist einer davon.
Da meldet der Bewegungsmelder auch nur alle x Sekunden (ich muss nochmal nachschauen wann genau) eine erkannte Bewegung.

Ob das mit allen Bewegungsmelder ght weiß ich nicht und denke ich mal nicht.
Aber FS20-BM können dahingehend eingestellt werden.
Ich denke mal das HM-BW das auch können.
Das würde ja auch im Hinblick auf die Batterielebensdauer Sinn machen nicht alle a Sekunden eine erkannte Bewegung zu melden (wobei a die kürzeste Zeit im BM ist).

Von daher wäre es auch besser den BM dahingehend zu programmieren und du müstest dir wieder keinen Kopf machen wie du das im DOIF abfangen kannst  ;)

Grüße

Zitat von: Damian am 05 Juli 2014, 17:26:15
Du hast meine Frage nicht genau beantwortet, wann 51200 kommt und wann 0. Ich gehe mal davon aus, dass bei Bewegung 51200 kommt, dann würde mit:

Code Auswählen Erweitern

define OG.hf.LI.Xxx.DI DOIF ([OG.hf.BM.Treppe:sensor] eq "51200") (set OG.hf.LI.Treppe on-for-timer 5)
attr OG.hf.LI.Xxx.DI do always

dein Treppenlicht bei erster Bewegung angehen und bei jeder weiteren Bewegung innerhalb von 5 Sekunden, um weitere 5 Sekunden verlängert und wenn keine Bewegung innerhalb von 5 Sekunden kommt wieder ausgehen.

Das war´s.

Zitat von: Puschel74 am 05 Juli 2014, 16:48:50
Melde dich doch einfach mal dort und frag Dirk (das ist glaube ich der Modulautor) ob er on-/off-for-timer in das Modul einbauen könnte.
...
Die Modulautoren müssen nur danach gefragt/darauf hingewiesen/darum gebeten werden.

Zitat von: krikan am 05 Juli 2014, 16:55:18
on-for-timer geht bereits jetzt, wenn Du den Umweg über readingsProxy gehst http://www.fhemwiki.de/wiki/ReadingsProxy .

Zitat von: RoBra81 am 06 Juli 2014, 14:17:20
Daher bin ich wieder bei meinen 6 mehr oder weniger umfangreichen notifies (Bewegungsmelder ein/aus, 2 Taster lang/kurz), die ich eben testweise durch 1 DOIF ersetzen wollte...

ZitatIch kann zwar nun on-for-timer für meine Homematic-Wired Geräte nutzen, bekomme aber nicht heraus, wie lange es noch dauert, bis das Gerät abgeschaltet wird.

Zitat von: RoBra81 am 06 Juli 2014, 14:17:20
da mein Bewegungsmelder bei Bewegung ein Relais schließt und erst bei "Keine Bewegung" wieder öffnet

Zitat von: cruser1800 am 06 Juli 2014, 21:42:56
Ich habe leider auch ein kleines Problem. DOIF arbeitet leider nicht immer den ersten Teil ab, obwohl die Bedingungen alle Wahr sind. Der zweite Teil DOELSIF wird leider nie abgearbeitet. Die Bedingung ist 1.

Code Auswählen Erweitern

([001_Wetterstation:temperature]>25 and [001_Wetterstation:brightness]>65 and [Thermostat_Wohnzimmer:measured-temp]>22 and [002_Fenster_TR] eq "closed" and $hms gt "12:00" and $hms lt "20:30") (set Jalousie_TR 40,set Jalousie_dummy 40,set Verschattung_dummy 1) DOELSEIF ([Verschattung_dummy]>1) (set Jalousie_TR hoch,set Jalousie_dummy hoch,set Verschattung_dummy 0)

Was mache ich falsch?

Danke für die Hilfe

Gruß Lutz

Zitat von: satprofi am 07 Juli 2014, 15:51:02
hallo.
ich habe auch kleines problem wo ich keine lösung finde.
ich schalte die klima ab einen bestimmten wert ein. das klappt auch.
jetzt möchte ich aber , wenn dieser wert bis zu einem anderen wert nicht unterschritten wird die klima weiterlaufen lassen.
wie realisiert man das mit DOIF ?

z.b.  ab 1500W klima on, unter 1000W klima off.

Zitat von: Damian am 06 Juli 2014, 22:00:24
Version 1.4 im ersten Post.

-status "disabled" eingebaut
-Ein cmd-Status wird nur noch dann für einen nicht existierenden ELSE-Fall gesetzt, wenn es nur den DOIF-Fall gibt. Das grundsätzliche Setzen eines cmd-Status für nicht existierenden ELSE-Fall war ungünstig und machte die Wait-Timer-Steuerung zunichte. Das Beispiel im Post #190 würde z. B. mit Version 1.3 nicht funktionieren.

Gruß

Damian

Zitat von: cruser1800 am 07 Juli 2014, 21:01:48
Danke für deine Antwort. Ist es jetzt bei der Änderung so, dass wenn DOIF falsch ist DOELSIF abgearbeitet wird ohne das es ein weiteres Notify benötigt?

Gruß

Zitat von: Hoeness am 07 Juli 2014, 23:02:29

Mit dem folgende DOIF Ausdruck schalte ich jetzt meine 1_Bew_Eiche_DOIF ein.

Code Auswählen Erweitern

define Wasser_Eiche DOIF ([Automatik_DOIF] eq "an") (set 1_Bew_Eiche_DOIF on-for-timer 3) DOELSE (set 1_Bew_Eiche_DOIF aus)

In dem Beispiel schalte ich 1_Bew_Eiche_DOIF für 3 Sekunden ein.

Wie kann ich jetzt den Wert "meiner" Bewässerungszeit  - Bewaesserung_Zeit- in dem Ausdruck benutzen?

Zitat von: kud am 08 Juli 2014, 19:51:10
Tolle Sache mit dem DOIF. Danke.
Aber mein Eintrag

define Feuchte_warnung DOIF ([arduino_ana_1] > 200) (system('/usr/bin/mplayer /opt/TTS/Wassereinbruch_bilge.mp3 &'))

liefert im Event-Monitor ein

DOIF Feuchte_warnung last_error: system('/usr/bin/mplayer /opt/TTS/Wassereinbruch_bilge.mp3 &'): Unknown command system('/usr/bin/mplayer, try help.

Hab ich da was übersehen?

Gruss
KU

Zitat von: satprofi am 11 Juli 2014, 11:53:09
Hallo.
Warum schaltet DOIF trotzdem wenn Leistung unter 1000W

Code Auswählen Erweitern


DOELSEIF ([Heizungsmode] eq "off" and [Pac] < 1000 and $hms gt "10:00" and $hms lt "18:30") (set Klima_SZ off)
dieses commando wurde ausgewertet lt. state

Zitat von: satprofi am 11 Juli 2014, 14:39:06
achso!
ich dachte es wird regelmässig geprüft. heisst wenn nach 10h die leistung unter 1000 fällt, passiert nichts mehr? wobei "off" bei mir für einschalten steht.
es sollte zw. 10 u. 18:30h die klima aus-, bzw. wieder eingeschalten werden wenn der wert unter  od. über 1000w steht.

Zitat von: satprofi am 11 Juli 2014, 15:23:46
aber bei uhrzeit ändert sich status ja minütlich? kommt das nicht durch?
pac sendet alle 3min., und wait ist auf 300

Zitat von: Hoeness am 12 Juli 2014, 22:27:16
Hi,

ich bins mal wieder ;-)

Ich möchte mit DOIF ein dummy toggeln (aus/an):

Der Trigger hierzu kommt von einem Taster über GPIO: hier die Config:

Code Auswählen Erweitern

######## Input 4 -Beregnung
define In4_Beregnung RPI_GPIO 10
attr In4_Beregnung active_low no
attr In4_Beregnung debounce_in_ms 50
attr In4_Beregnung devStateIcon aus:rain-icon_off an:rain-icon_on
attr In4_Beregnung direction input
attr In4_Beregnung eventMap on:an off:aus
attr In4_Beregnung group 1_Input
attr In4_Beregnung interrupt rising
attr In4_Beregnung pud_resistor down
attr In4_Beregnung room Bewässerung_DOIF
attr In4_Beregnung webCmd an:aus

Der dummy ist wie folgt konfiguriert:

Code Auswählen Erweitern

######## Beleuchtung Terasse
define man_Bewaesserung dummy
attr man_Bewaesserung group 2_Output
attr man_Bewaesserung room Bewässerung_DOIF
attr man_Bewaesserung webCmd an:aus
attr man_Bewaesserung devStateIcon aus:Lampe_off an:Lampe_on
attr man_Bewaesserung eventMap on:aus off:an

Mein DOIF sieht wie folgt aus:

Code Auswählen Erweitern

define n_In4_Beregnung DOIF ([In4_Beregnung] eq "an" and [man_Bewaesserung] eq "aus") (set man_Bewaesserung an) DOELSEIF ([In4_Beregnung] eq "an" and [man_Bewaesserung] eq "an") (set man_Bewaesserung aus)

Irgendwie stehe ich hier auf dem Schlauch.

Zitat von: Damian am 13 Juli 2014, 16:40:42
Es kommt drauf an, was du genau haben möchtest. Bisher geht die Bewässerung an, wenn du deinen dummy aus machst und aus wenn du deinen dummy an machst und immer nur dann wenn in in4_Beregnung an. Wenn In4_Beregnung aus ist passiert gar nichts. Wenn du etwas anderes haben willst, dann musst du es genauer spezifizieren.

Zitat von: Brockmann am 13 Juli 2014, 16:50:14
Ich denke, es ist anders gemeint. Das DOIF soll von In4_Beregnung getriggert werden. Wenn von dort ein "an" kommt, soll das DOIF den Status von man_Bewaesserung jeweils umkehren (eben toggle).
Die Frage ist halt,  ob In4_Beregnung zwischenzeitlich auch mal was anderes als "an" triggert und den Status des DOIF damit ändert. Andernfalls fehlt ein

Code Auswählen Erweitern

attr n_In4_Beregnung do always
damit das DOIF so funktionieren kann.
Ist aber auch eher ins Blaue hinein geraten...

Zitat von: Brockmann am 14 Juli 2014, 19:10:35
Hallo werte DOIF-Gemeinde,

heute habe ich folgendes DOIF definiert:

Code Auswählen Erweitern

DOIF ([{sunset()}])(Schalter01 on) DOELSEIF ([23:59])(Schalter01 off)

Ist soweit selbsterklärend, denke ich. Das Licht soll bei Sonnenuntergang an gehen und um 23:59 ausgeschaltet werden.
Wurde auch akzeptiert und in den Readings stehen zwei plausible Timer.

Allerdings wird mir seitdem das Logfile mit folgender Fehlermeldung zugepflastert:

Code Auswählen Erweitern

Use of uninitialized value in pattern match (m//) at ./FHEM/98_DOIF.pm line 417.
Alle paar Minuten kommt wieder eine neue gleichlautende Zeile dazu...

Ich bin etwa ratlos, weil ich keine DOIFs habe, die alle paar Minuten getriggert werden könnten. Die hängen alle an bestimmten Uhrzeiten oder an bestimmten Status-Dummys, die sich aber auch nicht minütlich ändern...

Zitat von: Damian am 14 Juli 2014, 20:56:13
Ich nehme an, dass du die Version 1.4 benutzt. Offenbar gibt es bei dir Trigger, die keinen Device-Namen liefern.

Ich bastle z. Zt. noch an der Version 1.5. Bis dahin kannst du im Modul in der Zeile 417 folgende Zeile einfügen:

return "" if (!$dev->{NAME});

danach kommt dann:

return "" if ($hash->{devices}{all} !~ / $dev->{NAME} /);

das sollte helfen.

Gruß

Damian

Zitat von: Damian am 14 Juli 2014, 21:19:41
Ich sehe gerade, das Problem ist wahrscheinlich eher die Tatsache, dass $hash->{devices}{all} nicht existiert, weil du nur Timer hast und keine Device-Angaben. Ich habe offenbar immer in Kombination mit Devices getestet  :)
also dann ab Zeile 417 die roten Zeilen einfügen:

Zitat von: Brockmann am 15 Juli 2014, 08:37:27
Das sieht gut aus. Nach dem Einfügen der Zeilen und "reload..." bleiben die Fehlermeldungen jetzt aus. Danke für den schnellen Fix.

Zitat von: satprofi am 15 Juli 2014, 18:40:50
hallo.
kann es sein, dass wenn man zwischendurch eine änderung an den werten vornimmt, das ding dann nicht mehr richtig schaltet, bis man neu startet?

Zitat von: cruser1800 am 15 Juli 2014, 20:35:50
Hallo,

ich habe eine Frage zum next_wait_timer!

Kann es sein, dass die Zeit vor der ersten Ausführung und nicht nach der ersten Ausführung läuft!

Bedingung für war:

Code Auswählen Erweitern

([001_Wetterstation:temperature]>25 and [001_Wetterstation:brightness]>70 and [Thermostat_Wohnzimmer:measured-temp]>22) (set Jalousie_WZ 40,set Jalousie_EZ 40,set Jalousie_KU 40,set Jalousie_dummy 40,set Verschattung_WZ_dummy on) DOELSEIF ([001_Wetterstation:brightness]<70 and [Verschattung_WZ_dummy] eq "on") (set Jalousie_WZ hoch,set Jalousie_EZ hoch,set Jalousie_KU hoch,set Jalousie_dummy hoch,set Verschattung_WZ_dummy off)

Event ist eingetreten: 2014-07-15_20:08:18 001_Wetterstation brightness: 69

aber: 2014-07-15_20:08:19 Verschattung_WZ next_wait_timer: 15.07.2014 20:23:19 cmd_2 001_Wetterstation

Nach der Wartezeit ist dann cmd_2 auch ordnungsgemäß eingetreten.

Gruß Lutz

Zitat von: cruser1800 am 15 Juli 2014, 21:23:45
Hallo Damain,

das Ereignis war da. Heißt das, dass meine Fritzbox zu lange für die Bearbeitung des cmd_2 benötigt, so dass schon  vor Bearbeitung der wait_timer gesetzt wird?

Dann sollte ich mir wohl eine andere Lösung als Server suchen!

Danke
Lutz

Zitat von: Damian am 15 Juli 2014, 21:28:29
Verstehe ich nicht. Der Timer wurde doch maximal eine Sekunde nach dem Event gesetzt (20:08:19) und nicht davor???

Gruß

Damian

Zitat von: cruser1800 am 15 Juli 2014, 21:33:41
Die Helligkeit hat den Wert unterschritten, so dass cmd_1 nicht eintritt und cmd_2 hätte ausgeführt werden müssen.

Leider wurde aber cmd_2 nicht ausgeführt sondern der wait_timer aktiviert. Somit wurde die erste Ausführung von cmd_2 erst nach der Wartezeit von 15 min aktiviert.

Da ich Jalousien damit steuere ist es 15 min länger dunkel.

Gruß

Lutz

Zitat von: Damian am 15 Juli 2014, 21:37:57
Wie sieht denn die Definition des Wait-Attributes aus, sonst kann ich nur raten.

Gruß

Damian

Zitat von: cruser1800 am 15 Juli 2014, 21:41:58
wait           900:900

Zitat von: Damian am 15 Juli 2014, 21:49:06
Es funktioniert wie programmiert. Mit wait 900:900 hast du definiert, dass er 15 Minuten warten solle bevor er das Kommando ausführt und genau das tut er auch.

Warum sollte er denn das Kommando cmd_2 um 20:23:18 ausführen, wenn du ihm sagst, dass er 15 Minuten nach dem Erfüllen der Bedingung (hier für cmd_2) warten soll.

Da hast du offenbar etwas missverstanden.

Gruß

Damian

Zitat von: cruser1800 am 15 Juli 2014, 21:52:15
Danke, wieder etwas dazu gelernt! Ich bin davon ausgegangen, dass er erst ausführt und dann bei erneuten  Ergebnis erst eine definierte Pause abwartet.

Ist hier genau andersrum!

Danke

Lutz

Zitat von: Damian am 15 Juli 2014, 21:05:19
Nein.

An welchen Werten? Es wird immer nur einmal geschaltet, bis sich der Zustand ändert, wenn du do always nicht angibst.

Wenn man Änderungen an der Definition (DEF) vornimmt, werden alle Werte zurückgesetzt, dann sollte das nächste zutreffende Event das entsprechenden Kommando auslösen.

Für irgendwelche Analysen, musst du mir einen nachvollziehbaren Fall liefern.

Gruß

Damian

Zitat von: satprofi am 16 Juli 2014, 18:18:01
ich habe nur den temperaturwert geändert. danach kam nichts mehr, obwohl ja die temperatur zu hoch war.

liegts jetzt an "do always" ? das hab ich aktiviert.

Zitat von: Damian am 16 Juli 2014, 22:16:32
Ich bin in der Testphase einer neuen Version, die nun auch mit Zeitintervallen umgehen kann. Ich habe auch gleich eine Wochentagfunktion eingebaut, weil ich die Wochentag-Abfragen umständlich fand. Hier einige Beispiele aus der neuen Doku:

Zitat von: Brockmann am 17 Juli 2014, 06:47:16
Wäre es prinzipiell auch möglich, ein "offenes" Intervall anzugeben. Für den Anwendungsfall, den ich hier schon mal geschildert hatte: Ein Licht soll bei Sonnenuntergang, aber frühestens 17:00 Uhr angeschaltet werden. Wenn der Sonnenuntergang vor 17:00 Uhr liegt, soll eben erst um 17:00 Uhr geschaltet werden.

Theoretisch also:

Code Auswählen Erweitern

DOIF ([{sunset_abs()}] and [17:00-]) (set Licht on) DOELSE (set Licht off)
aber praktisch geht das vermutlich nicht? Das Problem bei diesem Szenario ist, dass das Licht nicht zu einem bestimmten Zeitpunkt wieder ausgeschaltet werden soll, sondern über eine andere Funktion beim "ins Bett gehen" ausgeschaltet wird.

Wobei, wenn ich die richtig verstehe, könnte ich mir beispielsweise hiermit behelfen:

Code Auswählen Erweitern

DOIF ([{sunset_abs()}] and [17:00-sunrise_abs()}]) (set Licht on) DOELSE (set Licht off)
Wobei sunrise_abs erst am nächsten Tag liegt und kleiner als 17:00 Uhr ist. Das reale Intervall wäre also beispielsweise heute 17:00-04:39:59. Würde DOIF damit in diesem Szenario wie gewünscht funktionieren?

Zitat von: Damian am 17 Juli 2014, 07:45:26
Intervalle z. B. [17:00-16:00] oder mit Funktionen werden unterstützt.

Zitat von: Brockmann am 17 Juli 2014, 07:58:00
Nur noch mal zur Sicherheit:
Das heisst, wenn bei einem Intervall die zweite Angabe kleiner als die erste ist, wird der zweite Zeitpunkt auf den nächsten Tag verschoben?
[17:00-04:00] wäre also zwischen 17:00 Uhr abends heute und 4:00 Uhr morgens am nächsten Tag wahr?

Zitat von: Brockmann am 17 Juli 2014, 06:47:16

Code Auswählen Erweitern

DOIF ([{sunset_abs()}] and [17:00-sunrise_abs()}]) (set Licht on) DOELSE (set Licht off)

Zitat von: cwagner am 18 Juli 2014, 08:08:21
Eine Anregung: I.d.R. will man ja in der Steuerung, dass etwas "allways" gedoed wird, was halten Du und die Mitbnenutzer davon, dass das attribut do als Default schon auf allways steht?
Wenn man dann eine Eintagsfliege will, kann es ja auf - huch - once gibt es gar nicht im Dropdown?

Zitat von: cwagner am 18 Juli 2014, 08:08:21
Ein zweites Thema: Wie könnte ich verhindern, dass dieses DOIF ständig immer wieder CMD1 von Eintreten der Dunkelheit bis Ende der Dunkelheit und CMD2 vice versa "feuert".

Zitat von: Damian am 16 Juli 2014, 18:34:12
Poste mal deine Definition, dann kann ich dir sagen, ob die Sache sinnvoll ist. Vielleicht ist es nur ein Verständnisproblem.

Gruß

Damian

Zitat von: cwagner am 18 Juli 2014, 12:00:00
Unter den Attributen fand ich das serienmäßige eventmap, dass ich schon bei THRESHOLD verwandt habe, um in einer Webübersicht "Klartext" zu haben. Das scheint aber bei DOIF (noch nicht?) zu funktionieren.

Zitat von: satprofi am 18 Juli 2014, 12:20:05
Hallo.
Vielleicht findest du den/die fehler.

Code Auswählen Erweitern


([Heizungsmode] eq "off" and [Pac:state] > 1500 and [HZ_Wohnzimmer_Weather] > 22 and [Terassentuer] eq "Closed" and $hms gt "10:00" and $hms lt "18:30") (set Klima_WZ on) DOELSEIF ([Heizungsmode] eq "auto" and [Pac:state] > 1500 and [HZ_Wohnzimmer_Weather] < 24 and [Terassentuer] eq "Closed" and $hms gt "08:00" and $hms lt "18:30") (set Klima_WZ on) DOELSEIF ([Klima_WZ_manuOn] eq "on" and [HZ_Wohnzimmer_Weather] > 23 and [Terassentuer] eq "Closed") (set Klima_WZ on) DOELSEIF ([Heizungsmode] eq "off" and [Pac:state] < 1000 and [Terassentuer] eq "Closed") (set Klima_WZ off) DOELSEIF ([Klima_WZ_manuOn] eq "off") (set Klima_WZ off) DOELSE (set Klima_WZ ff)


do always
   
wait 300:300:0:300:0:300

Gruss.

Zitat von: satprofi am 19 Juli 2014, 17:38:49
aha, danke.
kann man jetzt zeileneinrückung verwenden?
das wäre ja eine hilfe.

gruss

Zitat von: Damian am 19 Juli 2014, 17:23:17
Ohne zu verstehen, was die Abfragen bei dir im Einzelnen bedeuten, habe ich dein Konstrukt etwas zusammengefasst und auf Intervalle umgestellt. do always macht hier keinen Sinn. Sonst wird unnötig bei dir ein set-Befehl wiederholt (wenn etwas auf off gesetzt wurde, dann muss man es beim nächsten Trigger nicht schon wieder auf off setzen)

Code Auswählen Erweitern

((([Heizungsmode] eq "off" and [HZ_Wohnzimmer_Weather] > 22) or ([Heizungsmode] eq "auto" and [HZ_Wohnzimmer_Weather] < 24))
and [Pac:state] > 1500 and [10:00-18:30] and [Terassentuer] eq "Closed")
(set Klima_WZ on)
DOELSEIF  ([Klima_WZ_manuOn] eq "on" and [HZ_Wohnzimmer_Weather] > 23 and [Terassentuer] eq "Closed")
(set Klima_WZ on)
DOELSEIF ([Heizungsmode] eq "off" and [Pac:state] < 1000 and [Terassentuer] eq "Closed")
(set Klima_WZ off)
DOELSEIF ([Klima_WZ_manuOn] eq "off")
  (set Klima_WZ off)
DOELSE
  (set Klima_WZ off)
 
wait 300:0:300:0:300


Gruß

Damian

Zitat von: satprofi am 20 Juli 2014, 11:45:27
leider heute keine einschaltung mehr mit diesem code.
timer läuft seit 10:00 aber keine aktivität.

[edit]
Habe fehler gefunden, vielöleicht ein bug? wenn einer der readings " -???- " hat läuft das ganze nicht an. dies ist aber nach stromausfall oder restart von fhem der fall.
wie kann man das umgehen?

gruss

Zitat von: satprofi am 20 Juli 2014, 19:33:57
hallo.
es liegt nicht an DOIF, sondern an fhem selbst. denn werte die keine zustandsänderung nach reboot des systems haben, werden mit -???- gelistet.

Zitat von: TecCheck am 20 Juli 2014, 22:21:54
Hallo zusammen,
Du solltest auf jeden Fall nach dem einchecken (das kommt, da bin ich sicher) neben einem Eintrag in die CommandRef eine WikiSeite mit allen Beispielen hier aus dem Post in Betracht ziehen. Du hast sicher viel Arbeit in dieses Modul investiert und es wäre zu schade, wenn es aus Unkenntniss kaum genutzt würde.

Zitat
So, jetzt mein (Luxus)Problem:
Ich möchte bei jeder Statusänderung (egal welche Änderung) einer meiner Tür/Fenstersensoren
einen Einschaltbefehl an ein Display senden.
Ist es mit DOIF möglich, dies zu erreichen, ohne jeden Sensor einzeln aufzuzählen wie:

Code Auswählen Erweitern

DOIF ([tf_Sens1] eq "on"  or [tf_Sens2] eq "on"  or   [tf_Sens3] eq "on" or . . . . .) (set display on_for_timer 20)

z.B. in dem man auf eine Statusänderung in einer Gruppe triggert wie zb.:

DOIF ([TF_SensorenGruppe] eq "on"  or  [TF_SensorenGruppe] eq "off") (set display on_for_timer 20)

oder kannst du eine solche funktion einbauen?
Ist das 'gemeinsame triggern' überhaupt in fhem möglich??

Zitat von: TecCheck am 20 Juli 2014, 22:53:22
Das nenne ich mal Support!
Da kann sich manche Hotline ein paar Scheiben von abschneiden.

Zitat von: Hoeness am 12 Juli 2014, 22:27:16
Hi,

ich bins mal wieder ;-)

Ich möchte mit DOIF ein dummy toggeln (aus/an):

Der Trigger hierzu kommt von einem Taster über GPIO: hier die Config:

Code Auswählen Erweitern

######## Input 4 -Beregnung
define In4_Beregnung RPI_GPIO 10
attr In4_Beregnung active_low no
attr In4_Beregnung debounce_in_ms 50
attr In4_Beregnung devStateIcon aus:rain-icon_off an:rain-icon_on
attr In4_Beregnung direction input
attr In4_Beregnung eventMap on:an off:aus
attr In4_Beregnung group 1_Input
attr In4_Beregnung interrupt rising
attr In4_Beregnung pud_resistor down
attr In4_Beregnung room Bewässerung_DOIF
attr In4_Beregnung webCmd an:aus

Der dummy ist wie folgt konfiguriert:

Code Auswählen Erweitern

######## Beleuchtung Terasse
define man_Bewaesserung dummy
attr man_Bewaesserung group 2_Output
attr man_Bewaesserung room Bewässerung_DOIF
attr man_Bewaesserung webCmd an:aus
attr man_Bewaesserung devStateIcon aus:Lampe_off an:Lampe_on
attr man_Bewaesserung eventMap on:aus off:an

Mein DOIF sieht wie folgt aus:

Code Auswählen Erweitern

define n_In4_Beregnung DOIF ([In4_Beregnung] eq "an" and [man_Bewaesserung] eq "aus") (set man_Bewaesserung an) DOELSEIF ([In4_Beregnung] eq "an" and [man_Bewaesserung] eq "an") (set man_Bewaesserung aus)

Irgendwie stehe ich hier auf dem Schlauch.

Zitat von: Hoeness am 21 Juli 2014, 00:11:36
Hi,

Sorry für meinen späten Kommentar zu euren Antworten.

Ersteinmal möchte ich danke für eure Bemühungen sagen.

Da mein letzter Post ein paar Seiten her ist hier nochmal mein Problem:

Hat sich noch nicht viel geändert. Ich habe heute wieder ein paar Stunden experimentiert. Bin aber nicht weitergekommen.
Im Event Monitor kann ich sehen, dass das dummy man_Bewaesserung aus und danach sofort wieder eingeschaltet wird. Warum ist mir schleierhaft.

Code Auswählen Erweitern

2014-07-20 23:38:21 DOIF n_In4_Beregnung cmd_1
2014-07-20 23:38:21 DOIF n_In4_Beregnung last_cmd: 1
2014-07-20 23:38:21 DOIF n_In4_Beregnung last_cmd_event: man_Bewaesserung
2014-07-20 23:38:21 DOIF n_In4_Beregnung last_error: no error
2014-07-20 23:38:21 dummy man_Bewaesserung aus
2014-07-20 23:38:21 dummy man_Bewaesserung an
2014-07-20 23:38:21 DOIF n_In4_Beregnung cmd_2
2014-07-20 23:38:21 DOIF n_In4_Beregnung last_cmd: 2
2014-07-20 23:38:21 DOIF n_In4_Beregnung last_cmd_event: In4_Beregnung
2014-07-20 23:38:21 DOIF n_In4_Beregnung last_error: no error
2014-07-20 23:38:21 RPI_GPIO In4_Beregnung Pinlevel: high
2014-07-20 23:38:21 RPI_GPIO In4_Beregnung an
2014-07-20 23:38:22 RPI_GPIO In4_Beregnung Pinlevel: low
2014-07-20 23:38:22 RPI_GPIO In4_Beregnung aus
2014-07-20 23:38:22 RPI_GPIO In4_Beregnung Langpress: off

Vielleicht kann mir jemand helfen.

Zitat von: Damian am 21 Juli 2014, 08:16:37
Ich kann das hier z. Zt. aus dem Urlaub nicht nachstellen. Vielleicht hat es doch etwas damit zu tun, dass durch das Setzen des Dummys das Event durch fhem nicht unterbunden wird und erneut ein Event bei n_In4 auslöst.

Du kannst mal probieren

Code Auswählen Erweitern

attr n_In4 wait 1:1

zu setzen. Damit wird ein Verzögerungstimer von 1 Sekunde gesetzt, damit könnte das Problem umgangen werden.

Gruß

Damian

Zitat von: Damian am 21 Juli 2014, 08:53:32
Und ich dachte IF bräuchte man gar nicht mehr  :)

Zitat von: Hoeness am 21 Juli 2014, 10:57:33

Code Auswählen Erweitern

define CMD_dtoggle cmdalias dtoggle .* AS IF (Value("$EVTPART0") eq "an")(set $EVTPART0 aus) ELSE (set $EVTPART0 an)
füge ich irgendwo (weit oben) in meine fhem.cfg ein.

Zitat von: Simon74 am 23 Juli 2014, 23:39:19

Code Auswählen Erweitern

define Cafe_Abends_Aus DOIF ([20:59-21:00] and [t5.ku.sd1_Pwr:power] < 2) (set t5.ku.sd1_Sw off)
Ich hätte nun aber gerne im Logfile stehen das <DOIF "Cafe_Abends_Aus"> ausgelöst wurde, wie am einfachsten ?

Zitat von: RoBra81 am 24 Juli 2014, 13:11:44
Hallo,

ich bin gerade dabei meine Lüftersteuerung zu bauen. Ich möchte die maximale Lüfterstufe (0 bis 10) auf Basis verschiedener Kriterien begrenzen. Dabei habe ich an DOIF gedacht. Nun zu meiner Frage: eines der Kriterien soll die Zeit sein (Lüfter im Schlafzimmer nachts nicht auf höchster Stufe). Das wäre mit DOIF und [xx:00] ja kein Problem. Nun würde ich aber gern die Zeit dynamisch halten (Dropdownliste an meinem Lüftungsdummy). Gibt es nun eine Möglichkeit, wenn ein Nutzer eine Zeit auswählt (set LueftungsDummy Ruhe_Ab 10 => wird in einem Reading des Dummys gespeichert) daraus ein DOIF-Event [10:00] zu machen?

Vielen Dank
Ronny

Zitat von: gsbox am 24 Juli 2014, 15:42:50

Code Auswählen Erweitern

define azLichtAus DOIF ([az_licht] eq "on")({Log 1,"az_licht wurde automatisch abgeschaltet";};;set az_licht off)

Zitat von: Damian am 24 Juli 2014, 15:15:38
Zeiten kann man auch als Funktionen mit [{funktion(...)}] angeben. Dazu musst du dir eine eigene Funkion programmieren, die dann die entsprechende Zeit als Returnwert im Format HH:MM oder HH:MM:SS liefert, siehe z. B. sunset(...).

Zitat von: gsbox am 24 Juli 2014, 16:38:56
Jetzt definiere ich ja einige DOIF-Defines. Ist es möglich, diese zu gruppieren, so dass ich diese "Anwesenheits-Simulation" mit einem Atttribut aktivieren/deaktivieren kann ?

Zitat von: satprofi am 24 Juli 2014, 18:55:50
Seit installation der neueren version klappt folgendes nicht mehr richtig

Zitat von: satprofi am 24 Juli 2014, 19:12:12
Ja, hab ich. auch gelöscht und neu definiert.
doif schaltet nur mehr wenn die zeit erreicht wird. brauch ich jetzt "do always" ?

Zitat von: satprofi am 24 Juli 2014, 21:54:19
Cmd-5

Zitat von: Hoeness am 24 Juli 2014, 22:34:54
Hallo,

ich habe eine Frage zu den Wochentagen, die ich bei Zeitangaben definieren kann:

1-6 entspricht Montag-Samstag?
7 entspricht WE
8 entspricht nicht WE

Wie kann ich den Sonntag definieren?

Ich hätte auch noch eine Idee.
Kann DOIF eventuell noch so erweitern, dass ich angeben kann, dass alle 2,3,4,5,... Tage etwas ausgelöst werden soll?

Gruß Hoeness

ZitatKann DOIF eventuell noch so erweitern, dass ich angeben kann, dass alle 2,3,4,5,... Tage etwas ausgelöst werden soll?

Zitat von: Damian am 24 Juli 2014, 23:30:02
Dann funktioniert alles wie programmiert.
Wenn cmd-5 (off) zuletzt ausgeführt wurde, dann wird es nicht noch mal ausgeführt (wozu auch, off ist off)
Gruß

Damian

Zitat von: UweH am 25 Juli 2014, 18:38:30
Hallo,

dieses Beispiel:

Code Auswählen Erweitern

define DI_Radio DOIF ([08:00-10:00]|7) (set Radio on) DOELSE (set Radio off) funktioniert bei mir nicht, auch am Wochentag wird eingeschaltet und dann aber auch nicht mehr ausgeschaltet. Ohne angehängte 7 oder 8 funktioniert's...Genau so ist es mit anderen Wochentagen...sobald ich eine Tageszahl hinter eine Zeit setze, schaltet DOIF zwar ein, aber nicht mehr aus. Was mache ich falsch?

Zitat von: satprofi am 25 Juli 2014, 10:23:54
nein, wenn terassentuer offen, dann keine reaktion. cmd_5 war ja nach 18:30 der fall, das klappt ja.
ich dachte du fragtest nach dem letzten state.

[edit]
ohne "do always" klappt die abschaltung nicht. da wird nur der timer abgefragt, also die angegebene zeit.
alles andere schaltet nicht ab. werde das ganze morgen aufs neue testen.

Zitat von: UweH am 25 Juli 2014, 18:38:30
Hallo,

dieses Beispiel:

Code Auswählen Erweitern

define DI_Radio DOIF ([08:00-10:00]|7) (set Radio on) DOELSE (set Radio off) funktioniert bei mir nicht, auch am Wochentag wird eingeschaltet und dann aber auch nicht mehr ausgeschaltet. Ohne angehängte 7 oder 8 funktioniert's...Genau so ist es mit anderen Wochentagen...sobald ich eine Tageszahl hinter eine Zeit setze, schaltet DOIF zwar ein, aber nicht mehr aus. Was mache ich falsch?

Zitat von: Brockmann am 30 Juli 2014, 08:26:55
Gerade habe ich folgendes DOIF versucht:

Code Auswählen Erweitern

([STATUS] =~ "Abwesend|Urlaub")
(cmd 1)
DOELSEIF([{OldValue("STATUS")}] ne "Nacht")
(cmd 2)


Das führt zur Fehlermeldung

Code Auswählen Erweitern

DOIF: the at function "OldValue("STATUS")" must return a timespec and not Anwesend.: {OldValue("STATUS")}

Das verstehe ich auch: DOIF akzeptiert in dieser Form nur Funktionen, die eine Zeit zurückliefern, aus der sich ein Timer generieren lässt.

Mein Frage ist, ob diese Einschränkung eigentlich wirklich notwendig ist? Prinzipiell könnte man doch eine beliebige Funktion in dieser Form verwenden.
Liefert die Funktion eine Zeit zurück, wird ein entsprechender Timer generiert. Wenn nicht, wird sei einfach nur als Bedingung ausgewertet, wenn das DOIF anderweitig angestoßen wird.
Das böte auch die Möglichkeit, in DOIFs Bedingungen zu formulieren, die nur zur Laufzeit überprüft werden, ohne selbst Trigger für das DOIF zu sein, was in manche Situationen im Hinblick auf Effizienz durchaus sinnvoll sein kann.

(Es geht mir dabei auch gar nicht um das konkrete Beispiel. Das habe ich nun durch Einfügen entsprechenden Perl-Codes innerhalb von (cmd 2) gelöst, was ich aber als "unschöne" Lösung empfinde.)

Zitat von: Brockmann am 30 Juli 2014, 12:10:53
Hallo Damian,

Danke für die Erläuterung. Da kann DOIF wieder mal schon mehr, als ich dachte.  ;)
Vielleicht wäre es sinnvoll, die Dokumentation um ein solches Beispiel zu erweitern. Bislang ist da nur sunset in eckigen Klammern drin, was ja nochmal etwas anderes ist.
(Ja, ich weiß, in der Featureliste steht was von voller Perl-Unterstützung, aber was das bedeutet und wie man es einsetzen kann, erkennt eben nicht jeder gleich (*Pfeil auf mich*).

Dass bestimmte Arten von Bedingungen keinen Trigger definieren, empfinde ich nicht als Nachteil, sondern sogar als Vorteil, solange man die Wahl hat, welche Variante man verwendet.
Das lässt einem Spielraum, bei der Definition ein wenig auf Effizienz zu achten.

Eine spezielle Unterstützung für OldValue fände ich übertrieben, da es ja doch eher exotisch ist, OldValue als Trigger zu verwenden. Und man könnte es auch jetzt schon definieren:

Code Auswählen Erweitern

([STATUS] and (OldValue("STATUS") ne "Nacht")
Dann wird bei jedem Wechsel von STATUS geprüft, ob der vorherige Zustand "Nacht" war. Dafür braucht es keine eigene Syntax, finde ich.

Zitat von: Damian am 30 Juli 2014, 12:54:58
Man wird beliebigen Status, unabhängig von Abfragen definieren können:

Code Auswählen Erweitern

attr di_Rolladen State Heute beträgt die Temperatur [Wetter:temp] Grad, der Rolladen ist jetzt [di_Rolladen]

Zusätzlich wird man auch Zahlen in der Statusausgabe formatieren können wie beim THRESHOLD über sprintf.

Zitat von: Damian am 30 Juli 2014, 12:54:58
Dann sollen reine Status-Definitionen ohne Ausführungteil möglich sein:

Das kann man zwar jetzt auch schon, aber man muss noch () für die Ausführung angeben:

Zitat von: Brockmann am 30 Juli 2014, 13:44:28
Könnte ich damit den State eines DOIFs individuell anpassen, also z. B. so:

Code Auswählen Erweitern

attr mein_DOIF State [mein_DOIF:last_cmd] durch [mein_DOIF:last_cmd_event] um [mein_DOIF:...
Ups, dabei fällt mir gerade ein, auf den TimeStamp eines Readings kann DOIF nicht zugreifen, oder?
Ich hätte im Status der meisten DOIFs am liebsten den letzten Befehl, das auslösende Objekt und den Zeitpunkt des Befehls stehen, damit man das direkt ablesen kann.

Zitat
Also quasi: Rolladen_runter durch Wettersensor um 2014-07-30 13:20:29

Zitat
Das heißt, man sollte auch jetzt schon "leere" Ausführungsteile angeben können? Das habe ich nämlich heute morgen gerade erfolglos ausprobiert:

Code Auswählen Erweitern

DI_Test DOIF: no commands: ([STATUS] eq "Anwesend") ()

Zitatund hier her vermittelt wurde

Zitat2014.08.02 12:49:38 3: CUL_HM set Waschmaschine off
2014.08.02 12:49:38 2: di_Waschmaschine: set pushmsg msg 'Keller' 'Waschmaschine FERTIG!!!' '' 0 '';set Waschmaschine off: OK

Zitat2014-08-02_12:49:58 Verbrauch_WAMA_Wh power: 0.01

Zitat von: satprofi am 03 August 2014, 16:26:57
Hallo.
Ich habe hier einen denkfehler, bzw. denke ich zu einfach?

Leider funktioniert das and / or nicht. Es schaltet die Kellertuer auch wenn "Alarm_on" off ist.

(([Alarm_on] eq "on") and ([Fenster_Waschkueche] eq "Open") or ([Geraeteschupfen] eq "Open") or ([Kellertuer] eq "Open")) (set Alarm_Sirene on-for-timer 30)

Ziel ist: Alarm_Sirene on-for-timer 30  wenn Alarm_on und eine der bestimmten Türen offen. Oder muss ich für jede tür ein DOELSEIF erstellen?

gruss

Zitat von: satprofi am 03 August 2014, 16:39:48
Aha, danke.
Verstehe ich das richtig, das sämtliche and und or in eigene Klammern sitzen müssen?

z.b.
(([Alarm_on] "on" and [06:00-18:00]) and ([Fenster_Waschkueche] eq "Open") or ([Geraeteschupfen] eq "Open") or ([Kellertuer] eq "Open")) (set Alarm_Sirene on-for-timer 30)

würde Sirene nur aktivieren wenn Alarm_on und Tür offen zw. 6:00 u. 18:00 ?

Zitat von: satprofi am 03 August 2014, 16:50:05
Hallo.
Gerade entdeckt:

Code Auswählen Erweitern


perl error in condition: InternalDoIf('Heizungsmode','STATE','') eq "on" DOIF_time($hash->{realtime}{0},$hash->{realtime}{1},$wday,$hms,""): syntax error at (eval 3517) line 1, near ""on" DOIF_time"

hast Du einen Tip?

gruss

Zitat von: ostseehuepfer am 03 August 2014, 18:15:48
Hey,

also list di_Waschmaschine ergibt No device named di_Waschmaschine found
und list Waschmaschine ergibt Internals:

Code Auswählen Erweitern

Internals:
   DEF        24ABCE01
   NAME       Waschmaschine
   NR         132
   STATE      on
   TYPE       CUL_HM
   chanNo     01
   device     CUL_HM_HM_ES_PMSw1_Pl_24ABCE
   Readings:
     2014-08-02 18:49:40   CommandAccepted yes
     2014-08-03 08:33:59   deviceMsg       on (to HMLAN1)
     2014-08-03 08:33:59   level           100
     2014-08-03 08:33:59   pct             100
     2014-08-03 08:33:59   recentStateType info
     2014-08-03 08:33:59   state           on
     2014-08-03 08:33:59   timedOn         off
   Helper:
     Role:
       chn        1
       prs        1
Attributes:
   icon       scene_washing_machine
   model      HM-ES-PMSw1-Pl
   peerIDs    00000000,
   room       Übersicht,Keller

Grüße

Zitat von: ostseehuepfer am 03 August 2014, 18:21:44
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

Zitat von: ostseehuepfer am 03 August 2014, 18:41:31
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

Zitat von: ostseehuepfer am 03 August 2014, 20:03:26
Hey,

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

Grüße

Zitat von: ostseehuepfer am 03 August 2014, 20:17:10
Danke !!! Nehme mal an damit bekomme ich keine weiteren doppelten Nachrichten?

Grüße

Zitat von: ostseehuepfer am 03 August 2014, 20:19:18
OK wird gleich getestet Danke!!!!!

Läuft :) Vielen Vielen Dank !!!

   
• 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.  ;)

Zitat von: Brockmann am 05 August 2014, 10:55:00
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.

Zitat von: Simon74 am 07 August 2014, 14:49:59
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)

Zitat von: Brockmann am 07 August 2014, 15:25:58
Das kann so nicht gehen. Du fragst damit ja eine Eigenschaft eines Objekts ab, das nicht existiert. Und das gibt einen Fehler.
Die Existenz von Objekten kannst Du mit defined $defs{<Objektname>} abfragen, also ungefähr (ungetestet):

Code Auswählen Erweitern

DOELSEIF(not defined $defs{wz.led.off})(define...)
(Diese Bedingung würde so aber nie getriggert werden, also der Trigger für das DOIF muss aus einer der anderen Bedingungen kommen!)

Zitat von: Brockmann am 07 August 2014, 15:29:39
Ich habe folgendes als DOIF erstellt:

Code Auswählen Erweitern

([FHEM_Kalender:modeStarted] ne "")
    (
    setreading Datastore Cal_start_sum (get FHEM_Kalender summary [FHEM_Kalender:modeStarted]),
    setreading Datastore Cal_start_loc (get FHEM_Kalender location [FHEM_Kalender:modeStarted])
    )

In den Readings habe ich dann stehen:

Code Auswählen Erweitern


Cal_start_loc    (get FHEM_Kalender location 2vdojpgsnaoneamvfiqcgooglecom)    2014-08-07 14:44:03
Cal_start_sum    (get FHEM_Kalender summary 2vdo5og6naoneamvfpqcgooglecom)     2014-08-07 14:44:03


Also der Ausdruck in eckigen Klammern wird ausgewertet, aber der Rest nicht. Gibt es eine Möglichkeit, den Rückgabewert der get-Funktion ins Reading zu schreiben?
Ich habe schon verschiedene Varianten von Kombinationen von Klammern, fhem"..." usw ausprobiert, aber ich bekomme es nicht hin.