LaCrosse: falsche Zuordnung der Temperatursensoren

[willybauss]

Bei mir ist offenbar einer der Sensoren gestorben. Eigentlich hätte ich erwartet, dass dann gar keine Werte mehr "kommen", aber fhem hat offenbar beschlossen, gelegentlich die Werte eines anderen Sensors (beides TX35DTH-IT) zu verwenden. So habe ich jetzt 2 Plots mit denselben Werten, wovon natürlich nur einer richtig ist.  Die Adresse beider Sensoren ist natürlich unterschiedlich.

Ist das ein bekanntes Problem? Und was kann ich dagegen tun?

[HCS]

Ist das ein bekanntes Problem? Und was kann ich dagegen tun?

Das ist ein mir unbekanntes Problem und eigentlich kann das nicht sein.
Zeig mal einen list der beiden betroffenen LaCrosse devices.

[willybauss]

Hier der komplette Inhalt der Raw Definitions.

Der ausgefallene Sensor, der keine Daten sendet:

Code Auswählen Erweitern

defmod LaCrosse_Bad_OG LaCrosse 19
attr LaCrosse_Bad_OG IODev myJeeLink
attr LaCrosse_Bad_OG doDewpoint 1
attr LaCrosse_Bad_OG event-min-interval humidity:120,temperature:120
attr LaCrosse_Bad_OG event-on-update-reading .*
attr LaCrosse_Bad_OG room LaCrosse


Der "andere" Sensor, dessen Daten fälschlicherweise dem "Bad_OG" zugeordnet werden:

Code Auswählen Erweitern

defmod LaCrosse_Apfelregal LaCrosse 37
attr LaCrosse_Apfelregal IODev myJeeLink
attr LaCrosse_Apfelregal doDewpoint 1
attr LaCrosse_Apfelregal event-min-interval humidity:120,temperature:120
attr LaCrosse_Apfelregal event-on-update-reading .*
attr LaCrosse_Apfelregal room LaCrosse


Inzwischen sendet "Bad_OG" wieder - warum auch immer. Somit sind wieder die richtigen Daten im Plot. Ich würde dennoch gerne verstehen, was da falsch lief. Ich kann ggf. gerne nochmal bei "Bad_OG" die Batterien entfernen, um den Fehlerfall nochmal zu provozieren, wenn das hilft. Hier erst mal der gestrige Effekt im Plot.

[willybauss]

Hier auch noch die Definitionen der Log-Devices:

Code Auswählen Erweitern

defmod FileLog_LaCrosse_Bad_OG FileLog /mntUSB/fhem/log/LaCrosse_Bad_OG-%Y-%m.log LaCrosse_Bad_OG:humidity:.*|LaCrosse_Bad_OG:temperature:.*
attr FileLog_LaCrosse_Bad_OG archivedir /mntUSB/fhem/log/archive/
attr FileLog_LaCrosse_Bad_OG logtype text
attr FileLog_LaCrosse_Bad_OG nrarchive 2
attr FileLog_LaCrosse_Bad_OG room LaCrosse

Code Auswählen Erweitern

defmod FileLog_LaCrosse_Apfelregal FileLog /mntUSB/fhem/log/LaCrosse_Apfelregal-%Y.log LaCrosse_Apfelregal
attr FileLog_LaCrosse_Apfelregal logtype text
attr FileLog_LaCrosse_Apfelregal room LaCrosse

Da hatte ich bei "Apfelregal" wohl den Filter vergessen, insofern wird alles geloggt (auch Batteriestand und dewpoint), aber das sollte nichts mit dem Fehler zu tun haben. Sobald das Thema geklärt ist werde ich das korrigieren.

[willybauss]

Mit herausnehmen der Batterien kann ich den Effekt nicht reproduzieren.

Könnte es sein, dass  - trotz "battery ok" -  die Batterien so schwach waren, dass nur noch die Kennung gesendet wurde und die Daten nicht? Dann hat fhem womöglich den nächsten gesendeten Datensatz (eben dem des anderen Sensors) dem Bad_OG-Sensor zugeordnet.

Ich habe grade nochmal die Batterien nachgemessen, die während des Problems drin waren. Beide zeigen 1,42V. Das ist nicht voll, aber auch nicht total leer; und wie geschrieben: der Sensor meldete "battery ok".

[willybauss]

Mist. Auch mit den "alten" Batterien tritt der Effekt heute nicht mehr auf. Bleibt also nur die Vermutung:

Könnte es sein, dass  - trotz "battery ok" -  die Batterien so schwach waren, dass nur noch die Kennung gesendet wurde und die Daten nicht? Dann hat fhem womöglich den nächsten gesendeten Datensatz (eben dem des anderen Sensors) dem Bad_OG-Sensor zugeordnet.

[HCS]

Mist. Auch mit den "alten" Batterien tritt der Effekt heute nicht mehr auf. Bleibt also nur die Vermutung:
Könnte es sein, dass  - trotz "battery ok" -  die Batterien so schwach waren, dass nur noch die Kennung gesendet wurde und die Daten nicht? Dann hat fhem womöglich den nächsten gesendeten Datensatz (eben dem des anderen Sensors) dem Bad_OG-Sensor zugeordnet.

Das kann nicht sein. Auf den übertragenen Daten ist eine CRC-Prüfung drauf. Wenn die nicht komplett gesendet weden, gehen die nicht durch.
Hatte auch bei meinen gefühlten 20 Sensoren noch nie etwas in die Richtung und ich hatte schon öfters leer werdende Batterien.

Wäre es möglich, dass ein Nachbar einen Sensor mit dieser ID hat, der gerade so an der Reichweitengrenze ist und manchmal empfangen wird?
Nachdem Du die Batterien dann raus hattest, hast Du ja eine neue ID und nicht mehr die vom Nachbarn, das wäre dann die Erklärung, warum es jetzt nicht mehr auftritt.

[willybauss]

Dann wäre es aber ein enormer Zufall, dass sein Sensor exakt dieselben Werte für Temperatur und Luftfeuchte anzeigt.

[HCS]

Ja, ist eine seltsame Sache.
Eventuell hat der Sensor ja tatsächlich bis zu seinem Batterie-Reset seltsame Dinge gesendet.
Ich würde jetzt einfach mal abwarten und beobachten.

[willybauss]

Wird wohl so gewesen sein. Was mich daran stört ist, dass er bis zuletzt "battery ok" meldete, was aber offenbar nicht stimmte. Ist das ein bekanntes Thema?

[HCS]

Kein Ahnung, wie es bei einem TX35 genau ist, aber ich habe das Thema hier mal für einen TX29DTH-IT genau beleuchtet:
https://forum.fhem.de/index.php/topic,61313.msg528971.html#msg528971

[willybauss]

ok, danke. Dann scheint der TX35 deutlich empfindlicher auf geringe Batteriespannung zu reagieren. Wie gesagt: die alten Batterien hatten je 1,42V und er sendete nicht mehr. Das hätte ich früher wissen sollen, schade.

[willybauss]

Ist eigentlich der Unterschied bekannt zwischen TX29DTH-IT und TX35DTH-IT?

[HCS]

Ist eigentlich der Unterschied bekannt zwischen TX29DTH-IT und TX35DTH-IT?

Rein rechnerisch ist der Unterschied 6 

Ansonsten:
TX29DTH-IT: 17.241 kbps
TX35DTH-IT: 9.579 kbps

Senden beide das gleiche Protokoll, nur mit unterschiedlicher data rate.

[willybauss]

super, danke Dir!