[GELÖST] DOIF übernimmt trotz Trigger Werte aus readingsProxy nicht

[Burny4600]

Mir ist heute aufgefallen das die Werte von readingsProxy von DIOF nicht übernommen werden.
Es steht bei den DOIF Readings immer nur der gleiche Wert obwohl sich der Wert des readingsProxys ändert.

readingsProxy

Code Auswählen Erweitern

Internals:
   CFGFN      /media/hdd/fhem/mycfg/Resol/resol_dl2_rasp02.cfg
   DEF        DL2:CS10
   DEVICE     DL2
   NAME       DL2_CS10
   NOTIFYDEV  global,DL2
   NR         591
   NTFY_ORDER 50-DL2_CS10
   READING    CS10
   STATE      843 W/m²
   TYPE       readingsProxy
   CONTENT:
     DL2        1
   READINGS:
     2018-05-19 09:10:37   state           843
Attributes:
   alias      CS10 Strahlungsenergie
   fp_SolarThermie 61,326,5, ,DL2_CS10
   group      OG2 Heizungsraum - SolarThermie
   icon       sani_solar
   room       SolarThermie
   stateFormat state W/m²

DOIF

Code Auswählen Erweitern

Internals:
   CFGFN      /media/hdd/fhem/myprogram/pool_rasp02.pm
   DEF        ([DL2_CS10:state] >= 3)
(set LUX_SRD {([DL2_CS10:state] * 115)})
DOELSEIF
([DL2_CS10:state] < 3)
(set LUX_SRD 0)
   MODEL      FHEM
   NAME       LUX_SRBR
   NR         3463
   NTFY_ORDER 50-LUX_SRBR
   STATE      BERECHNUNG
   TYPE       DOIF
   READINGS:
     2018-05-19 09:15:39   Device          DL2_CS10
     2018-05-19 09:04:04   cmd             1
     2018-05-19 09:04:04   cmd_event       LUX_SRBR
     2018-05-19 09:04:04   cmd_nr          1
     2018-05-16 08:05:25   e_DL2_CS10_state 84
     2018-05-19 09:04:04   state           cmd_1
   Regex:
   condition:
     0          ReadingValDoIf($hash,'DL2_CS10','state') >= 3
     1          ReadingValDoIf($hash,'DL2_CS10','state') < 3
   devices:
     0           DL2_CS10
     1           DL2_CS10
     all         DL2_CS10
   do:
     0:
       0          set LUX_SRD {([DL2_CS10:state] * 115)}
     1:
       0          set LUX_SRD 0
     2:
   helper:
     DOIF_Readings_events
     DOIF_eventas
     event      867
     globalinit 1
     last_timer 0
     sleeptimer -1
     triggerDev DL2_CS10
     triggerEvents:
       867
     triggerEventsState:
       867
   internals:
   itimer:
   perlblock:
   readings:
     0           DL2_CS10:state
     1           DL2_CS10:state
     all         DL2_CS10:state
   trigger:
   uiState:
   uiTable:
Attributes:
   alias      Sonnenintensität Süd Seite
   eventMap   /cmd_1:BERECHNUNG/cmd_2:0 lx
   group      AB Pool - SolarThermie
   icon       weather_light_meter
   room       AB-Pool
   sortby     03

e_DL2_CS10_state steht immer auf 84 obwohl sich der Wert DL2_CS10:state von 843 hat.
Ebenso verhält es sich bei allen anderen readingsProxy Werte die DOIF nicht mehr übernimmt.

[amenomade]

Komisch. Man sieht beim Reading "Device", dass er getriggert hat, aber... Was sagt die Log?

[Burny4600]

Im LOG steht nichts was mit der Berechnung zu tun hat.

Die Berechnung wird nur mehr mit chekall ausgeführt und dann steht im LOG bei Verbose 5 auch nur das im LOG

Code Auswählen Erweitern

2018.05.20 14:09:36.570 4: dummy set LUX_SRD 67735

Ich werde eine ältere DOIF pm wieder verwenden denn bis ungefähr vor zwei drei Tagen hatten die Berechnungen unter DOIF noch funktioniert.
Jetzt machen viele DOIF Berechnungen nicht das was sie sollten.

EDIT 14:57
Ich habe nun die DOIF Version

Code Auswählen Erweitern

# $Id: 98_DOIF.pm 16651 2018-04-23 06:28:53Z Damian $
wieder eingespielt und es funktionieren die Berechungen wieder.
Da muss im aktuellem DOIF irgendetwas faul sein.

[Ellert]

Wurde das Problem nicht mit dieser Version behoben?

https://forum.fhem.de/index.php/topic,87901.0.html

[Burny4600]

Nein.
Genau mit dieser Version 98_DOIF.pm 16755 2018-05-18 13:47:23Z Damian $ habe ich die Probleme erst bekommen das die Trigger bei Berechnungen nicht mehr funktionieren.

[Damian]

Nein.
Genau mit dieser Version 98_DOIF.pm 16755 2018-05-18 13:47:23Z Damian $ habe ich die Probleme erst bekommen das die Trigger bei Berechnungen nicht mehr funktionieren.

Ich vermute,, dass readingsProxy keine Events beim state produziert. STATE unterscheidet sich offenbar vom Reading state, was schon recht unüblich ist.

Dann wirst du in deinem Fall im DOIF das Attribut checkReadingEvent 0 setzen müssen, um die alte Kompatibilität wieder herzustellen.

[Burny4600]

@Damian
Ich habe das anhand dieses Beispiels getestet.
Die letzte 98_DOIF.pm Version mit dem Attribut checkReadingEvent 0 brachte die Lösung.
So wie ich dich jetzt verstanden hatte, ist der Fehler nicht im DIOF sondern im readingsProxy.

[Damian]

@Damian
Ich habe das anhand dieses Beispiels getestet.
Die letzte 98_DOIF.pm Version mit dem Attribut checkReadingEvent 0 brachte die Lösung.
So wie ich dich jetzt verstanden hatte, ist der Fehler hatte nicht im DIOF sondern im readingsProxy.

Es ist nicht unbedingt ein Fehler, das Setzen des Readings state erzeugt im readingProxy kein Event, also muss das DOIF auf alles reagieren, was von diesem Device kommt. Das entspricht dem vorherigem (Performance ungünstigen) Verhalten von DOIF.