Hi,
ich bin gerade dabei zwei Module für die Integration von smarthomatic-Geräten in FHEM vorzubereiten. Es handelt sich dabei um ein Opensource/Openhardware Projekt von Uwe Freese (siehe http://www.smarthomatic.org). Bevor ich es hier zum Review einstelle hätte ich gerne noch ein merkwürdiges Verhalten von FHEM verstanden und die daraus resultierenden Problem für die Implementierung gelöst:
Angenommen wir haben drei Geräte:
shc_base : Basisstation
├─> shc_deva : Gerät A - ein Umweltsensor der Feuchtigkeitsmesswerte (humidity) liefert
└─> shc_devb : Gerät B - ein Umweltsensor der Temperaturmesswerte (temperature) liefert
Nachdem die ersten Messwerte von den Sensoren eingetroffen sind werden diese in den Readings gespeichert:
shc_deva ─>{READINGS}{humidity}{VAL} = 55.3
shc_devb ─>{READINGS}{temperature}{VAL} = 23.4
Aber nacheiniger Zeit enthalten die Readings von Gerät A auch ein temperature-Reading und umgekehrt ein humidity-Reading (bei meinen Debugversuchen bin ich zu dem Schluss gekommen, dass das irgendwo im Bereich readingsBulkUpdate() liegt, bin mir aber nicht sicher):
shc_deva ─>{READINGS}{humidity}{VAL} = 55.3
{READINGS}{temperature} = 0 # temperature ist definiert, enthält aber weder {VAL} noch {TIME}
shc_devb ─>{READINGS}{temperature}{VAL} = 23.4
{READINGS}{humidity} = 0 # humidity ist definiert, enthält aber weder {VAL} noch {TIME}
Wenn man FHEM neustartet, erhalten die unvollständigen Readings über WriteStatefile und ReadStatefile Default-Wert für {VAL} und {TIME}. Ab hier sehen dann die Readings so aus:
shc_deva ─>{READINGS}{humidity}{VAL} = 55.3
{READINGS}{temperature}{VAL} = 0
shc_devb ─>{READINGS}{temperature}{VAL} = 23.4
{READINGS}{humidity}{VAL} = 0
Hat dieses Verhalten schon jemand beobachtet, ist das gewollt? Leider habe ich im Forum und im Wiki nichts dazu entdecken können. Könnt Ihr mir weiterhelfen?
Gruß,
Stefan
das ist kein normales verhalten.
verwendest du dispatch/parse? könnte es sein das du zwischendurch aus versehen readings in das falsche device steckst?
gruss
andre
Hi Andre,
ja ich verwende dispatch/parse! Letztendlich hab ich als Grundlage sogar die Module von Dir verwendet, 36_Jeelink.pm und 36_PCA301.pm. D.h. die Struktur ist damit ähnlich ;-). Die smarthomatic Module habe ich ausgegiebig überprüft und gedebuggt. Als Ursache kann ich den Code eigentlich ausschließen. Übrigens: Uwe Freese der Kopf von smarthomatic hat sich das ganz unabhängig von mir durchgesehen und kam zu dem gleichen Ergebnis: Irgendwo im Bereich von readingsBeginUpdate(), readingsBulkUpdate() und readingsEndUpdate(), oder den dahinterliegenden Mechanismen liegt der Fehler...
Gruß,
Stefan
ZitatIrgendwo im Bereich von readingsBeginUpdate(), readingsBulkUpdate() und readingsEndUpdate(), oder den dahinterliegenden Mechanismen liegt der Fehler...
Das mag schon sein, allerdings schaffen z.Zt. etwa 200 Module diesen Fehler nicht auszuloesen. Ihr muesst uns schon verraten, wie man das macht.
Moin rr2000,
kann ich so bestätigen, war allerdings bisher zu faul zum suchen wo der Fehler liegt.
In der Anlage mal zwei Bilder von einem Temperatursensor DS18B20 angebunden mit OWX/OWTHERM.
Zum rekonstruieren:
- FHEM beenden
- fhem.save löschen
- FHEM neu starten, erster Screenshot (vorher.jpg)
- in der Weboberfläche Save config drücken
- Seite neu laden
- et voila, zweiter Screenshot (falschesReading.jpg
Gruß Joachim
Zitat von: rudolfkoenig am 27 Mai 2014, 12:19:54
Das mag schon sein, allerdings schaffen z.Zt. etwa 200 Module diesen Fehler nicht auszuloesen. Ihr muesst uns schon verraten, wie man das macht.
Ja ich weiß, daher vermutlich auch kein Eintrag im Forum ;-)
Ich skizzieren mal den Code wo ich die Readings, abhängig von Geräte- bzw. Message-Typ, eintrage. An keiner anderen Stelle werden die Readings sonst angetastet. Wenn gewünscht kann ich auch den gesamten Code posten.
sub SHC_Dev_Parse($$)
{ ... # Überprüfe Vorraussetzungen und dekodiere Nachricht
readingsBeginUpdate($rhash);
given ($msggroupname) {
when ('Weather') {
given ($msgname) {
when ('Temperature') {
my $tmp = $parser->getField("Temperature") / 100; # parser returns centigrade
readingsBulkUpdate($rhash, "temperature", $tmp);
}
when ('HumidityTemperature') {
my $hum = $parser->getField("Humidity") / 10; # parser returns 1/10 percent
my $tmp = $parser->getField("Temperature") / 100; # parser returns centigrade
readingsBulkUpdate($rhash, "humidity", $hum);
readingsBulkUpdate($rhash, "temperature", $tmp);
}
...
}
...
}
... # Setze state_str aus verfügbaren Readings zusammen
readingsBulkUpdate($rhash, "state", $state_str);
readingsEndUpdate($rhash, 1); # Do triggers to update log file
return @list;
}
Hinweis: Bitte nicht irritieren lassen, dass ich hier einmal die Temperatur und einmal die Temperatur plus Feuchte schreibe. Die Fehlerbeschreibung sollte möglichst einfach und verständlich sein, daher hab ich die Details weggelassen. Das Problem tritt auch mit vielen anderen Messwerte (Entfernung, Helligikeit, Luftdruck) auf (siehe Screenshots).
Gruß,
Stefan
@rr2000: der Code schaut fuer mich ok aus. readingsBulkUpdate setzt die Readings ueber setReadingsVal, und dieser setzt immer VAL und TIME.
Meiner Ansicht nach ist das Problem anderswo zu suchen: irgendwer greift ohne eine Pruefung direkt auf
{READINGS}{humidity}{VAL} zu, auch wenn es noch nicht existiert, oder was aehnliches.
Sonst hilft hier mAn nur debug-Ausgabe zu streuen: ich wuerde in SHC_Dev_Parse am Anfgang
und am Ende alle Readings ausgeben, und schauen, welche Operation den Schaden anrichtet.
@ Rudi,
ZitatMeiner Ansicht nach ist das Problem anderswo zu suchen: irgendwer greift ohne eine Pruefung direkt auf
{READINGS}{humidity}{VAL} zu, auch wenn es noch nicht existiert, oder was aehnliches.
Meintest Du mich?
Zitat von: rudolfkoenig am 27 Mai 2014, 13:08:35
Sonst hilft hier mAn nur debug-Ausgabe zu streuen: ich wuerde in SHC_Dev_Parse am Anfgang
und am Ende alle Readings ausgeben, und schauen, welche Operation den Schaden anrichtet.
Genau das haben ich/wir versucht, über Debug-Ausgaben in SHC_Dev_Parse dem ganzen auf die Schliche zu kommen. Ergebnis: Es passiert nicht in SHC_Dev_Parse.
Mit Elipse und EPIC habe ich versucht im FHEM Code fündig zu werden. Das ist allerdings kläglich gescheitert, da bei EPIC die watch Funktion nicht geht.
@ rr2000, @ Rudi,
das Problem liegt irgendwo in der fhem.pl!
Wie ich oben schon geschrieben habe, kann ich dieses Problem unter ganz anderen Vorraussetzungen bei mir reproduzieren.
Bei mir läuft FHEM auf einer FB7390, nur mit OWX/OWTHERM. Also ein Modul welches mit dem von rr2000 keine Gemeinsamkeit hat.
--> die einzige Gemeinsamkeit ist, dass auch hier unter noch nicht näher bekannten Umständen Phantom Readings auftauchen, die dann auch reproduzierbar sind. In meinem Fall das Reading Feuchte, welches es bei einem OWX Temperatursensor nicht gibt.
Gruß Joachim
Zitatdas Problem liegt irgendwo in der fhem.pl!
Ich finde wir sollten abstimmen.
Moin Rudi,
ich fühle mich gerade, mit verlaub gesagt, von Dir verarscht.
Warum:
Ich versuche Dir bei der Eingrenzung des Problems zu helfen, es wird von Dir nicht auf dieses Hilfsangebot eingegangen, sondern ignoriert,
Wenn ich dann ein zweites mal versuche zu helfen, gibt es einen dummen Kommentar:
ZitatIch finde wir sollten abstimmen.
Das bringt weder rr2000, Dich, noch mich weiter.
Wenn die Informationen von mir zu spärlich waren, sag, was Du zusätzlich noch brauchst.
Ansonsten bin ich hier raus.
Gruß Joachim
debugging per abstimmung. wenn sich das bewährt eröffnet das natürlich unglaubliche möglichkeiten :)
als vorlage zur abstimmung schlage ich vor das ihr ein minimal setup aus genau euren beiden modulen zusammen stellt mit dem das problem reproduzierbar ist.
nicht vorhandene hardware lässt sich auf unix ebene wunderbar mit einem fifo der als directio geöffnet wird simulieren. da kann man dann auf shell ebene einfach die daten rein pipen.
Zitatich fühle mich gerade, mit verlaub gesagt, von Dir verarscht.
Tut mir leid, ich muss mir staerker einpraegen, dass meine Witze auch falsch verstanden werden koennen.
Leider hilft mir dein Beispiel gar nicht: Du sagst, dass das gleiche Problem (was mAn gar nicht so gleich ist, s.u) bei dir auch auftritt, deswegen muss die Ursache fhem.pl sein. Das kann zwar sein, eine logische Schlussfolgerung ist das aber nicht. In beiden Faellen koennte Benutzercode im notify/watchdog/etc oder ein Bug im jeweiligen Modul oder was anderes die Ursache sein. Oder Bug(s) in fhem.pl.
Bzgl. "gleiches Problem": bei rr2000 gibt es einen neuen Hash-Eintrag mit Wert 0, ohne VAL und TIME. Bei dir gibt es korrekte VAL und TIME Eintraege. Meiner Ansicht nach ist es wahrscheinlicher, dass die beiden Faelle komplett andere (und nicht in fhem.pl zu suchende) Ursachen habe. Mag sein, dass ich mich irre, das ist nur mein Bauchgefuehl.
Zitat von: rudolfkoenig am 27 Mai 2014, 14:33:20
Bzgl. "gleiches Problem": bei rr2000 gibt es einen neuen Hash-Eintrag mit Wert 0, ohne VAL und TIME. Bei dir gibt es korrekte VAL und TIME Eintraege. Meiner Ansicht nach ist es wahrscheinlicher, dass die beiden Faelle komplett andere (und nicht in fhem.pl zu suchende) Ursachen habe. Mag sein, dass ich mich irre, das ist nur mein Bauchgefuehl.
Die korreten VAL und TIME Einträge entstehen erst beim neu starten. In der Funktion WriteStatefile und ReadStatefile werden die vorher unkorrekten Einträge mit default-Werten versorgt und damit zu korrekten Einträgen.
Ich nehme an Joachim hat den unkorrekten Hash-Eintrag auch, er wird nur nirgendwo im Webinterface angezeigt. Man kann ihn nur durch Debug-Ausgaben sichtbar machen.
Moin Rudi,
Entschuldigung angenommen.
Ich versuche gerade, das ganze auf einem zweiten System nach zustellen, da ich mein Produktivsystem nicht zerlegen will, und als Vergleich behalten möchte. Sowie ich das geschafft habe, poste ich die fhem.cfg.
@rr2000,
wie komme ich an den hash-Eintrag?
Gruß Joachim
Also mein Debug-Code in SHC_Dev_Parse() sieht so aus:
my $r = $rhash->{READINGS};
foreach my $c (sort keys %{$r}) {
my $rd = $r->{$c};
foreach my $cc (sort keys %{$rd}) {
my $rrd = $rd->{$cc};
print "$rname $c: $rd -> $cc: $rrd\n";
}
}
damit erhalte ich nach einem frischen Start von fhem (rm log/*) folgende Debugausgaben.
SHC_Dev_20 brightness: HASH(0x1e93930) -> TIME: 2014-05-27 15:10:46
SHC_Dev_20 brightness: HASH(0x1e93930) -> VAL: 42
SHC_Dev_20 state: HASH(0x1e93870) -> TIME: 2014-05-27 15:11:04
SHC_Dev_20 state: HASH(0x1e93870) -> VAL: T: 25.3 Baro: 946.46 B: 42
SHC_Dev_20 temperature: HASH(0x1e93630) -> TIME: 2014-05-27 15:11:04
SHC_Dev_20 temperature: HASH(0x1e93630) -> VAL: 25.3
SHC_Dev_23 brightness: HASH(0x1e95230) -> TIME: 2014-05-27 15:11:02
SHC_Dev_23 brightness: HASH(0x1e95230) -> VAL: 65
SHC_Dev_23 humidity: HASH(0x1e939f0) -> TIME: 2014-05-27 15:10:54
SHC_Dev_23 humidity: HASH(0x1e939f0) -> VAL: 48.9
SHC_Dev_23 state: HASH(0x1e937e0) -> TIME: 2014-05-27 15:11:02
SHC_Dev_23 state: HASH(0x1e937e0) -> VAL: T: 24.49 H: 48.9 B: 65
SHC_Dev_23 temperature: HASH(0x1e8dd50) -> TIME: 2014-05-27 15:10:54
SHC_Dev_23 temperature: HASH(0x1e8dd50) -> VAL: 24.49
Alles in Ordnung. Danach stoppe ich fhem mit "shutdown". Und schaue mir log/fhem.save an.
setstate SHC_Dev_20 T: 25.3 Baro: 946.46 B: 42
setstate SHC_Dev_20 2014-05-27 15:11:04 barometric_pressure 946.46
setstate SHC_Dev_20 2014-05-27 15:11:10 brightness 42
setstate SHC_Dev_20 2014-05-27 15:11:26 distance 0 <==== Fehler
setstate SHC_Dev_20 2014-05-27 15:11:26 humidity 0 <==== Fehler
setstate SHC_Dev_20 2014-05-27 15:11:10 state T: 25.3 Baro: 946.46 B: 42
setstate SHC_Dev_20 2014-05-27 15:11:04 temperature 25.3
setstate SHC_Dev_23 T: 24.42 H: 49.1 B: 65
setstate SHC_Dev_23 2014-05-27 15:11:26 barometric_pressure 0 <==== Fehler
setstate SHC_Dev_23 2014-05-27 15:11:02 brightness 65
setstate SHC_Dev_23 2014-05-27 15:11:26 distance 0 <==== Fehler
setstate SHC_Dev_23 2014-05-27 15:11:21 humidity 49.1
setstate SHC_Dev_23 2014-05-27 15:11:21 state T: 24.42 H: 49.1 B: 65
setstate SHC_Dev_23 2014-05-27 15:11:21 temperature 24.42
setstate SHC_PS_40_notify_on active
Ab hier wird der Fehler sichtbar. Die Default-Werte werden in WriteStatefile() in fhem.save geschrieben
my $rd = $r->{$c};
if(!defined($rd->{TIME})) {
Log 4, "WriteStatefile $d $c: Missing TIME, using current time";
$rd->{TIME} = TimeNow();
}
if(!defined($rd->{VAL})) {
Log 4, "WriteStatefile $d $c: Missing VAL, setting it to 0";
$rd->{VAL} = 0;
}
Noch klarer kann man es sehen, wenn man auch alle Hash-Einträge ausgibt:
my $r = $rhash->{READINGS};
foreach my $c (sort keys %{$r}) {
my $rd = $r->{$c};
print "$rname $c: $rd\n"; # Print also empty entries <=====
foreach my $cc (sort keys %{$rd}) {
my $rrd = $rd->{$cc};
print "$rname $c: $rd -> $cc: $rrd\n";
}
}
dann tauchen die Einträge sofort nach einem frischen Start (rm log/* && ./fhem.pl fhem.cfg) auf, als Readings ohne {VAL} und {TIME}:
SHC_Dev_20 barometric_pressure: HASH(0x30a1518)
SHC_Dev_20 barometric_pressure: HASH(0x30a1518) -> TIME: 2014-05-27 15:31:43
SHC_Dev_20 barometric_pressure: HASH(0x30a1518) -> VAL: 946.48
SHC_Dev_20 brightness: HASH(0x30a8e98)
SHC_Dev_20 distance: HASH(0x30a8ec8) <===== Fehler **************************************
SHC_Dev_20 humidity: HASH(0x30a8e68) <===== Fehler **************************************
SHC_Dev_20 state: HASH(0x30a8ef8)
SHC_Dev_20 state: HASH(0x30a8ef8) -> TIME: 2014-05-27 15:31:43
SHC_Dev_20 state: HASH(0x30a8ef8) -> VAL: T: 24.85 Baro: 946.48
SHC_Dev_20 temperature: HASH(0x30a1440)
SHC_Dev_20 temperature: HASH(0x30a1440) -> TIME: 2014-05-27 15:31:43
SHC_Dev_20 temperature: HASH(0x30a1440) -> VAL: 24.85
@ rr2000,
hast Du zufällig dewpoint bei Dir am laufen?
oder
userReadings, die auf ein anderes Device mappen?
@ Rudi,
hier die Minimal fhem.cfg, mit der sich das Problem nachstellen lässt:
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global motd none
attr global mseclog 1
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global userattr DbLogExclude devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global verbose 3
define telnetPort telnet 7072 global
define WEB FHEMWEB 8083 global
attr WEB menuEntries rereadcfg,cmd=rereadcfg,restart,cmd=shutdown restart,update,cmd=update,updatecheck,cmd=update+check,updateforce,cmd=update+force
# Fake FileLog entry, to access the fhem log from FHEMWEB
define Logfile FileLog ./log/fhem-%Y-%m.log fakelog
define eventTypes eventTypes ./log/eventTypes.txt
##############################################################################################
define dew_all dewpoint dewpoint .* Temperatur Feuchte dewpoint
##############################################################################################
define onewire OWX /dev/ttyUSB0
attr onewire room OWX
define OWX_01_2C5987150000 OWID 01 2C5987150000
attr OWX_01_2C5987150000 IODev onewire
attr OWX_01_2C5987150000 model DS2401
attr OWX_01_2C5987150000 room OWX
attr OWX_01_2C5987150000 stateFormat {ReadingsVal($name,"present",0) ? "present" : "not present"}
#############################################################################################
define TS_Bad OWTHERM DS18B20 4638BA030000 300
attr TS_Bad IODev onewire
attr TS_Bad model DS1822
attr TS_Bad room Bad
attr TS_Bad stateFormat {( int (ReadingsVal("TS_Bad","temperature",0) * 10 + 0.5 ) / 10)." °C"}
attr TS_Bad tempHigh 25
attr TS_Bad tempLow 0
attr TS_Bad userReadings Temperatur {( int (ReadingsVal("TS_Bad","temperature",0) * 10 + 0.5 ) / 10)}
define FS_Bad OWMULTI DS2438 362E27010000 300
attr FS_Bad IODev onewire
attr FS_Bad event-min-interval Temperatur:600,Feuchte:600,V:600,VAD:600
attr FS_Bad event-on-change-reading Temperatur,Feuchte,V,VAD
attr FS_Bad icon tropfen
attr FS_Bad model DS2438
attr FS_Bad room Bad
attr FS_Bad stateFormat {sprintf("T: %.1f H: %.1f D: %.1f",ReadingsVal("FS_Bad","Temperatur",0), ReadingsVal("FS_Bad","Feuchte",0), ReadingsVal("FS_Bad","dewpoint",0))}
attr FS_Bad userReadings VAD {(ReadingsVal("FS_Bad","voltage",0) * 1000 + 0.5) / 1000 },V {(ReadingsVal("FS_Bad","VDD",0) * 1000 + 0.5) / 1000 },Temperatur { ReadingsVal("TS_Bad","Temperatur",0) },Feuchte:V { int((((((ReadingsVal("FS_Bad","VAD",0)) + 0.0)/(ReadingsVal("FS_Bad","V",0)) - 0.1515) / 0.00636) / (1.0546 - 0.00216 * (ReadingsVal("FS_Bad","Temperatur",0)))) * 10 + 0.5 ) / 10 }
Bei Entfernen von dewpoint, oder dem Entfernen der userReadings, die auf ein anderes Device mappen verschwindet das Problem.
FHEM mit update force von heute.
So, kann jetzt nicht mehr weitertesten, muss gleich zur Arbeit.
Gruß Joachim
Zitatdann tauchen die Einträge sofort nach einem frischen Start (rm log/* && ./fhem.pl fhem.cfg) auf, als Readings ohne {VAL} und {TIME}:
Damit kann man was anfangen:
- Wo ist fhem.state gespeichert?
- kannst du bitte folgende Funkion
sub
CheckR($)
{
my $txt = shift;
Log 1, "CheckR $txt";
foreach my $d (sort keys %defs) {
next if(!$defs{$d}{READINGS} || $defs{$d}{READINGSCHECKED});
foreach my $r (sort keys %{$defs{$d}{READINGS}}) {
if(!defined($defs{$d}{READINGS}{$r}{VAL}) ||
!defined($defs{$d}{READINGS}{$r}{TIME})) {
Log 1, "*** $d -> $r: $defs{$d}{READINGS}{$r} at $txt";
Log 1, " K:".join(",",sort keys %{$defs{$d}{READINGS}{$r}});
}
$defs{$d}{READINGSCHECKED} = 1;
}
}
}
in fhem.pl einbauen, und es z.Bsp. aus fhem.pl/CommandDefine mit
CheckR("DEF $def")aufrufen?
Habs gerade beim testen mit fhem.cfg.demo gesehen, dass GUEST ein aehnliches Problem hat, die Ursache ist eine unvorsichtige Pruefung per
defined( $hash->{READINGS}{state}{VAL} ) in GUEST_Set, was ein leeres $hash->{READINGS}{state} anlegt, falls sie noch nicht existiert. Sowas vermute ich auch in eurem Fall.
@Joachim: da ich kein OneWire habe, hilft mir das erstmal nicht, ich habe es jetzt zwar kurz getestet, ich sehe aber keine Probleme, abgesehen von den tausenden Meldungen, die bestaetigen, dass ich kein OneWire habe.
@ Rudi,
mal sehen, vielleicht bekomme ich in der Nachtschicht was OneWire freies gebastelt.
Gruß Joachim
Zitat von: rudolfkoenig am 27 Mai 2014, 16:18:05
Damit kann man was anfangen:
- Wo ist fhem.state gespeichert?
- kannst du bitte folgende Funkion
in fhem.pl einbauen, und es z.Bsp. aus fhem.pl/CommandDefine mit
CheckR("DEF $def")
aufrufen?
Wie genau?
Zitat von: rudolfkoenig am 27 Mai 2014, 16:18:05
Habs gerade beim testen mit fhem.cfg.demo gesehen, dass GUEST ein aehnliches Problem hat, die Ursache ist eine unvorsichtige Pruefung per
defined( $hash->{READINGS}{state}{VAL} )
in GUEST_Set, was ein leeres $hash->{READINGS}{state} anlegt, falls sie noch nicht existiert. Sowas vermute ich auch in eurem Fall.
Stimmt, das ist bei mir der Fall!
if (defined($rhash->{READINGS}{$state_format_arr->[$i]}{VAL})) {
Ich werds noch testen. Danke für die Hilfe!
Gruß,
Stefan
OK, wenn man es richtig macht funktioniert es auch.
if ((defined($rhash->{READINGS}{$state_format_arr->[$i]})
&& defined($rhash->{READINGS}{$state_format_arr->[$i]}{VAL}))) {
Nochmals danke und bitte verzeih mir den Hochmut den Fehler in der fhem.pl vermutet zu haben ;)
Gruß,
Stefan
Moin Rudi,
Ich entschuldige mich ersteinmal, dass ich die fhem.pl in Verdacht hatte, es kann auch die 98_dewpoint.pm sein, womit der Ball dann bei mir liegt.
Zum nachstellen reicht folgende fhem.cfg:
attr global autoload_undefined_devices 1
attr global logfile ./log/fhem-%Y-%m.log
attr global modpath .
attr global mseclog 1
attr global statefile ./log/fhem.save
attr global updateInBackground 1
attr global userattr DbLogExclude devStateIcon devStateStyle icon sortby webCmd widgetOverride
attr global verbose 3
define telnetPort telnet 7072 global
define WEB FHEMWEB 8083 global
# Fake FileLog entry, to access the fhem log from FHEMWEB
#define autocreate autocreate
#attr autocreate filelog ./log/%NAME-%Y.log
define eventTypes eventTypes ./log/eventTypes.txt
###################################################################################################
define dew_all dewpoint dewpoint .* temperature humidity dewpoint
define alive dummy
attr alive room Alive
attr alive setList 0 1
attr alive userReadings temperature { ReadingsVal("alive","state",0) }
define at_alive at +*00:01:00 {if ("$value{alive}" == 0) {fhem("set alive 1")} else {fhem("set alive 0")}}
attr at_alive room Alive
####################################################################################################
nach einem Save config gibt es dann ein Phantom Reading "humidity"
mich wundert, dass das noch keinem aufgefallen ist.
Gruß Joachim
Moin Rudi,
konntest Du das Phantom Reading nachstellen?
Gruß Joachim
Habs nicht probiert, fuer dewpoint fuehle ich mich nicht zustendig.
Dass Du nicht für dewpoint zuständig bist, weiß ich.
Die Fragen sind:
1. Tritt das ganze nur bei mir auf?
2. Da es bei mir nur bei Save config, rereadconfig und restart auftritt, und die Einbindung in FHEM ja deutlich von normalen Modulen abweicht, wo liegt der Fehler? Dewpoint selber schreibt nicht in die fhem.save, und solange die nicht durch FHEM bedient wird, taucht das Phantom Reading nicht auf.
Gruß Joachim
1. Nein, ich konnte es auch nachstellen.
2. Vermutlich in dewpoint.pm, da habe ich solche Zeilen gesehen:
if (defined($dev->{READINGS}{$hum_name}{VAL}) && defined($dev->{READINGS}{$temp_name}{TIME})) {
die das beschriebene Effekt haben. Ich empfehle ReadingsVal/ReadingsTimestamp, die das Problem vermeiden.
Willi (Maintainer von dewpoint) hat unlaengst geschrieben, dass er das Modul an Olaf/Joachim :) abgeben will, das ist aber laut Maintainer.txt wohl noch nicht geschehen. Trotzdem sollte man eine neue Diskussion mit passenden Titel im passenden Bereich (Automatisierung) oeffnen.
Moin Rudi,
Danke für die Rückmeldung.
Du hast Recht, dass ich das Modul von Willi übernehme, bin nur noch nicht dazugekommen, das in der Maintainers.txt zu ändern.
Werde mich jetzt mal mit Deinen Informationen auf die Suche machen, und den Fehler beseitigen.
Gruß Joachim