DOIF sendet mehrmals. Wie lässt sich das abstellen?

[Ellert]

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?

[Damian]

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:

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

[Ellert]

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

Code Auswählen Erweitern

set <device> logfile create|update|disable|enable|delete

[Damian]

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

Code Auswählen Erweitern

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.

[Ellert]

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.

[Damian]

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.

[Ellert]

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.

[Damian]

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.

[Ellert]

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.

Das geht mir auch so, vielleicht ist die Zeit für eine Einsteiger-Anleitung reif.

[Damian]

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

[Burny4600]

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

Code Auswählen Erweitern


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

Dies ist die zugehörige Config

Code Auswählen Erweitern

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,Rolllaeden

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

Code Auswählen Erweitern

### 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?

[Damian]

Hallo Damian.
Habe mit eventMonitor Filter folgenden Ausdruck bei einmaliger Betätigung von FB_R_OG1_Nord

Code Auswählen Erweitern


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.

[Burny4600]

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.

Code Auswählen Erweitern

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

[Ellert]

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?

[Burny4600]

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.