sporadische Sensor-Lesefehler (I2C)

Begonnen von yoda_gh, 03 März 2018, 23:46:36

Vorheriges Thema - Nächstes Thema

yoda_gh

Hallo!

Ich wollte mal prinzipiell nachfragen, wie andre hier mit sporadischen Lesefehlern bei Sensoren umgehen. In meinem Fall ist es ein per I2C an den Raspi abgeschlossener HDC1080. Zuerst hatte ich fast stündlich einmal 125  Grad oder 100% Feuchte in der Wohnung. Anscheinend gibt es regelmäßig Störungen in meiner I2C-Anbindung.

Nachdem ich dem Modul beigebracht habe, die Fehler, die RPII2C erkennt, nicht einfach zu ignorieren, sehe ich jetzt nur noch alle paar Tage falsche Werte..

Da es bei dem Sensor und I2C ja keine Prüfsummen o.ä. gibt, tendiere ich dazu, das in Software zu lösen, zum Beispiel mit einem userReading, wo ich unrealistische Werte verwerfe. Eigentlich gehört so was aber in die entstehenden FHEM-Module, oder?

Wie geht ihr mit so was um? Hardware reparieren, so dass keine Fehler mehr auftreten? Oder doch lieber in Software lösen (ziehe ich bei den seltenen Fehlern eigentlich vor)? Sollte man in die I2C-Module eine passende Erkennung einbauen, z. B. Wert verwerfen, wenn Differenz zur letzten Messung zu groß?

Gernot

jensb

Hallo yoda_gh,

eine eingefache Möglichkeit sind die readingFnAttributes. Der event-aggregator "median" wurde extra eingebaut, um sporadische Ausreißer aus einer sonst plausiblen Abfolge von Messwerten herauszufiltern. Hast du aber relativ vielen Fehler oder Zeiten wo nur Fehler auftreten, hilft das nicht.

Ein Prüfsumme ist bei I2C normalerweise nicht erforderlich. Wenn Störungen auf den Bus durchschlagen, dann versteht auch das Device die Anfragen vom Master nicht mehr oder falsch. Dabei kommt es meist zu Busfehlern und die werden an die Software zurückgemeldet. Entscheiden ist also, ob das Modul das berücksichtigt. Es macht aber keinen Sinn eine Wert aus einem Lesevorgang mit Fehler in ein Reading zu übertragen. Besser wäre es, den letzten fehlerfreien Wert eine Zeit anstehen zu lassen und nach einem sinnvollen Timeout einen Fehlerstatus zu setzen.

Die Hardware würde ich mir unabhängig davon auf jeden Fall vornehmen. I2C ist zwar nicht dafür spezifiziert, verträgt aber je nach Schirmung schon mal ein paar Meter Kabel, vor allem wenn man den Bustakt heruntersetzt.

Grüße,
Jens
FHEM 6.1 - RPi 4 Raspbian 12 + PiTFT - OPi Zero Armbian 5.35
EnOcean - (W)LAN/Firmata: BMP180, TSL2561, SHT21, Heatronic 3, OBIS - WLAN/ESP8266: Gardena 1251, Zirkulationspumpe - RTL433: Oregon - Bluetooth - MQTT
Contributions: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/jensb

yoda_gh

Hallo Jens!

Super, danke für den Tipp mit dem event-aggregator "median". Ich hatte zwar in der commandref das Beispiel mit "myBadSensor" gesehen. aber bin trotzdem nicht auf die Idee gekommen, dass das mir helfen könnte. Man sollte in der commandref dazu noch etwas ergänzen, habe dazu einen Post gemacht.

Seit ich in 52_I2C_HDC1008.pm die gemeldeten Busfehler auswerte, habe ich praktisch keine fehlerhaften Werte mehr.

Hardware-Optimierung wäre ggf. sinnvoll, aber ehrlich gesagt fehlt mir dazu aktuell die Zeit/Lust (mit zwei kleinen Kindern daheim) ;-). Kabel ist nur ca. 10 cm lang, verläuft aber knapp neben der FritzBox, also vielleicht stört da was rein - oder der andere I2C-Sensor (CO2-SenseAir K30) am selben Bus macht gelegentlich Unsinn und stört meine kommunikation (zum Beispiel redet der andere Sensor nur mit meinem Raspi, wenn ich die I2C-Frequenz auf 90kHz setze, weder mit mehr, noch mit weniger) - also vermutlich eine aufwändigere Fehlersuche...

Aber wie gesagt, ich hatte jetzt schon seit einer Woche keinen Ausreisser mehr (mit dem Original-Code von I2C_HDC1008 ca. all 90 Minuten), insofern ist das also für mich wohl erledigt.

Danke,

Gernot