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.
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
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.
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.
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.
Hier gibt es eine ähnliche Beobachtung https://forum.fhem.de/index.php/topic,98963.0.html
In FHEM kann jeder alles. Es gibt keine gekapselten Speicherbereiche. Im Prinzip kann jeder Speicherbereiche zerschießen, die anderen gehören.
Ja, interessant ist nur die Häufung der Beobachtungen, 3 Fälle in kurzer Zeit, das bedeutet nicht automatisch einen Fehler im Modul.
Zitat von: Ellert am 11 April 2019, 18:52:50
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.
Ich kann das Problem auch bei mir feststellen: siehe https://forum.fhem.de/index.php/topic,99639.msg930296.html#msg930296
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.
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.