[Solved] DOIF Kommand Logging

[Rampler]

Hallo zusammen,
wenn das folgende DOIF triggert, vermisse ich das Logging:

Code Auswählen Erweitern

## GoodWe SOC auf 90% beschränken
## SOC >= 90% => 0A Ladestrom
([GoodWe:SOC] >= 90) 
 (set GoodWe BMS_Charge_Current_Max 0)
## SOC < 90% => 25A Ladestrom
DOELSE 
 (set GoodWe BMS_Charge_Current_Max 25)
Im EventMonitor erscheint das Event.

Code Auswählen Erweitern

2025-06-09 18:54:58 ModbusAttr GoodWe SOC: 92
2025-06-09 18:54:58 ModbusAttr GoodWe BMS_Charge_Current_Max: 0
Wenn ich manuell folgenden Kommando:

Code Auswählen Erweitern

set GoodWe BMS_Charge_Current_Max 0eingebe wird dieser auch in einem Logfile gelogt, auch mehrmals, da event-on-update für das Reading definiert ist.

Es sind nur diese Attribute definiert:
attr SOC_LIMIT alias SOC Limit
attr SOC_LIMIT cmdState SOC >= 90% => I-Max 0A | SOC <= 90% => I-Max 25A
attr SOC_LIMIT do always
attr SOC_LIMIT verbose 3

Hat jemand einen Tipp für mich ?
Mir ist ein solches Verhalten noch nie aufgefallen ..

VG Klaus

EDIT:

Auszug aus dem Event-Monitor, der letzte Eintrag wird gelogt: (Manuelle Eingabe)
2025-06-09 20:02:58 ModbusAttr GoodWe SOC: 88
2025-06-09 20:02:58 ModbusAttr GoodWe BMS_Charge_Current_Max: 25
2025-06-09 20:03:20 ModbusAttr GoodWe BMS_Charge_Current_Max: 25

[Rampler]

So wird es auch nicht gelogt:

Code Auswählen Erweitern

## GoodWe SOC auf 90% beschränken
## SOC >= 90% => 0A Ladestrom
([GoodWe:SOC] >= 90) 
 ( set GoodWe BMS_Charge_Current_Max 0 )
## SOC < 90% => 25A Ladestrom
DOELSE 
 {fhem("set GoodWe BMS_Charge_Current_Max 25")}
EventMonitor:
2025-06-09 20:18:58 ModbusAttr GoodWe SOC: 86
2025-06-09 20:18:58 ModbusAttr GoodWe BMS_Charge_Current_Max: 25

Ich checks nicht ...

[Damian]

Die Einträge erscheinen im Eventmonitor. Wenn sie nicht geloggt werden, dann musst du das Problem nicht auf der DOIF-Seite, sondern auf der Seite des Loggens suchen.

[Rampler]

Das dachte ich auch erst, aber der manuell eingegebene Kommand wird ja gelogt, nur nicht, wenn dieser vom DOIF kommt.

Hier ist mal die Definitionen des Filelogs:

Code Auswählen Erweitern

Internals:
   DEF        ./log/WR-%Y-%m.log GoodWe|HZ.GoodWe|HZ.wr
   FD         83
   FUUID      6759e9d0-f33f-b6d9-84cf-91aadbb8f32c099a
   NAME       FileLog_WR
   NOTIFYDEV  GoodWe,HZ.GoodWe,HZ.wr
   NR         708
   NTFY_ORDER 50-FileLog_WR
   REGEXP     GoodWe|HZ.GoodWe|HZ.wr
   STATE      active
   TYPE       FileLog
   addLogMinInterval 3600
   currentlogfile ./log/WR-2025-06.log
   logfile    ./log/WR-%Y-%m.log
   READINGS:
     2025-06-10 06:00:56   linesInTheFile  17537
Attributes:
   addLog     HZ.wr:Ventilator:3600,HZ.GoodWe:Goodwe_Relay:3600
   comment    .*(PV_[1-2]_Power|PV_[1-2]_Voltage|stat|CONNECTED|Heizstab[1-3]).*
   icon       time_note
   ignoreRegexp .*(PV_[1-2]_Power|PV_[1-2]_Voltage|stat|CONNECTED).*
   nrarchive  1
   room       Logs,PV

[Damian]

Dann bau die Konstruktion mit zwei Dummys nach - für den Sensor und für das zu schaltende Device jeweils eins. Wenn das dazugehörige DOIF Events erzeugt, die geloggt werden, dann weißt du, dass es mit den Devices zusammenhängt.

[Rampler]

Danke Damian für Deine Unterstützung.

Ich habe jetzt im DOIF einen Wait 1:1 eingebaut, damit funktioniert es ..

Siehe auch:
https://forum.fhem.de/index.php?topic=141858.0

[Damian]

Danke Damian für Deine Unterstützung.

Ich habe jetzt im DOIF einen Wait 1:1 eingebaut, damit funktioniert es ..

Siehe auch:
https://forum.fhem.de/index.php?topic=141858.0

Offenbar wird nicht erkannt, wenn unmittelbar ein Event des gleichen Devices folgt. Entweder ist es ein grundsätzliches FHEM-Problem oder ein Problem des Log-Devices. Das könntest du auch noch mit einem separaten Device (DOIF oder Notify) überprüfen, welches auf 'ModbusAttr GoodWe BMS_Charge_Current_Max: 0' triggert (wait vorher rausnehmen).

Du solltest im Automatisierung-Board den Titel ändern. Wenn da DOIF drinsteht, wird sich Rudi die Sache nicht anschauen.

[Beta-User]

Danke Damian für Deine Unterstützung.

Ich habe jetzt im DOIF einen Wait 1:1 eingebaut, damit funktioniert es ..

Siehe auch:
https://forum.fhem.de/index.php?topic=141858.0

Offenbar wird nicht erkannt, wenn unmittelbar ein Event des gleichen Devices folgt. Entweder ist es ein grundsätzliches FHEM-Problem oder ein Problem des Log-Devices. Das könntest du auch noch mit einem separaten Device (DOIF oder Notify) überprüfen, welches auf 'ModbusAttr GoodWe BMS_Charge_Current_Max: 0' triggert (wait vorher rausnehmen).

Du solltest im Automatisierung-Board den Titel ändern. Wenn da DOIF drinsteht, wird sich Rudi die Sache nicht anschauen.

Es ist m.E. ein "grundsätzliches FHEM"-Thema. Problem paßt nicht, es geht um die Verhinderung von Schleifen.
Eventuell muss NOTIFYDEV neu initialisiert werden nach rename des DOIF.

[Damian]

Ich sehe hier keine Schleife. Eventreihenfolge ist:

GoodWe-> log
              -> Notify->GoodWe->log

[Beta-User]

Ich sehe hier keine Schleife. Eventreihenfolge ist:

GoodWe-> log
              -> Notify->GoodWe->log

Soweit ich mich entsinne: Das DOIF greift innerhalb derselben Event-loop ein und ergänzt lediglich die Liste.
Deswegen wird aber nicht nochmal von vorne begonnen... Wer also schon notifyFn hatte, wird nicht nochmal aufgerufen.

[Damian]

Ich sehe hier keine Schleife. Eventreihenfolge ist:

GoodWe-> log
              -> Notify->GoodWe->log

Soweit ich mich entsinne: Das DOIF greift innerhalb derselben Event-loop ein und ergänzt lediglich die Liste.
Deswegen wird aber nicht nochmal von vorne begonnen... Wer also schon notifyFn hatte, wird nicht nochmal aufgerufen.

Das Problem hat mit DOIF nichts zu tun. Es funktioniert auch mit Notify nicht. 

[Beta-User]

Ich sehe hier keine Schleife. Eventreihenfolge ist:

GoodWe-> log
              -> Notify->GoodWe->log

Soweit ich mich entsinne: Das DOIF greift innerhalb derselben Event-loop ein und ergänzt lediglich die Liste.
Deswegen wird aber nicht nochmal von vorne begonnen... Wer also schon notifyFn hatte, wird nicht nochmal aufgerufen.

Das Problem hat mit DOIF nichts zu tun. Es funktioniert auch mit Notify nicht. 

Imo funktioniert es, wenn die notifyPrefix passt bzw. die Namen der beteiligten Evetnt-Handler.
Wählt man die unpassend, "funktioniert" auch notify nicht. Falls es unklar ist: readingsChange.pm hängt sich bewusst vorne ein, MQTT_GENERIC_BRIDGE hinten. fhem.pl => setNotifyDev() löscht ein Array...