Zum Test habe ich nur ein kleines DOIF Beispiel konfiguriert um das eigenartige Verhalten der ROLLO Steuerung zu finden.
Eine Fernbedienung öffnet bzw. schließt die Rollläden.
### OG1-Schlafzimmer
define R_OG1_SL_FB DOIF ([FB_R_OG1_Nord] eq "AUF" and [{sunrise(1800,"08:00")}-{sunset(-600)}])\
(set R_OG1_SL_P open)\
DOELSEIF\
([FB_R_OG1_Nord] eq "ZU")\
(set R_OG1_SL_P closed)
attr R_OG1_SL_FB alias Steuerung Fernbedienung Rollladen - OG1 Schlafzimmer
attr R_OG1_SL_FB devStateIcon initialize.*:control_minus P0:fts_shutter_10 P100:fts_shutter_100
attr R_OG1_SL_FB do always
attr R_OG1_SL_FB eventMap cmd_1:P0 cmd_2:P100
attr R_OG1_SL_FB group Steuerung
attr R_OG1_SL_FB icon fts_shutter_updown
attr R_OG1_SL_FB room OG1,OG1-Schlafzimmer,Rolllaeden
# -----------------------------------------------------------------------------------------------
### OG1-Bad
define R_OG1_BA_FB DOIF ([FB_R_OG1_Nord] eq "AUF")\
(set R_OG1_BA_P open)\
DOELSEIF\
([FB_R_OG1_Nord] eq "ZU")\
(set R_OG1_BA_P closed)
attr R_OG1_BA_FB alias Steuerung Fernbedienung Rollladen - OG1 Bad
attr R_OG1_BA_FB devStateIcon initialize.*:control_minus P0:fts_shutter_10 P100:fts_shutter_100
attr R_OG1_BA_FB do always
attr R_OG1_BA_FB eventMap cmd_1:P0 cmd_2:P100
attr R_OG1_BA_FB group Steuerung
attr R_OG1_BA_FB icon fts_shutter_updown
attr R_OG1_BA_FB room OG1,OG1-Bad,Rolllaeden
# -----------------------------------------------------------------------------------------------
### OG1-Wohnzimmer
define R_OG1_WZ_FB DOIF ([FB_R_OG1_Nord] eq "AUF")\
(set R_OG1_WZ_P open)\
DOELSEIF\
([FB_R_OG1_Nord] eq "ZU")\
(set R_OG1_WZ_P closed)
attr R_OG1_WZ_FB alias Steuerung Fernbedienung Rollladen - OG1 Wohnzimmer
attr R_OG1_WZ_FB devStateIcon initialize.*:control_minus P0:fts_shutter_10 P100:fts_shutter_100
attr R_OG1_WZ_FB do always
attr R_OG1_WZ_FB eventMap cmd_1:P0 cmd_2:P100
attr R_OG1_WZ_FB group Steuerung
attr R_OG1_WZ_FB icon fts_shutter_updown
attr R_OG1_WZ_FB room OG1,OG1-Wohnzimmer,Rolllaeden
attr R_OG1_WZ_FB verbose 5
Config ROLLOMODUL
define R_OG1_WZ_P ROLLO
attr R_OG1_WZ_P alias OG1 Wohnzimmer - Rollladen
attr R_OG1_WZ_P autoStop 0
attr R_OG1_WZ_P automatic-enabled on
attr R_OG1_WZ_P blockMode none
attr R_OG1_WZ_P cmdIcon half:remotecontrol/black_btn_MENUDroid open:remotecontrol/black_btn_CHUP closed:remotecontrol/black_btn_CHDOWN stop:remotecontrol/black_btn_STOP
attr R_OG1_WZ_P commandDown set R_OG1_WZ off
attr R_OG1_WZ_P commandStopDown set R_OG1_WZ off
attr R_OG1_WZ_P commandStopUp set R_OG1_WZ on
attr R_OG1_WZ_P commandUp set R_OG1_WZ on
attr R_OG1_WZ_P devStateIcon open:fts_shutter_10:closed closed:fts_shutter_100:open half:fts_shutter_50:closed drive-up:fts_shutter_up@red:stop drive-down:fts_shutter_down@red:stop position-100:fts_shutter_100:open position-90:fts_shutter_80:closed position-80:fts_shutter_80:closed position-70:fts_shutter_70:closed position-60:fts_shutter_60:closed position-50:fts_shutter_50:closed position-40:fts_shutter_40:open position-30:fts_shutter_30:open position-20:fts_shutter_20:open position-10:fts_shutter_10:open position-0:fts_shutter_10:closed
attr R_OG1_WZ_P excessBottom 0
attr R_OG1_WZ_P excessTop 0
attr R_OG1_WZ_P group Steuerung
attr R_OG1_WZ_P icon fts_shutter_updown
attr R_OG1_WZ_P reactionTime 1
attr R_OG1_WZ_P resetTime 1
attr R_OG1_WZ_P room OG1,OG1-Wohnzimmer,Rolllaeden
attr R_OG1_WZ_P secondsDown 20
attr R_OG1_WZ_P secondsUp 21
attr R_OG1_WZ_P switchTime 1
attr R_OG1_WZ_P type normal
attr R_OG1_WZ_P verbose 5
attr R_OG1_WZ_P webCmd position:half:open:closed:stop
Wie man aus dem LOG sieht wird der Rollladen mehrmals angesteuert, was aber nicht sein dürfte.
Es wird immer ein kurzer Zwischenstop ausgeführt wenn die Steuerrung über ein DOIF erfolgt.
2016.12.08 12:15:35.730 3: FS20 set FB_R_OG1_Nord on
2016.12.08 12:15:35.731 5: nanoCUL868_OG1 sending F1b1b0811
2016.12.08 12:15:35.732 5: SW: F1b1b0811
2016.12.08 12:15:35.952 2: nanoCUL433_OG1 IT_set: R_OG1_BA on
2016.12.08 12:15:36.953 2: nanoCUL433_OG1 IT_set: R_OG1_SL on
2016.12.08 12:15:37.452 5: ROLLO (R_OG1_WZ_P) >> Set (open,)
2016.12.08 12:15:37.705 5: ROLLO (R_OG1_WZ_P) >> Start
2016.12.08 12:15:37.706 4: ROLLO (R_OG1_WZ_P) drive from 100 to 0. command: open. state: closed
2016.12.08 12:15:37.707 4: ROLLO (R_OG1_WZ_P) position: 100 -> 0 / direction: up
2016.12.08 12:15:37.709 5: ROLLO (R_OG1_WZ_P) >> calculateDriveTime | going up: from 100 to 0
2016.12.08 12:15:37.710 4: ROLLO (R_OG1_WZ_P) calculateDriveTime: oldpos=100,newpos=0,direction=up,time=21,steps=100,drivetime=23
2016.12.08 12:15:37.963 4: ROLLO (R_OG1_WZ_P) execute following commands: set R_OG1_WZ on; ;
2016.12.08 12:15:38.213 3: FS20 set R_OG1_WZ on
2016.12.08 12:15:38.214 5: nanoCUL868_OG1 sending F1b1b1511
2016.12.08 12:15:38.266 4: ROLLO (R_OG1_WZ_P) stop in 23 seconds.
2016.12.08 12:15:38.424 5: SW: F1b1b1511
2016.12.08 12:15:38.446 4: FS20 FB_R_OG1_Nord on
2016.12.08 12:15:38.762 2: nanoCUL433_OG1 IT_set: R_OG1_BA on
2016.12.08 12:15:40.096 2: nanoCUL433_OG1 IT_set: R_OG1_SL on
2016.12.08 12:15:40.595 5: ROLLO (R_OG1_WZ_P) >> Set (open,)
2016.12.08 12:15:40.597 5: ROLLO (R_OG1_WZ_P) >> calculatePosition
2016.12.08 12:15:40.598 4: ROLLO (R_OG1_WZ_P) calculated Position is 90.4761904761905; rest drivetime is 19
2016.12.08 12:15:41.342 5: ROLLO (R_OG1_WZ_P) >> Start
2016.12.08 12:15:41.343 4: ROLLO (R_OG1_WZ_P) drive from 90.4761904761905 to 0. command: open. state: drive-up
2016.12.08 12:15:41.344 4: ROLLO (R_OG1_WZ_P) position: 90.4761904761905 -> 0 / direction: up
2016.12.08 12:15:41.346 5: ROLLO (R_OG1_WZ_P) >> calculateDriveTime | going up: from 90.4761904761905 to 0
2016.12.08 12:15:41.347 4: ROLLO (R_OG1_WZ_P) calculateDriveTime: oldpos=90.4761904761905,newpos=0,direction=up,time=21,steps=90.4761904761905,drivetime=21
2016.12.08 12:15:41.591 4: ROLLO (R_OG1_WZ_P) execute following commands: set R_OG1_WZ on; ;
2016.12.08 12:15:41.836 3: FS20 set R_OG1_WZ on
2016.12.08 12:15:41.837 5: nanoCUL868_OG1 sending F1b1b1511
2016.12.08 12:15:41.882 4: ROLLO (R_OG1_WZ_P) stop in 21 seconds.
2016.12.08 12:15:41.963 3: nanoCUL433 IT: R_OG1_BA AUF->on
2016.12.08 12:15:42.010 3: nanoCUL433 IT: R_OG1_SL AUF->on
2016.12.08 12:15:42.105 3: nanoCUL433 IT: R_OG1_BA AUF->on
2016.12.08 12:15:42.200 3: nanoCUL433 IT: R_OG1_SL AUF->on
2016.12.08 12:15:42.551 5: SW: F1b1b1511
2016.12.08 12:15:42.590 4: FS20 R_OG1_WZ on
2016.12.08 12:15:42.881 4: FS20 R_OG1_WZ on
2016.12.08 12:15:43.126 5: CUL/RAW: /F1B
2016.12.08 12:15:43.129 5: CUL/RAW: F1B/1B001117
2016.12.08 12:15:43.130 4: CUL_Parse: nanoCUL868_OG1 F1B1B001117 -62.5
2016.12.08 12:15:43.132 5: nanoCUL868_OG1: dispatch 810b04xx0101a0011b1b000011
2016.12.08 12:15:44.004 5: CUL/RAW: /F1B1B001117
2016.12.08 12:15:44.006 4: CUL_Parse: nanoCUL868_OG1 F1B1B001117 -62.5
2016.12.08 12:15:44.008 5: nanoCUL868_OG1: dispatch 810b04xx0101a0011b1b000011
2016.12.08 12:15:59.000 2: nanoCUL433_OG1 IT_set: R_OG1_BA on
2016.12.08 12:15:59.485 3: nanoCUL433_EG IT: R_OG1_BA AUF->on
2016.12.08 12:16:00.012 2: nanoCUL433_OG1 IT_set: R_OG1_SL on
2016.12.08 12:16:00.709 3: nanoCUL433_EG IT: R_OG1_SL AUF->on
2016.12.08 12:16:10.111 5: ROLLO (R_OG1_WZ_P) >> Timer
2016.12.08 12:16:10.113 5: ROLLO (R_OG1_WZ_P) >> Stop
2016.12.08 12:16:10.116 4: ROLLO (R_OG1_WZ_P): stops from drive-up at position 0
2016.12.08 12:16:10.119 3: FS20 set R_OG1_WZ on
2016.12.08 12:16:10.120 5: nanoCUL868_OG1 sending F1b1b1511
2016.12.08 12:16:10.122 5: SW: F1b1b1511
2016.12.08 12:16:10.203 4: ROLLO (R_OG1_WZ_P) stopped by excute the command: set R_OG1_WZ on
2016.12.08 12:16:12.147 4: FS20 R_OG1_WZ on
2016.12.08 12:16:12.851 5: CUL/RAW: /F1B1B001117
2016.12.08 12:16:12.853 4: CUL_Parse: nanoCUL868_OG1 F1B1B001117 -62.5
2016.12.08 12:16:12.855 5: nanoCUL868_OG1: dispatch 810b04xx0101a0011b1b000011
Wenn der Rollladen direkt oder über das ROLLO Modul gesteuert wird tritt dieses Fehlerverhalten nicht auf.
Auch mit Hilfe der Attribute cmdpause 10 und repeatsame 1 ändert sich nichts am Verhalten.
Auch hier erfolgt genauso eine mehrfache Ansteuerrung.
Lass doch do always weg.
Ich benötige in dieser Anwendung das bei einem neuerlichen Tastendruck auf on oder off der Befehl ein zweites mal geschickt wird um den Rollladen wieder zu stoppen.
Wenn ich das do always weg lasse funktioniert das nicht mehr.
Nein ist es nicht. Es kommt auf den Anwendungsfall an.
Zitat von: CoolTux am 08 Dezember 2016, 16:31:44
Nein ist es nicht. Es kommt auf den Anwendungsfall an.
Und wie kann ich das mit DOIF lösen?
DOELSE ()
Was soll ich mit dem DOELSE ()
Ich habe je einen WebButton für AUF und für ZU.
Wenn ich ein zweites Mal auf AUF oder auf ZU drücke soll der Rollladen in der vorher definierten Fahrtrichtung stehen bleiben.
([FB_R_OG1_Nord] eq "AUF")
(set R_OG1_WZ_P open)
DOELSEIF
([FB_R_OG1_Nord] eq "ZU")
(set R_OG1_WZ_P closed)
Zitat von: Burny4600 am 08 Dezember 2016, 16:20:17
Ich benötige in dieser Anwendung das bei einem neuerlichen Tastendruck auf on oder off der Befehl ein zweites mal geschickt wird um den Rollladen wieder zu stoppen.
Wenn ich das do always weg lasse funktioniert das nicht mehr.
Dann gibt es noch die Möglichkeit auf Events (http://fhem.de/commandref_DE.html#DOIF_Ereignissteuerung_ueber_Auswertung_von_Events) zu triggern, statt auf Readings. Damit blendest Du die Auslöser aus, die bei Aktualisierung der Gerätereadings entstehen.
Nur was soll die Änderung auf Events verbessern?
Ob ich es so
([FB_R_OG1_Nord:"AUF"])
(set R_OG1_WZ_P open)
DOELSEIF
([FB_R_OG1_Nord:"ZU"])
(set R_OG1_WZ_P closed)
oder so
([FB_R_OG1_Nord] eq "AUF")
(set R_OG1_WZ_P open)
DOELSEIF
([FB_R_OG1_Nord] eq "ZU")
(set R_OG1_WZ_P closed)
ändert an dem Verhalten rein gar nichts.
Ich meinte nicht reguläre Ausdrücke für Readings, sondern komplette Events, wie ["^FB_R_OG1_Nord$:^AUF$"]
Zitat von: Burny4600 am 09 Dezember 2016, 17:01:47
Nur was soll die Änderung auf Events verbessern?
Ob ich es so
([FB_R_OG1_Nord:"AUF"])
(set R_OG1_WZ_P open)
DOELSEIF
([FB_R_OG1_Nord:"ZU"])
(set R_OG1_WZ_P closed)
oder so
([FB_R_OG1_Nord] eq "AUF")
(set R_OG1_WZ_P open)
DOELSEIF
([FB_R_OG1_Nord] eq "ZU")
(set R_OG1_WZ_P closed)
ändert an dem Verhalten rein gar nichts.
Es kann schon ein unterschiedliches Verhalten geben, denn bei [FB_R_OG1_Nord:"AUF"] wird tatsächlich das Vorkommen von "AUF" im Event zum Trigger. Bei [FB_R_OG1_Nord] eq "AUF" führt dagegen
jedes Event des Devices FB_R_OG1_Nord zum Überprüfen der Bedingung.
Grundsätzlich sollte ein solches Verhalten gar nicht passieren laut DOIF commandref.
Das DOIF-Modul arbeitet mit Zuständen. Jeder Ausführungszweig DOIF/DOELSEIF..DOELSEIF/DOELSE stellt einen eigenen Zustand dar (cmd_1, cmd_2, usw.). Das Modul merkt sich den zuletzt ausgeführten Ausführungszweig und wiederholt diesen standardmäßig nicht. Ein Ausführungszweig wird erst dann wieder ausgeführt, wenn zwischenzeitlich ein anderer Ausführungszweig ausgeführt wurde, also ein Zustandswechsel stattgefunden hat. Dieses Verhalten ist sinnvoll, um zu verhindern, dass zyklisch sendende Sensoren (Temperatur, Feuchtigkeit, Helligkeit, usw.) zu ständiger Wiederholung des selben Befehls oder Befehlsabfolge führen.
Die Konfigurationen sollten nur einmal einen Zweig bearbeiten.
Das verhalten der DOIF Anwendungen ist wie das Prellen eines Kontaktes.
Obwohl nur einmal der Befehl abgesetzt wird, startet der Rollladen, stop und startet wie es im gefällt.
Was auffällt, ist wenn ich direkt den Funkaktor anspreche dieses Verhalten nicht ist.
Mache ich das gleiche mit dem ROLLO Modul tritt dieses sonderbare Verhalten auf, aber nur wenn ich DOIF verwende.
Nehme ich einen Dummy der das ROLLO Modul bedient funktioniert es auch.
Hast Du mal im Event-Monitor geguckt, wer die 2. (ungewollte) Aktion auslöst?
Ich hab mich vor kurzem in einer ähnlichen Problematik befunden und so den Fehler eingrenzen können.
Gerade dass mit den Events ist nicht zu unterschätzen, wenn man mehrere Auslösemöglichkeiten hat.
Bei mir war dass Problem (SpiegelBTRadio) nicht vorhanden, solange ich nur einen Dummy zum schalten hatte. Als der dash-Button dazu kam, funktionierte alles irgendwie nicht mehr stabil. Genau hier war dass Problem, dass ich den state des dash ausgelesen habe. Drückte ich auf den dummy, schlug das DOIF für den dash zu und schaltete nochmal.
Zitat von: Burny4600 am 09 Dezember 2016, 18:15:28
Grundsätzlich sollte ein solches Verhalten gar nicht passieren laut DOIF commandref.
Daher https://forum.fhem.de/index.php/topic,62172.msg535797.html#msg535797
Es steht und fällt alles mit der Analyse der Events, die zu Triggerung des definierten DOIFs führen. Ich glaube da müssen wir noch etwas ausführlicher im WIKI darauf eingehen.
Ganz wichtig ist es alle Events im Event-Monitor aufzuzeichnen, die relevant sind, hier ist es ganz einfach: Filter im Event-Monitor auf FB_R_OG1_Nord setzen. Wenn man die hat, dann lässt sich innerhalb weniger Sekunden erklären warum sich das definierte Modul so verhält und nicht anders.
Zitat von: Damian am 09 Dezember 2016, 19:27:47
Es steht und fällt alles mit der Analyse der Events, die zu Triggerung des definierten DOIFs führen. Ich glaube da müssen wir noch etwas ausführlicher im WIKI darauf eingehen.
Ganz wichtig ist es alle Events im Event-Monitor aufzuzeichnen, die relevant sind, hier ist es ganz einfach: Filter im Event-Monitor auf FB_R_OG1_Nord setzen. Wenn man die hat, dann lässt sich innerhalb weniger Sekunden erklären warum sich das definierte Modul so verhält und nicht anders.
Aber auch die Befehlsreferenz zum DOIF sollte einmal sehr deutlich beschreiben, wann bei der Angabe eines Readings eine Bedingung geprüft wird, z.B. so:
[<Device>], eigentlich
[<Device>:&STATE],
[<Device>:state],
[<Device>:<Reading>] und
[<Device>:&<Internal>] wird immer dann geprüft, wenn
<Device> ein Event erzeugt, auch wenn das Event nicht das angegebene Reading/Internal enthält.
Beispiel
Wenn bei einem Heizkörperventil HM-CC-RT-DN in der Bedingung steht
[HM_123456] eq "CMDs_done", wird die Bedingung jedesmal geprüft, wenn
measured-temp aktualisiert wird.
Oder habe ich das irgendwo überlesen?
Zitat von: Ellert am 09 Dezember 2016, 21:08:35
Aber auch die Befehlsreferenz zum DOIF sollte einmal sehr deutlich beschreiben, wann bei der Angabe eines Readings eine Bedingung geprüft wird, z.B. so:
[<Device>], eigentlich [<Device>:&STATE], [<Device>:state], [<Device>:<Reading>] und [<Device>:&<Internal>] wird immer dann geprüft, wenn <Device> ein Event erzeugt, auch wenn das Event nicht das angegebene Reading/Internal enthält.
Beispiel
Wenn bei einem Heizkörperventil HM-CC-RT-DN in der Bedingung steht [HM_123456] eq "CMDs_done", wird die Bedingung jedesmal geprüft, wenn measured-temp aktualisiert wird.
Oder habe ich das irgendwo überlesen?
Aus der Commandref:
Zitatdefine di_garage DOIF ([remotecontrol] eq "on") (set garage on) DOELSEIF ([remotecontrol] eq "off") (set garage off)
Das Modul wird getriggert, sobald das angegebene Device hier "remotecontrol" ein Event erzeugt. Das geschieht, wenn irgendein Reading oder der Status von "remotecontrol" aktualisiert wird. Ausgewertet wird hier der Zustand des Statuses von remotecontrol nicht das Event selbst.
Das sollte ziemlich klar sein. Aber das heißt alles nichts, denn die Commandref zu DOIF ist inzwischen so umfangreich geworden, dass man schon mal vor lauter Bäume den Wald nicht mehr sieht. Das waren noch Zeiten, als das Modul nur einige wenige Features unterstützte - da war die Commandref entsprechend kürzer (siehe englischer Teil) :) Aber man kann bekanntlich nicht alles haben. Ich glaube allerdings nicht, dass jemand noch mal zurück möchte.
Ja, die guten alten Zeiten...
Da das Loggen der Events zur Fehleranalyse wichtig ist, könnten wir das DOIF mit der Möglichkeit ausstatten ein FileLog zu verwalten, dessen Regexp die im DOIF angegebenen Geräte und Events loggt.
Was hälst Du davon?
Logfile verwalten mit set <device> logfile create|update|disable|enable|delete
Zitat von: Ellert am 09 Dezember 2016, 21:45:50
Ja, die guten alten Zeiten...
Da das Loggen der Events zur Fehleranalyse wichtig ist, könnten wir das DOIF mit der Möglichkeit ausstatten ein FileLog zu verwalten, dessen Regexp die im DOIF angegebenen Geräte und Events loggt.
Was hälst Du davon?
Logfile verwalten mit set <device> logfile create|update|disable|enable|delete
Wann hast du das denn programmiert :)
Ein interessanter Ansatz. Muss ich mir genauer anschauen. Allerdings muss man für die Analyse es immer bewusst erst einmal einschalten und evtl. wieder ausschalten. Ein alternativer Ansatz wäre immer die relevanten letzten x Events in einem Array intern abzulegen und für die Analyse mit list sich diese anzeigen zu lassen.
Ich habe die letzten Tage damit experimentiert.
Man könnte das FileLog nach einem Modify automatisch updaten und es ggf. einen Tag nach einem Modify laufen lassen.
Wobei das Anlegen von Geräten und Setzen von Attributen ohne Benutzereingriff in FHEM nicht erwünscht ist, oder?
FileLog belastet die Modullaufzeit nicht, das Mitschreiben der Events schon.
Ich wollte auch nur einen minimalen Eingriff ins DOIF durchführen.
Zitat von: Ellert am 09 Dezember 2016, 22:29:53
Ich habe die letzten Tage damit experimentiert.
Man könnte das FileLog nach einem Modify automatisch updaten und es ggf. einen Tag nach einem Modify laufen lassen.
Wobei das Anlegen von Geräten und Setzen von Attributen ohne Benutzereingriff in FHEM nicht erwünscht ist, oder?
FileLog belastet die Modullaufzeit nicht, das Mitschreiben der Events schon.
Ja, da sehe ich auch ggf. ein Problem, dass das DOIF-Modul außerhalb des eigenen Bereiches Sachen verändert. Es könnte tatsächlich unerwünscht sein oder in irgendwelchen Konstellationen womöglich unkalkulierte Nebeneffekte mit sich bringen.
Die letzten zehn Events im Speicher abzulegen dürfte gesamt betrachtet wesentlich weniger Performance kosten als ein Logfile auf die Platte zu schreiben.
Wenn wir hier gerade über Ideen plaudern:
In jedem DOIF eine Ereignisvergangenheit vorzuhalten, finde ich übertrieben, obwohl ich nicht einschätzen kann, wie sich das auswirkt.
10 Events sind recht wenig, das nützt nur etwas, wenn man vor der Maschine sitzt und dann kann man auch gleich in den Eventmonitor schauen.
Ich denke man müsste unterscheiden, zwischen einer langfristigen Beobachtung und einer kurzfristigen Beobachtung beim Erstellen des DOIF.
Für langfristige Beobachtung wäre ein auf Benutzerwunsch erstelltes Logfile angebracht und für kurzfristige Beobachtung könnte vielleicht der Eventmonitor in einem Fenster in der Detailansicht des DOIF eingeblendet werden, etwa wie "Raw definition"
Wenn DOIF zur langfristigen Beobachtung das Logfile nicht erstellen soll, dann könnte man zumindest über einen get-Befehl die Regexp für FileLog anbieten und/oder ein define für "Raw definition" und das weitere Handling (update|disable|enable|delete) des FileLog dem Benutzer überlassen. So ein Debug-FileLog wir eher selten notwendig sein, daher müsste eine Servicefunktion nicht so aufwendig gestaltet werden.
Für eine kurzfristige Beobachtung sollte eine kurze Eventhistorie ausreichen, sie sollte nur auf Benutzerwunsch geführt werden.
Viellecht mit set Eventhistorie on for <Minuten> und die Minuten begrenzen.
Zitat von: Ellert am 10 Dezember 2016, 09:31:06
Wenn wir hier gerade über Ideen plaudern:
In jedem DOIF eine Ereignisvergangenheit vorzuhalten, finde ich übertrieben, obwohl ich nicht einschätzen kann, wie sich das auswirkt.
10 Events sind recht wenig, das nützt nur etwas, wenn man vor der Maschine sitzt und dann kann man auch gleich in den Eventmonitor schauen.
Ich denke man müsste unterscheiden, zwischen einer langfristigen Beobachtung und einer kurzfristigen Beobachtung beim Erstellen des DOIF.
Für langfristige Beobachtung wäre ein auf Benutzerwunsch erstelltes Logfile angebracht und für kurzfristige Beobachtung könnte vielleicht der Eventmonitor in einem Fenster in der Detailansicht des DOIF eingeblendet werden, etwa wie "Raw definition"
Wenn DOIF zur langfristigen Beobachtung das Logfile nicht erstellen soll, dann könnte man zumindest über einen get-Befehl die Regexp für FileLog anbieten und/oder ein define für "Raw definition" und das weitere Handling (update|disable|enable|delete) des FileLog dem Benutzer überlassen. So ein Debug-FileLog wir eher selten notwendig sein, daher müsste eine Servicefunktion nicht so aufwendig gestaltet werden.
Für eine kurzfristige Beobachtung sollte eine kurze Eventhistorie ausreichen, sie sollte nur auf Benutzerwunsch geführt werden.
Viellecht mit set Eventhistorie on for <Minuten> und die Minuten begrenzen.
Ja, es ist gut sich Gedanken zu machen wie man da geschickt vorgeht. Ich habe allerdings z. Zt. wenig Zeit zum Programmieren und wir reden hier von Features, von denen andere noch weit entfernt sind.
Die Philosophie ein Modul einfach zu halten und alles andere dem User zu überlassen scheint auch zu funktionieren (notify). Da käme vermutlich keiner auf die Idee, dass notify von sich aus Logs erzeugt.
Ich habe inzwischen das Gefühl, dass das DOIF-Modul, ursprünglich insb. für Anfänger entwickelt, aufgrund der gewachsenen Funktionalität diese immer mehr überfordert.
ZitatIch habe inzwischen das Gefühl, dass das DOIF-Modul, ursprünglich insb. für Anfänger entwickelt, aufgrund der gewachsenen Funktionalität diese immer mehr überfordert.
Das geht mir auch so, vielleicht ist die Zeit für eine Einsteiger-Anleitung reif.
Zitat von: Ellert am 10 Dezember 2016, 10:55:29
Das geht mir auch so, vielleicht ist die Zeit für eine Einsteiger-Anleitung reif.
Das mit Sicherheit (wenn ich mal im Rentenalter bin), denn in der FHEM-Einsteiger-Doku wird z. Zt. DOIF an keiner Stelle erwähnt ;)
Zitat von: Damian am 09 Dezember 2016, 19:27:47
Es steht und fällt alles mit der Analyse der Events, die zu Triggerung des definierten DOIFs führen. Ich glaube da müssen wir noch etwas ausführlicher im WIKI darauf eingehen.
Ganz wichtig ist es alle Events im Event-Monitor aufzuzeichnen, die relevant sind, hier ist es ganz einfach: Filter im Event-Monitor auf FB_R_OG1_Nord setzen. Wenn man die hat, dann lässt sich innerhalb weniger Sekunden erklären warum sich das definierte Modul so verhält und nicht anders.
Hallo Damian.
Habe mit eventMonitor Filter folgenden Ausdruck bei einmaliger Betätigung von
FB_R_OG1_Nord
2016-12-10 12:48:02.414 DOIF R_OG1_WZ_FB cmd_event: FB_R_OG1_Nord
2016-12-10 12:48:02.434 FS20 FB_R_OG1_Nord AUF
2016-12-10 12:48:03.041 DOIF R_OG1_WZ_FB cmd_event: FB_R_OG1_Nord
2016-12-10 12:48:03.061 FS20 FB_R_OG1_Nord AUFDies ist die zugehörige Config
define R_OG1_WZ_FB DOIF (["^FB_R_OG1_Nord$:^AUF$"])\
(set R_OG1_WZ AUF)\
DOELSEIF\
(["^FB_R_OG1_Nord$:^ZU$"])\
(set R_OG1_WZ ZU)
attr R_OG1_WZ_FB alias Steuerung Fernbedienung Rollladen - OG1 Wohnzimmer
attr R_OG1_WZ_FB devStateIcon initialize.*:control_minus P0:fts_shutter_10 P100:fts_shutter_100
attr R_OG1_WZ_FB do always
attr R_OG1_WZ_FB eventMap cmd_1:P0 cmd_2:P100
attr R_OG1_WZ_FB group Steuerung
attr R_OG1_WZ_FB icon fts_shutter_updown
attr R_OG1_WZ_FB room OG1,OG1-Wohnzimmer,RolllaedenNehme ich das
attr R_OG1_WZ_FB do always heraus wird im eventMonitor das gleiche Verhalten mit kurz hintereinader vollgenden Befehlen ersichtlich, aber nur einmal ausgegeben.
Ich habe testweise das Attribut do always bei den anderen Rollladensteuerungen entfernt, worauf hier überhaupt nichts mehr so richtig funktioniert.
### OG1-Wohnzimmer
define R_OG1_WZ_ST DOIF ([14:00-{sunset(-4500)}] and ([ZLN:"DUNKEL"] or\
([ZLN:"HELL"] and [DL2_T11:state] < 22 and [IR_OG1_FB2:"AUS"] and [IR_OG1_FB3:"AUS"])))\
(set R_OG1_WZ_P:FILTER=position!=0 position 0)\
DOELSEIF\
([Daylight1_D:"HELL"] and [R_OG1_WZ_P:position] == 80 and \
(([UESF2_OG1_WZ:"ZU"] and [UESF1_OG1_WZ:"ZU"]) or\
[RKZRSD:"TROCKEN"] or \
[ZWN:"WINDSTILL"]))\
(set R_OG1_WZ_P:FILTER=position!=0 position 0)\
DOELSEIF\
([Daylight1_D:"HELL"])\
(set R_OG1_WZ_P:FILTER=position!=0 position 0)\
DOELSEIF\
([14:00-{sunset()}] and [ZLN:"HELL"] and\
[DL2_T11:state] < 29 and ([DL2_T11:state] > 22 or\
[IR_OG1_FB2:"EIN"] or\
[IR_OG1_FB3:"EIN"]) and\
[R_OG1_WZ_P:position] != 70 and [R_OG1_WZ_P:position] != 80 and [R_OG1_WZ_P:position] != 100)\
(set R_OG1_WZ_P:FILTER=position!=50 position 50)\
DOELSEIF\
([14:00-{sunset()}] and [ZLN:"HELL"] and\
[DL2_T11:state] > 29 and\
[R_OG1_WZ_P:position] != 80 and [R_OG1_WZ_P:position] != 100)\
(set R_OG1_WZ_P:FILTER=position!=70 position 70)\
DOELSEIF\
([Daylight1_D:"HELL"] and [RKZRSD:"REGEN"] and [ZWN:"WIND"] and\
[R_OG1_WZ_P:position] != 100 and\
([UESF2_OG1_WZ:"OFFEN"] or [UESF1_OG1_WZ:"OFFEN"]))\
(set R_OG1_WZ_P:FILTER=position!=80 position 80)\
DOELSEIF\
([Daylight1_D:"DUNKEL"])\
(set R_OG1_WZ_P:FILTER=position!=100 position 100)
attr R_OG1_WZ_ST alias Steuerung Automatic Rollladen - OG1 Wohnzimmer
attr R_OG1_WZ_ST devStateIcon initialize.*:control_minus P0:fts_shutter_10 P50:fts_shutter_50 P70:fts_shutter_70 P80:fts_shutter_80 P100:fts_shutter_100
attr R_OG1_WZ_ST eventMap cmd_1:P0 cmd_2:P0 cmd_3:P0 cmd_4:P50 cmd_5:P70 cmd_6:P80 cmd_7:P100
attr R_OG1_WZ_ST group Steuerung
attr R_OG1_WZ_ST icon fts_shutter_updown
attr R_OG1_WZ_ST room OG1,OG1-Wohnzimmer,Rolllaeden
Schon langsam bin ich am verzweifeln, da die vorgeschlagen Änderung bei den Rollladensteuerungen bisher nur eine Verschlechterung hervorgerufen hat.
Was ist in der
Config R_OG1_WZ_ST jetzt falsch?
Zitat von: Burny4600 am 10 Dezember 2016, 13:06:03
Hallo Damian.
Habe mit eventMonitor Filter folgenden Ausdruck bei einmaliger Betätigung von FB_R_OG1_Nord
2016-12-10 12:48:02.414 DOIF R_OG1_WZ_FB cmd_event: FB_R_OG1_Nord
2016-12-10 12:48:02.434 FS20 FB_R_OG1_Nord AUF
2016-12-10 12:48:03.041 DOIF R_OG1_WZ_FB cmd_event: FB_R_OG1_Nord
2016-12-10 12:48:03.061 FS20 FB_R_OG1_Nord AUF
Wenn zwei mal hintereinander der Trigger "AUF" kommt, dann ist ja logisch, warum bei do always DOIF zweimal schaltet. Da hilft auch keine EVENT-Auswertung, da die Events ja gleich sind. Du solltest jetzt herausfinden, warum zweimal von FS20 "AUF" gesendet wird. Du musst also die Ursache des Problem beseitigen und nicht die Symptome im DOIF.
Diese doppelte Sendung tritt auf wenn ich den Web Button des Dummy FB_R_OG1_Nord betätige.
Ebenso verhält sich das Ganze wenn ich anstatt des Dummys eine FS20 Sender verwende.
Die Betätigung erfolgt definitif nur einmal.
define FB_R_OG1_Nord FS20 1B1B 08
attr FB_R_OG1_Nord IODev nanoCUL868
attr FB_R_OG1_Nord alias Fernbedienung Rollläden - OG1 Nord
attr FB_R_OG1_Nord cmdIcon AUF:remotecontrol/black_btn_CHUP ZU:remotecontrol/black_btn_CHDOWN
attr FB_R_OG1_Nord devStateIcon AUF:fts_shutter_up@green ZU:fts_shutter_down@red
attr FB_R_OG1_Nord eventMap on:AUF off:ZU
attr FB_R_OG1_Nord group Fernbedienungen
attr FB_R_OG1_Nord icon it_remote
attr FB_R_OG1_Nord model fs20s8
attr FB_R_OG1_Nord room OG1,OG1-Bad,OG1-Schlafzimmer,OG1-Wohnzimmer,Rolllaeden,_Fernbedienungen
attr FB_R_OG1_Nord webCmd ::AUF:ZU
Heisst der Dummy genauso wie das FS20 Gerät (Dummy FB_R_OG1_Nord vs. define FB_R_OG1_Nord FS20 1B1B 08 )? Das sollte nicht möglich sein.
Synchronisierst Du den Dummy und FS20 irgendwie?
Was bewirken die beiden :: in webCmd?
Ich habe für die Testzwecke anstatt des FS20 Gerätes FB_R_OG1_Nord dieses mit einem Dummy ersetzt, um zu sehen ob es vom FS20 Gerät kommt oder von einer Programmroutine.
Das FS20 Gerät FB_R_OG1_Nord besitzt zwei Web Buttons für AUF und AB des Rollladens.
Nur es spielt keine Rolle ob ich FB_R_OG1_Nord als Dummy oder als FS20 Gerät ausführe. Das Verhalten ist identisch.
Die beiden :: im webCmd bewirken nur das die Web Buttons alle auf der gleichen Position gereiht werden, da ich Geräte mit vier Buttons in einer Gruppe habe. Das ist nur ein reiner optischer Eingriff.
Nach wie vor suche ich eine Lösung um mit dem FS20 Gerät die Rollläden Gruppe in Bewegung zu setzten und mit der gleichen Taste die Rollläden zu stoppen.
Mit dem DOIF funktioniert es jedenfalls so in der Form nicht.
Wenn die 2 Events immer im Abstand von 600 ms kommen, könntest Du mit dem Attribut cmdpause 700 Erfolg haben.
Das muss ich irgendwo überlesen haben das dies mSec sind und nicht Sekunden.
Ist da ein Fehler im Commandref.
ZitatAnwendungsbeispiel: Meldung über Frostgefahr alle 60 Minuten
define di_frost DOIF ([outdoor:temperature] < 0) (set pushmsg "danger of frost")
attr di_frost cmdpause 3600
attr di_frost do always
Das müsste natürlich cmdpause .7 heissen.
Ok.
Das war dann ein Missverständnis.
Ich werde das morgen in der Form testen.
Zitat von: luetty am 09 Dezember 2016, 18:32:25
Gerade dass mit den Events ist nicht zu unterschätzen, wenn man mehrere Auslösemöglichkeiten hat.
Bei mir war dass Problem (SpiegelBTRadio) nicht vorhanden, solange ich nur einen Dummy zum schalten hatte. Als der dash-Button dazu kam, funktionierte alles irgendwie nicht mehr stabil. Genau hier war dass Problem, dass ich den state des dash ausgelesen habe. Drückte ich auf den dummy, schlug das DOIF für den dash zu und schaltete nochmal.
Und wie hast Du das Problem gelöst?
Bei mir ist das Problem umgekehrt: Schalte ich den Dash, wird der dummy zusättzlich ausgelöst.
Das ist besonders doof, weil es ein toggle ist.
Danke und Gruß,
Kurt