falsches state / STATE in DOIF (state von anderen Devices)

[Invers]

Ich habe seit wahrscheinlich 2 Tagen (vielleicht aber auch schon länger) das Problem, dass mir im state / STATE von mehreren DOIFs irgendwas von anderen Devices angezeigt wird, die mit dem DOIF nichts zu tun haben.
Die Thermometer sind hier nicht von Xiaomi, sondern von HM und dem FHT.
Neustart Pi und fhem ändern nichts daran, aber mit DOIF initialize geht die falsche Anzeige weg
Ich werde also erst einmal die Fehleanzeige mit initialize beseitigen und dann beobachten, ob das Problem noch einmal auftritt.
Es stört mich jetzt nicht wirklich, ich wollte es nur melden, falls es doch jemanden interessieren sollte.
Falls das erneut passiert, werde ich mich noch einmal melden.



Wie gesagt, das betrifft einige DOIFs, hier ist nur mal ein List als Beispiel.

Code Auswählen Erweitern

Internals:
   DEF        (([TMP_HF:temperature] -2) >= [FHT_4955:measured-temp] and [Luefter] eq "off")
    (set Luefter on)
DOELSEIF (([TMP_HF:temperature] -2) < [FHT_4955:measured-temp] and [Luefter] eq "on")
    (set Luefter off)
   FUUID      5c6428dc-f33f-edf9-cc1e-54a6f137215c9b95
   MODEL      FHEM
   NAME       DI_Heizluefter
   NR         63
   NTFY_ORDER 50-DI_Heizluefter
   STATE      2019.04.10 10:38:58 1 : Timeout for XiaomiBTLESens::ExecGatttool_Run reached, terminated process 23663
   TYPE       DOIF
   VERSION    18890 2019-03-13 18:56:41
   READINGS:
     2019-04-11 08:31:57   Device          Luefter
     2019-03-30 07:10:00   cmd             2
     2019-03-30 07:10:00   cmd_event       TMP_HF
     2019-03-30 07:10:00   cmd_nr          2
     2019-04-10 10:53:07   e_FHT_4955_measured-temp 22.7
     2019-04-11 08:31:57   e_Luefter_STATE off
     2019-04-11 08:31:24   e_TMP_HF_temperature 21.1
     2019-04-10 10:38:58   state           2019.04.10 10:38:58 1 : Timeout for XiaomiBTLESens::ExecGatttool_Run reached, terminated process 23663
     2019-03-30 07:10:00   wait_timer      no timer
   Regex:
     accu:
   attr:
     wait:
       0:
         0
       1:
         180
   condition:
     0          (::ReadingValDoIf($hash,'TMP_HF','temperature') -2) >= ::ReadingValDoIf($hash,'FHT_4955','measured-temp') and ::InternalDoIf($hash,'Luefter','STATE') eq "off"
     1          (::ReadingValDoIf($hash,'TMP_HF','temperature') -2) < ::ReadingValDoIf($hash,'FHT_4955','measured-temp') and ::InternalDoIf($hash,'Luefter','STATE') eq "on"
   devices:
     0           TMP_HF FHT_4955 Luefter
     1           TMP_HF FHT_4955 Luefter
     all         TMP_HF FHT_4955 Luefter
   do:
     0:
       0          set Luefter on
     1:
       0          set Luefter off
     2:
   helper:
     event      FBPROP: microphone,powerMeter,tempSensor,switch,AIN: 08761 0087573,energy: 11595 Wh,temperature: 22.5 C (measured),present: yes,power: 0.00 W,fwversion: 04.16,devicelock: no,tempadjust: -1.0 C,voltage: 239.804 V,mode: manuell,off,FBNAME: Luefter,locked: no,ID: 18,FBTYPE: FRITZ!DECT 200
     globalinit 1
     last_timer 0
     sleeptimer -1
     triggerDev Luefter
     triggerEvents:
       FBPROP: microphone,powerMeter,tempSensor,switch
       AIN: 08761 0087573
       energy: 11595 Wh
       temperature: 22.5 C (measured)
       present: yes
       power: 0.00 W
       fwversion: 04.16
       devicelock: no
       tempadjust: -1.0 C
       voltage: 239.804 V
       mode: manuell
       off
       FBNAME: Luefter
       locked: no
       ID: 18
       FBTYPE: FRITZ!DECT 200
     triggerEventsState:
       FBPROP: microphone,powerMeter,tempSensor,switch
       AIN: 08761 0087573
       energy: 11595 Wh
       temperature: 22.5 C (measured)
       present: yes
       power: 0.00 W
       fwversion: 04.16
       devicelock: no
       tempadjust: -1.0 C
       voltage: 239.804 V
       mode: manuell
       state: off
       FBNAME: Luefter
       locked: no
       ID: 18
       FBTYPE: FRITZ!DECT 200
   internals:
     0           Luefter:STATE
     1           Luefter:STATE
     all         Luefter:STATE
   itimer:
   perlblock:
   readings:
     0           TMP_HF:temperature FHT_4955:measured-temp
     1           TMP_HF:temperature FHT_4955:measured-temp
     all         TMP_HF:temperature FHT_4955:measured-temp
   trigger:
   uiState:
   uiTable:
Attributes:
   comment    18.3.2015 DOELSEIF von <= aud < geändert
   disable    0
   do         always
   room       Andere->FHT
   wait       0:180

[Damian]

Ich würde mal behaupten, dass der Status von außen gesetzt wurde. Das DOIF selbst hat zuletzt:

2019-03-30 07:10:00   cmd             2

zum obigen Zeitpunkt den Status gesetzt.

Attribute, die den Status des Moduls beeinflussen,  wie state, stateFormat oder cmdState hast du nicht gesetzt.

[Invers]

Na ja, zumindest nicht bewusst. Es werden ja überall andere Stateinhalte gesetzt.
Ich hab nun mal alles mit initialize gelöscht und werde sehen, ob es noch einmal passiert. Vielleicht habe ich ja bei meinen Experimenten tatsächlich etwas verbrochen. Wahrscheinlich hast du Recht.
Danke dir.

[Ellert]

Ich habe falschen Inhalt in einem Fall auch beobachtet, aber nicht weiterverfolgt, weil nach einem Neustart alles o.k. war. Ich habe nicht versucht das Verhalten zu reproduzieren. Ich hatte eine HTTPMOD Abfrage über userReadings und Perl-DOIF aufbereitet und nach mehrfachen Perl-Fehlern gab es den falschen Inhalt. Letztlich habe ich wohl zuviel herumexperimentiert und die Konsistenz der Hashes korrumpiert. Das ist aber nur eine Vermutung.

[Ellert]

Hier gibt es eine ähnliche Beobachtung https://forum.fhem.de/index.php/topic,98963.0.html

[Damian]

In FHEM kann jeder alles. Es gibt keine gekapselten Speicherbereiche. Im Prinzip kann jeder Speicherbereiche zerschießen, die anderen gehören.

[Ellert]

Ja, interessant ist nur die Häufung der Beobachtungen, 3 Fälle in kurzer Zeit, das bedeutet nicht automatisch einen Fehler im Modul.

[Damian]

Ja, interessant ist nur die Häufung der Beobachtungen, 3 Fälle in kurzer Zeit, das bedeutet nicht automatisch einen Fehler im Modul.

ja, vielleicht ein Bug in fhem.pl, wenn es auch bei anderen Modulen häufiger passiert.

Allerdings sieht der Eintrag hier ziemlich sauber aus, als wenn jemand den dorthin geschrieben hätte.

[Damian]

Ich kann das Problem auch bei mir feststellen: siehe https://forum.fhem.de/index.php/topic,99639.msg930296.html#msg930296

[Damian]

Ich habe einen dringenden Tatverdacht: https://forum.fhem.de/index.php/topic,99203.msg926068.html#msg926068

Edit: Problem erkannt.

Die selbstdefinierte Funktion logtrigger wird von außen aufgerufen, das bekommt das DOIF-Modul nicht mit. Hinter set_State verbirgt sich readingsSingleUpdate mit einem vorbelegten hash, der leider aber nicht mehr vom aktuellen DOIF-Modul stammt

Ich werde das Beispiel wieder auf setreading abändern.

Edit: Obige Definition (Link) geändert, Problem gelöst.

[Invers]

Du hast Recht. Nach der Löschung aller nicht benötigten DOIFs (Da war auch mein Versuch mit der Logdatei dabei), ist der Fehler nie mehr aufgetreten.
Aufgrund der zeitlichen Verzögerung zwischen Test und das Bemerken des Fehlers war mir ein Zusammenhang nicht bewusst geworden.
Schon erstaunlich, dass du darauf einfach so kommen konntest. Hochachtung. Danke.