LaCrosse - ab und zu falscher Wert?

Begonnen von der_da, 25 Januar 2020, 17:03:09

Vorheriges Thema - Nächstes Thema

der_da

Hallo.
Ich habe seit langer Zeit LaCrosse-Thermometer im Einsatz, die brav ihren Dienst verrichten. Nun tritt bei einem der Thermometer seit einiger Zeit das Problem auf, dass ab und zu ein völlig unplausibler Wert gesendet wird (normal um die 20°C, ab und zu nur ca. 3°C). Ich habe schon die Batterien herausgenommen um eine andere Sendefrequenz zu bekommen, in der Annahme, der Nachbar hat ein baugleiches Gerät im Garten oder so etwas, aber auch mit einer neuen Frequenz bleibt es bei dem merkwürdigen Verhalten. Kennt jemand ein solches Problem und weiß Abhilfe?

Danke!

dkreutz

Ich habe insgesamt 10 Technoline TX29IT und beobachte hin und wieder auch solche "Aussetzer". Außerdem hatte ich schon bei einigen der Devices plötzlich zusätzliche Readings "windspeed" und "winddirection", als ob ich eine Wetterstation mit Windmesser hätte. Dazu wurde mir hier im Forum erklärt, dass das Lacrosse-Funkprotokoll nicht mit Prüfsummen o.ä. arbeitet und so durch Störeinflüsse für den Empfänger gültige Funk-Telegramme entstehen können, die aber fehlerhafte Werte enthalten.

Der Batteriewechsel ändert meines Wissens nach nicht die Funkfrequenz, sondern nur die Geräte-ID.
Raspberry Pi3B+ (Bullseye) / JeeLink868v3c (LaCrosse), nanoCUL433 (a-culfw V1.24.02), HM-MOD-UART (1.4.1), TEK603, MapleCUL / diverse Sensoren/Sender/Aktoren von Technoline, Intertechno, Shelly, Homematic und MAX!, Froggit Wetterstation, Luftdaten.info / Autor des fhem-skill für Mycroft.ai

der_da

Zitat von: dkreutz am 25 Januar 2020, 20:16:00
Der Batteriewechsel ändert meines Wissens nach nicht die Funkfrequenz, sondern nur die Geräte-ID.
Ja sorry, meinte ich auch. Aber die ID ist ja im Funkprotokoll mit drin. Insofern sollte ein dazwischenfunkendes Gerät vom Nachbarn durch ändern der eigenen ID ja "entschärft" werden. Danke für deine Erläuterung. Mich wundert halt nur, dass von meinen (müsste erst nachzählen) ca. 15 LaCrosse-Geräten nur das eine neuerdings zickt.

HCS

Das LaCross-Protokoll hat eine Prüfsumme, aber trotzdem kann es bei der Funkübertragung (sehr selten) zu Datenpaketen kommen, bei denen die Prüfsumme stimmt und trotzdem falsche Werte zustande kommen.
Das sollte der filterTreshold (siehe CommandRef), der bei nicht gesetztem Attribut 10 ist, eigentlich abfangen.
Allerdings nur, wenn der Wert nur einmal kommt.

Zu prüfen wäre nun im Log des Sensors, was wie oft gesendet wird.
Also ob das einzelne Außreiser sind, z.B. so aussieht: 20,20,20,3,20,20,20

Oder ob der falsche Wert mehrfach nacheinander kommt, also so z.B.: 20,20,3,3,3,20,20
In diesem Fall kann man fast sicher davon ausgehen, dass der Sensor es so sendet oder ein anderer Sensor mit der gleichen ID dazwischenfunkt.

Das "windspeed und winddirection"-Problem hat die gleiche Urache.
Ich wollte schon immer mal (hätte ich nur Zeit) eine Konfiguration in das LaCrosse-Modul einbauen, um welche Sorte Sensor es sich handelt.
Dann könnte es je nach Sensor-Typ Readings unterdrücken, die der Sensor definitiv nicht hat.

Wzut

Zitat von: HCS am 26 Januar 2020, 08:41:00
Ich wollte schon immer mal (hätte ich nur Zeit) eine Konfiguration in das LaCrosse-Modul einbauen, um welche Sorte Sensor es sich handelt.
Dann könnte es je nach Sensor-Typ Readings unterdrücken, die der Sensor definitiv nicht hat.
das wäre schön ... ich woltte vor ein paar Wochen genau da für mich ran (neues Attribut model) , dann kam aber die Mega Baustelle MAX dawischen und so ärgere ich mich ersteinmal weiter über unsinnige Readings.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

der_da

#5
Zitat von: HCS am 26 Januar 2020, 08:41:00
Zu prüfen wäre nun im Log des Sensors, was wie oft gesendet wird.
Also ob das einzelne Außreiser sind, z.B. so aussieht: 20,20,20,3,20,20,20

Oder ob der falsche Wert mehrfach nacheinander kommt, also so z.B.: 20,20,3,3,3,20,20
In diesem Fall kann man fast sicher davon ausgehen, dass der Sensor es so sendet oder ein anderer Sensor mit der gleichen ID dazwischenfunkt.
Ich habe nachgesehen und der letztere Fall ist gegeben. Es kommen also mehrfach unsinnige Werte.Da ich die ID aber durch Batteriewechsel geändert habe, das Problem aber weiterhin besteht, glaube ich eher nicht an einen dazwischenfunkenden Nachbarsender. Das Problem fing um die Weihnachtstage letztes Jahr an, wie man am angehängten Plot erkennen kann.
Zitat
Das "windspeed und winddirection"-Problem hat die gleiche Urache.
Ich wollte schon immer mal (hätte ich nur Zeit) eine Konfiguration in das LaCrosse-Modul einbauen, um welche Sorte Sensor es sich handelt.
Dann könnte es je nach Sensor-Typ Readings unterdrücken, die der Sensor definitiv nicht hat.
Das fände ich auch super. Dieses windspeed-Problem ist für mich zwar kein Problem, aber auch bei mir gibt es einige dieser Readings, die da definitiv nicht hingehören.

ti_bar74

Hallo zusammen,
gibt es zu diesem Problem neue Erkenntnisse?

Auch ich habe einen Temperaturgeber (Technoline TX25), der viel zu hohe Werte über FHEM anzeigt. Vor Ort misst dieser Sensor 17.8°C und zeigt diese im Display so an, aber in FEHM werden 45.9 C angegeben. Aufgefallen ist es erst jetzt, da es sich dabei um die Pooltemperatur handelt. Dem Log nach tritt dieser falsche Wert seid dem 10.02.2020 auf. Bis dahin habe verhielt er sich unauffällig. Störungen aus der unmittelbaren Nachbarschaft kann ich ausschließen.

Vielleicht gibt es zwischenzeitlich doch noch eine Idee, woran das liegt.

Viele Grüße, Tilo

connormcl

Naja, vielleicht hat auch bei dir ein Nachbar ein neues Gerät beschafft, das die gleiche ID verwendet und bei dir reinsendet.

Könnte man testen, indem man die Batterie herausnimmt und falls noch Werte in FHEM ankommen, kommen sie von anderswo...
Aber Vorsicht: je nach Gerät wird dann eine neue ID vergeben und man muss den Sensor in FHEM wie bei Batteriewechsel neu anlernen.

Da das aber ein Temperatursensor ist, könnte die ID auch fest sein. In dem Fall hat man dann ein Problem, da man sie nicht ändern kann, wenn der Nachbar reinsendet. Dann müssen die Werte stark gefiltert werden, was nicht immer möglich ist, wenn die Temperaturbereiche ähnlich sind. In dem Fall würde ich ein Thermometer mit wechselbarer ID nachkaufen, wenn es nicht auch noch an eine Messstation sendet.

Weitere Möglichkeit ist eine leere Batterie. Meine Technoline zeigen zwar ihren Batteriestatus an und senden diesen normalerweise auch mit. Ich hatte aber schon Fälle in denen das nicht funktioniert hat. Die Batterieanzeige war auf ok, das Thermometer hat Mist gesendet oder war nicht mehr empfangbar und nach Batteriewechsel war wieder alles ok.


Hollo

Zitat von: ti_bar74 am 25 Mai 2020, 15:38:54
...Vielleicht gibt es zwischenzeitlich doch noch eine Idee, woran das liegt...
Da würde ich ganz stark davon ausgehen, dass sich die ID des Sensors geändert hat und Du da einen ganz anderen empfängst.
Ich würde beim entsprechenden Sensor in FHEM das "replaceBatteryForSec" aktivieren und am Sensor 1x Batterien raus und wieder rein.

Bzgl. der "ungültigen" Sensorwerte habe ich auch sporadisch.
Interessant ist, dass dann meist mehrere "falsche" Einträge gleichzeitig erscheinen.

Es stört mich eigentlich nur, wenn ich gerade an FHEM arbeite und im WebIF drüber stolper. Sonst sehe ich es ja gar nicht.  ;)

Ich habe mir da mal eine Funktion eingebaut, die ich in den Fällen dann einfach mal kurz aufrufe.
Ist bei mir ganz einfach, da die Sensoren nummeriert sind, und die Aufgabe per Alias zugewiesen ist.


################ LaCrosse Readings aufraeumen ######
# nach einiger Zeit sammeln sich bei meinen LaCrosse-Sensoren  #
# diverse Readings an, die die gar nicht koennen/kennen             #
# da das haendische Loeschen muehsam ist (und ich vergesslich)#
# packe ich das jetzt mal alles in eine Funktion                              #
##########################################
sub
LaCrosseCleaner()
{
# wir fangen mit den IT-Sensoren an
fhem("deletereading Sensor_0.* wind.*");
fhem("deletereading Sensor_0.* rain.*");
fhem("deletereading Sensor_0.* gas.*");
fhem("deletereading Sensor_0.* temperature2");
# dann gibt es noch das LaCrosse Gateway
fhem("deletereading LaCrosse_01 wind.*");
fhem("deletereading LaCrosse_01 rain.*");
fhem("deletereading LaCrosse_01 gas.*");
fhem("deletereading LaCrosse_01 temperature2");
# Druck ist ein Sonderfall, den haben naemlich beide Gateways
# daher ein erweitertes RegEx
fhem("deletereading Sensor_0[1-9] pressure");
}

FHEM 6.x auf RPi 3B Buster
Protokolle: Homematic, Z-Wave, MQTT, Modbus
Temp/Feuchte: JeeLink-Clone und LGW mit LaCrosse/IT
sonstiges: Linux-Server, Dreambox, "RSS-Tablet"