Hauptmenü

neues Modul DOIF

Begonnen von Damian, 21 Mai 2014, 15:53:18

Vorheriges Thema - Nächstes Thema

satprofi

sorry, ja das hatte ich vergessen.
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

Spartacus

Zitat von: Damian am 05 Dezember 2014, 18:13:05
Das bedeutet einfach, dass zu diesem Zeitpunkt kein Zustand von cal.01.Ferien.dum gesetzt war.
Gruß

Damian
Moin Damian,
Verstehe ich nicht! STATE steht auf 0 und ist damit gesetzt, oder?Internals:
   CFGFN      config/Dienste.cfg
   CHANGED
   NAME       cal.01.Ferien.dum
   NR         72
   STATE      0
   TYPE       dummy
   Readings:
     2014-12-05 15:40:42   state           0
Attributes:
   alias      Ferientag
   event-on-change-reading .*
   room       98-Dummy


Wo mache ich den Gedankenfehler ?
Christian
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Damian

Zitat von: Spartacus am 06 Dezember 2014, 09:25:48
Moin Damian,
Verstehe ich nicht! STATE steht auf 0 und ist damit gesetzt, oder?Internals:
   CFGFN      config/Dienste.cfg
   CHANGED
   NAME       cal.01.Ferien.dum
   NR         72
   STATE      0
   TYPE       dummy
   Readings:
     2014-12-05 15:40:42   state           0
Attributes:
   alias      Ferientag
   event-on-change-reading .*
   room       98-Dummy


Wo mache ich den Gedankenfehler ?
Christian

Das liegt wohl an der Null. Ich werde es in der nächsten Version korrigieren, solange kannst du etwas anderes stattdessen nehmen z. B. off.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Spartacus

Ah! ok!
Ist ja kein Problem! Wollte es nur verstehen....
Besten Dank,
Christian.
Fhem-System: 1 x raspberry PI Typ B, 1 x enOcean PI Typ B | Enocean: PTM210, FMS61NP, FAM14, 2 x FSR14-4x, FTS14-EM | LaCrosse: 2 x TX29D über Jeelink V3 | 1-Wire: 2 x DS18B20 über DS9490R

Damian

Zitat von: Damian am 06 Dezember 2014, 09:43:04
Das liegt wohl an der Null. Ich werde es in der nächsten Version korrigieren, solange kannst du etwas anderes stattdessen nehmen z. B. off.


Problem gefixed und eingecheckt. Korrektur ab morgen per FHEM-Update.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

MarkusN

Moin. Versuche momentan verschiedene at und notify auf doif umzustellen. Mehrmals habe ich beim Versuch ein doif zu definieren FHEM abgeschossen, zuletzt mit diesem Konstrukt:

define doif_zeitschaltuhr_licht_livingcolors DOIF ([{sunset("REAL")}-21:00]) (set licht_livingcolors on,set licht_livingcolors on) DOELSE ( {fhem("set licht_livingcolors off;set licht_livingcolors off") if ((Value("licht_livingcolors") ne "off") && (Value("harmony_wz") eq "PowerOff"))})

Hat sich da irgendwo ein Syntax Fehler eingeschlichen, oder mache ich was anderes falsch?

Grüße,

Markus

Damian

Zitat von: MarkusN am 07 Dezember 2014, 18:24:36
Moin. Versuche momentan verschiedene at und notify auf doif umzustellen. Mehrmals habe ich beim Versuch ein doif zu definieren FHEM abgeschossen, zuletzt mit diesem Konstrukt:

define doif_zeitschaltuhr_licht_livingcolors DOIF ([{sunset("REAL")}-21:00]) (set licht_livingcolors on,set licht_livingcolors on) DOELSE ( {fhem("set licht_livingcolors off;set licht_livingcolors off") if ((Value("licht_livingcolors") ne "off") && (Value("harmony_wz") eq "PowerOff"))})

Hat sich da irgendwo ein Syntax Fehler eingeschlichen, oder mache ich was anderes falsch?

Grüße,

Markus

Das Problem sind oft die Semikolons, die man in FHEM oft verdoppeln oder sogar vervierfachen muss, ja nach Hierarchie-Tiefe.

Genau aus diesem Grunde habe ich IF programmiert, hier bleibt man auf der FHEM-Ebene und kann statt Semikolon Komma angeben (immer nur eins) :)

Unabhängig davon weiß ich nicht, ob du das willst, was du da definiert hast, insb.:  Wenn eine Lampe brennt, soll nach 21:00 Uhr nichts ausgeschaltet werden???

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Brockmann

Zitat von: MarkusN am 07 Dezember 2014, 18:24:36
Moin. Versuche momentan verschiedene at und notify auf doif umzustellen. Mehrmals habe ich beim Versuch ein doif zu definieren FHEM abgeschossen, zuletzt mit diesem Konstrukt:

define doif_zeitschaltuhr_licht_livingcolors DOIF ([{sunset("REAL")}-21:00]) (set licht_livingcolors on,set licht_livingcolors on) DOELSE ( {fhem("set licht_livingcolors off;set licht_livingcolors off") if ((Value("licht_livingcolors") ne "off") && (Value("harmony_wz") eq "PowerOff"))})

Hat sich da irgendwo ein Syntax Fehler eingeschlichen, oder mache ich was anderes falsch?
Warum das FHEM abschiesst, weiß ich auch nicht. Diese Konstruktion mit dem nachgeschalteten if ist etwas ungewöhnlich, aber formal vermutlich korrekt? Habe ich so aber noch nie gemacht. Und im fhem("...") hätte ich es mal mit zwei ;; probiert.

Aber ich würde den DOELSE-Teil so lösen:
DOELSE (IF ([licht_livingcolors] ne "off" and [harmony_wz] eq "PowerOff")(set licht_livingcolors off,set licht_livingcolors off))
Sollte dasselbe bewirken.

Hat das eine Grund, dass Du immer zwei sets auf dasselbe Gerät machst? Oder ist das nur Beispielcode?

MarkusN

Zitat von: Damian am 07 Dezember 2014, 18:48:00
Unabhängig davon weiß ich nicht, ob du das willst, was du da definiert hast, insb.:  Wenn eine Lampe brennt, soll nach 21:00 Uhr nichts ausgeschaltet werden???

Ich sehe da kein Problem, hast du vielleicht das 'ne' als 'eq' gelesen? Habe das IF-Modul noch gar nicht so wahrgenommen, werde mich mal intensiver damit beschäftigen, danke für den Tip!

Zitat von: Brockmann am 07 Dezember 2014, 18:56:42
Aber ich würde den DOELSE-Teil so lösen:
DOELSE (IF ([licht_livingcolors] ne "off" and [harmony_wz] eq "PowerOff")(set licht_livingcolors off,set licht_livingcolors off))
Sollte dasselbe bewirken.

Hat das eine Grund, dass Du immer zwei sets auf dasselbe Gerät machst? Oder ist das nur Beispielcode?

Danke, habe den Vorschlag mal umgesetzt, hat FHEM auch so gefressen. Ich sende zwei Befehle hintereinander weil es sich bei dem Empfänger um Intertechno Dosen handelt, die nach dem ersten Befehl gerne mal nix tun. Seit dem ich alles immer zwei mal sende hat alles geschaltet wie erwartet.

Grüße,

Markus

maxritti

#849
Hi,

irgendwie scheint mir schon ein recht leichter Fall des DOIFs nicht zu glücken.
Und zwar steuere ich derzeit meine 5 Jallousien mit diversen at's, notifies und ein wenig Code in myUtils.pm
Das wollte ich nun mal vereinfachen und dachte mir, da kommt das DOIF doch ganz recht. Da kann ich doch alles gut mit abfrühstücken.
Anfangen wollte ich nun mal mit dem einfachsten Rollo, der an einem Fenster ist, wo kein Türkontakt eine Rolle spielt.

Dieser soll in Abhängigkeit eines Lichtsensors oder spätestens um 22:10 runtergehen, aber nur dann, wenn ein Dummy "duRolloMaster" auf "an" steht.
Ein andere Dummy "duPVRollo" ermöglicht den Rolle in Abhängigkeit des Ertrags meiner PV Anlage auf Zwischenwerte zu stellen.

Nur warum geht der Rollo welchen ich bislang als Dummy definiert habe nicht auf "off"?
Irgendwie landet der im cmd_4, obwohl "duRolloMaster" auf "an" steht und es draussen mal definitiv "dunkel" ist.

Internals:
   CFGFN
   DEF        (([duRolloMaster:state] eq "an") and (([EG_dr_TS_Terrasse:luminosity] < 0.3) or [22:10]))  (set du_EG_wz_RO_TerrasseRechts off) DOELSEIF (([duPVRollo:state] eq "an") and ([mySL:Pac_avg] >= 2100)) (set du_EG_wz_RO_TerrasseRechts 0) DOELSEIF (   ([duPVRollo:state] eq "an") and ([mySL:Pac_avg] >= 1501) ) (set du_EG_wz_RO_TerrasseRechts 30) DOELSE (set du_EG_wz_RO_TerrasseRechts on)
   NAME       di_EG_wz_RO_TerrasseRechts_ru
   NR         5432
   NTFY_ORDER 50-di_du_EG_wz_RO_TerrasseRechts
   STATE      cmd_4
   TYPE       DOIF
   Readings:
     2014-12-07 20:32:27   cmd_event       duRolloMaster
     2014-12-07 20:32:27   cmd_nr          4
     2014-12-07 20:32:16   e_EG_dr_TS_Terrasse_luminosity 0.15
     2014-12-07 20:32:28   e_duRolloMaster_state an
     2014-12-07 20:32:30   e_mySL_Pac_avg  0
     2014-12-07 20:32:27   state           cmd_4
     2014-12-07 20:32:07   timer_1_c1      07.12.2014 22:10:00
     2014-12-07 20:32:30   wait_timer      no timer
   Condition:
     0          (ReadingValDoIf('duRolloMaster','state','') eq "an") and ((ReadingValDoIf('EG_dr_TS_Terrasse','luminosity','') < 0.3) or DOIF_time_once($hash->{timer}{0},$wday,""))
     1          (ReadingValDoIf('duPVRollo','state','') eq "an") and (ReadingValDoIf('mySL','Pac_avg','') >= 2100)
     2             (ReadingValDoIf('duPVRollo','state','') eq "an") and (ReadingValDoIf('mySL','Pac_avg','') >= 1501)
   Days:
   Devices:
     0           duRolloMaster EG_dr_TS_Terrasse
     1           duPVRollo mySL
     2           duPVRollo mySL
     all         duRolloMaster EG_dr_TS_Terrasse duPVRollo mySL
   Do:
     0          set du_EG_wz_RO_TerrasseRechts off
     1          set du_EG_wz_RO_TerrasseRechts 0
     2          set du_EG_wz_RO_TerrasseRechts 30
     3          set du_EG_wz_RO_TerrasseRechts on
   Helper:
     last_timer 1
     sleepdevice duRolloMaster
     sleeptimer -1
   Internals:
   Readings:
     0           duRolloMaster:state EG_dr_TS_Terrasse:luminosity
     1           duPVRollo:state mySL:Pac_avg
     2           duPVRollo:state mySL:Pac_avg
     all         duRolloMaster:state EG_dr_TS_Terrasse:luminosity duPVRollo:state mySL:Pac_avg
   Realtime:
     0          22:10:00
   State:
   Time:
     0          22:10:00
   Timecond:
     0          0
   Timer:
     0          0
   Timerfunc:
   Timers:
     0           0
Attributes:
   room       LichtRollo
   wait       10:10:10

   
Kann doch eigentlich nicht so schwer sein.
Was mache ich denn erst mit einem Rollo, wo noch ein Türkontakt eine Rolle spielt?
Da soll der Rollo dann hoch gehen, wenn die Tür aufgeht und wieder runter, wenn die Tür geschlossen wird und die Bedingungen (dunkel oder nach 22:10) zutreffen.
Aber das kommt danach, wenn der "einfache" Fall gelöst ist.

maxritti

#850
Jetzt verstehe ich gar nichts mehr.
Eben ging das Doif mal auf cmd_1 aber dann wieder auf cmd_4 obwohl ich nichts gemacht habe.
Irgendwie hat der nach den wohl im wait 10:10:10 angegebenen 10 Sekunden gedacht zu schalten.

Nur warum cmd_4?
Der dummy Master ist nach wie vor auf "an"

maxritti

Selbstgespräch nächster Teil:

Ohne den DOELSE Teil, ohne wait und mit do "always" scheint es zu klappen.
Jetzt müsste ich nur noch verstehen warum bzw warum es mit dem DOELSE nicht so klappt wie gedacht.

Damian

Zitat von: maxritti am 07 Dezember 2014, 20:58:18
Selbstgespräch nächster Teil:

Ohne den DOELSE Teil, ohne wait und mit do "always" scheint es zu klappen.
Jetzt müsste ich nur noch verstehen warum bzw warum es mit dem DOELSE nicht so klappt wie gedacht.

do always in Verbindung mit zyklisch sendenden Sensoren, hier vermutlich: EG_dr_TS_Terrasse:luminosity, ist wenig sinnvoll.

Wenn man keinen Trigger bei solchen Sensoren haben will, dann muss man sie mit ReadingsVal(..) in der Bedingung angeben.

Gruß

Damian
Programmierte FHEM-Module: DOIF-FHEM, DOIF-Perl, DOIF-uiTable, THRESHOLD, FHEM-Befehl: IF

Brockmann

Zitat von: maxritti am 07 Dezember 2014, 20:58:18
Selbstgespräch nächster Teil:

Ohne den DOELSE Teil, ohne wait und mit do "always" scheint es zu klappen.
Jetzt müsste ich nur noch verstehen warum bzw warum es mit dem DOELSE nicht so klappt wie gedacht.
Damian war mal wieder schneller, aber nur weil ich es etwas ausführlicher geschrieben habe:  ;)

Du hast in Deinen Konditionen verschiedene Bedingungen drin. Wann immer ein dazu passendes Event auftritt, wird das DOIF getriggert, also beispielsweise wenn [mySL:Pac_avg] irgendeinen Wert meldet. Dann werden die Konditionen getestet, in denen dieser Wert enthalten ist. Ist keine der Konditionen wahr (weil der Wert zu hoch/zu niedrig ist oder eine verknüpfte Bedingung nicht stimmt), fällt DOIF auf den DOELSE-Fall zurück.

Genau aus diesem Grund ist (IMHO) eine der goldenen Regeln bei DOIFs, auf DOELSE möglichst zu verzichten bzw. es nur in Ausnahmefällen einzusetzen, wo man die Auswirkung genau überblicken und Seiteneffekte ausschließen kann. Und Deine Beschreibung passt genau zu solchen unerwarteten Seiteneffekten.

Ansonsten kannst Du Dir bei jeder Bedingung überlegen, ob sie wirklich eine Auswertung des DOIFs triggern soll. In einer zukünftigen Version wird es wohl die Möglichkeit geben, Bedingungen in DOIF-Notation als nicht-triggernd zu kennzeichnen. Bis dahin kann man anstelle der DOIF-Notation ganz klassisch Value oder ReadingsVal verwenden, um denselben Effekt zu erreichen.

satprofi

Hallo Damian.
Habe heute wieder einmal meine DOIF´s geprüft und siehe da einige Fehlermeldungen entdeckt.
bis jetzt hatte folgendes geklappt:


([Ueberschuss] > 1000 and [Absorbtionsphase] eq "Open" and [08:00-17:00]) (set Batterielader_aus off)


heute sah ich die meldung

internal doesnt exist [Ueberschuss:STATE]


habe jetzt meine DEF dahingehend geändert
([Ueberschuss:state] > 1000 and [Absorbtionsphase] eq "Open" and [08:00-17:00]) (set Batterielader_aus off)


und jetzt ist die fehlermeldung weg.
hat das mit gestrigem update was zu tun?

weiters wollte ich fragen wo genau man die Commandref zu DOIF finden kann?
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram