neues Modul DOIF

[satprofi]

aber bei uhrzeit ändert sich status ja minütlich? kommt das nicht durch?
pac sendet alle 3min., und wait ist auf 300

[Damian]

aber bei uhrzeit ändert sich status ja minütlich? kommt das nicht durch?
pac sendet alle 3min., und wait ist auf 300

Bei Uhrzeit gibt es nur ein Event, wenn die Zeit in eckigen Klammern angegeben wird (dann gibt es auch einen dazugehörigen Timer in den Readings). $hms ist dagegen nur eine Variable die abgefragt wird. $hms-Angabe löst kein Event aus - es wird also nichts minutlich oder sekundlich abgefragt.

Gruß

Damian

[Hoeness]

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.

[Damian]

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.

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.

Edit: Ich sehe gerade, dass du den dummy selbst schaltest. Das wird nicht gut funktionierten, denn das Schalten des dummys von an auf aus führt in deiner Definition dazu, dass es sofort wieder auf an geht und umgekehrt.

Gruß

Damian

[Brockmann]

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.

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...

[Damian]

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...

ok, jetzt verstehe ich erst, was er vorhat.

do always braucht man eigentlich nur, wenn der gleiche Fall mehrfach hintereinander ausgeführt werden soll, hier sollte es nicht erforderlich sein.

Da wollen wir nur hoffen, dass fhem auch hier einen Loop zuverlässig unterbindet

Gruß

Damian

[Brockmann]

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...

[Damian]

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...

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

[Damian]

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

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:

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

Gruß

Damian

[Brockmann]

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:

Das sieht gut aus. Nach dem Einfügen der Zeilen und "reload..." bleiben die Fehlermeldungen jetzt aus. Danke für den schnellen Fix.

[Damian]

Das sieht gut aus. Nach dem Einfügen der Zeilen und "reload..." bleiben die Fehlermeldungen jetzt aus. Danke für den schnellen Fix.

OK. Ich habe die gefixte Version (1.41) im ersten Post angehängt.

Gruß

Damian

[satprofi]

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?
habe kurz mal einen wert verändert und jetzt wird nicht mehr geschalten. ist mir vorgestern schon aufgefallen, aber am nächsten tag hats dann wieder normal funktioniert.

Code Auswählen Erweitern


last_cmd_event Terassentuer 2014-07-15 18:04:06


seit dieser zeit keine abfrage mehr.

[cruser1800]

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

[Damian]

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?

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

[Damian]

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

Ein Wait_Timer kann nur durch ein Ereignis ausgelöst werden, hier also um 20:08:18 gesetzt um 20:08:19 (aufgrund einer langsamen Verarbeitung bei dir) auf 20.23:19, weil du offenbar 5 Minuten für Wait eingestellt hast.

Wo ist das Problem?

Gruß

Damian