FHEM Forum

FHEM - Hausautomations-Systeme => 1Wire => Thema gestartet von: FEHMPiDi am 14 September 2015, 20:28:30

Titel: Filtern von unplausieblen Temperaturwerten
Beitrag von: FEHMPiDi am 14 September 2015, 20:28:30
Hallo,

ich habe einige DS18B20 Sensoren an einem RasPi zu hängen und wie folgt in FHEM eingebunden:

define GPIO4_DS18B20_00000485c220 GPIO4 28-00000485c220
attr GPIO4_DS18B20_00000485c220 alias Temp_Schlafzimmer
attr GPIO4_DS18B20_00000485c220 group Temperatur
attr GPIO4_DS18B20_00000485c220 icon temp_temperature
attr GPIO4_DS18B20_00000485c220 model DS18B20
attr GPIO4_DS18B20_00000485c220 room Schlafzimmer
attr GPIO4_DS18B20_00000485c220 stateFormat {sprintf "%.2f °C", ReadingsVal($name, "temperature", 0)}
define FileLog_GPIO4_DS18B20_00000485c220 FileLog ./log/GPIO4_DS18B20_00000485c220-%Y.log GPIO4_DS18B20_00000485c220
attr FileLog_GPIO4_DS18B20_00000485c220 alias Log_Temp_Schlafzimmer
attr FileLog_GPIO4_DS18B20_00000485c220 logtype text
attr FileLog_GPIO4_DS18B20_00000485c220 room Schlafzimmer


Jetzt habe ich das Problem das vereinzelt Werte von 80°C in den Logs stehen. Es scheint an der Verdrahtung zu liegen. Es gehen normale Kabel quer durchs Haus. Ich musste die bestehende Installation nutzen. Da kann ich also nichts mehr ändern. Kondensatoren und spezielle Dioden habe ich als Entstörschaltung schon versucht. Inzwischen kommen auch nur sehr wenige fehlerhafte Werte. Ich würde diese aber trotzdem gern aus dem Logfile fernhalten. Kann man also Werte über z.B. 50°C einfach ignorieren und den vorherigen Wert anzeigen?
Gibt es da ein attr in Fhem oder müsste man das in einer eigenen Funktion schreiben?
Wie müsste diese aber dann aussehen. ich kenne mich in Perl noch gar nicht aus. Bin gerade dabei mich einzuarbeiten.

Also danke schon mal für Eure Hilfe
Titel: Antw:Filtern von unplausiblen Temperaturwerten
Beitrag von: Bartimaus am 15 September 2015, 09:25:38
Moin,

ich hatte diese Probleme auch, bis ich alle Kontakte zu den Sensoren überprüft und ggfls. erneuert/verbessert habe. Seitdem keine Fehler mehr.
Um diese Werte nicht zu loggen, kann man anstelle FileLog http://www.fhemwiki.de/wiki/DbLog (http://www.fhemwiki.de/wiki/DbLog) verwenden. Dabei gibt es "exclude" Möglichkeiten.

Um die Einträge aus FileLog nachträglich zu entfernen, empfehle ich: http://heinz-otto.blogspot.de/2015/08/hilfe-mein-log-file-lauft-uber.html (http://heinz-otto.blogspot.de/2015/08/hilfe-mein-log-file-lauft-uber.html)

Otto ist auch User hier im Forum.
Titel: Antw:Filtern von unplausieblen Temperaturwerten
Beitrag von: Prof. Dr. Peter Henning am 15 September 2015, 14:57:37
1.Tipp: Nicht den GPIO-Port benutzen, sondern einen ordentlichen Busmaster für 20 € kaufen - der macht das Timing nämlich sehr viel sauberer, als die softwareseitige Emulation mit Raspberry Pi. Besonders dann, wenn die Verkabelung unsauber ist (z.B. die korrekte Topologie nicht eingehalten wurde, siehe hier http://www.fhemwiki.de/wiki/1-Wire_Busverlegung#Topologie), sollte das der erste Schritt sein.

2. Tipp: Ein fehlerhafter Messwert kann auf dem 1-Wire Bus nur dann auftreten, wenn auch der CRC-Fehlerkorrekturcode nicht stimmt. Also ordentliche Module verwenden - OWX/OWTHERM und OWFS/OWServer/OWDevice werfen nicht validierte Messwerte (bei denen der CRC nicht stimmt !) aus den Messdaten heraus.

Die nachträgliche Filterung wäre eine unselige Krücke.

LG

pah
Titel: Antw:Filtern von unplausieblen Temperaturwerten
Beitrag von: Bartimaus am 15 September 2015, 15:45:59
Zitat von: Prof. Dr. Peter Henning am 15 September 2015, 14:57:37
1.Tipp: Nicht den GPIO-Port benutzen, sondern einen ordentlichen Busmaster für 20 € kaufen - der macht das Timing nämlich sehr viel sauberer, als die softwareseitige Emulation mit Raspberry Pi. Besonders dann, wenn die Verkabelung unsauber ist (z.B. die korrekte Topologie nicht eingehalten wurde, siehe hier http://www.fhemwiki.de/wiki/1-Wire_Busverlegung#Topologie (http://www.fhemwiki.de/wiki/1-Wire_Busverlegung#Topologie)), sollte das der erste Schritt sein.

2. Tipp: Ein fehlerhafter Messwert kann auf dem 1-Wire Bus nur dann auftreten, wenn auch der CRC-Fehlerkorrekturcode nicht stimmt. Also ordentliche Module verwenden - OWX/OWTHERM und OWFS/OWServer/OWDevice werfen nicht validierte Messwerte (bei denen der CRC nicht stimmt !) aus den Messdaten heraus.

Die nachträglich Filterung wäre eine unselige Krücke.

LG

pah

Yip, bin Anfang des Jahres auch von GPIO4 auf HardwareBusmaster umgestiegen. Dabei dann den Verkabelungs/Kontakt/Fehlern auf die Spur gekommen und behoben, seitdem Ruhe.
Titel: Antw:Filtern von unplausiblen Temperaturwerten
Beitrag von: smurfix am 15 September 2015, 18:23:06
Zusatz: exakt 85°C sind fast immer ein Bug, denn diesen Wert meldet der DS18B20, wenn er ein Problem hat.
(Falls jemand ihn verwendet, um die Vorlauftemperatur der Heizung im tiefsten Winter zu messen. Oder die Sauna. Ansonsten sollten solche Temperaturen im Wohnbereich eher nicht vorkommen.)
Titel: Antw:Filtern von unplausieblen Temperaturwerten
Beitrag von: FEHMPiDi am 16 September 2015, 13:19:54
Hallo,

danke für die Antworten. Dann werde ich noch mal die Verkabelung prüfen und mich mit den oben genannten Modulen beschäftigen müssen. Ich gehe mal davon aus das es da auch genug tutorials gibt
Titel: Antw:Filtern von unplausieblen Temperaturwerten
Beitrag von: FEHMPiDi am 17 September 2015, 08:10:59
Hallo,
Eins habe ich noch nicht ganz verstanden im Wiki.
Wenn ich den OWSERVER benutze, brauche ich dann einen zusätzlichen Busmaster (Hardware) oder können die Sensoren am Gpio4 bleiben?

Danke


Gesendet von meinem SM-G901F mit Tapatalk

Titel: Antw:Filtern von unplausiblen Temperaturwerten
Beitrag von: smurfix am 17 September 2015, 08:24:30
owserver kann den Kerneltreiber verwenden, und der wiederum hat ein GPIO-Modul.

Optimal ist das nicht; ich würde auf jeden Fall einen DS2482 an i²c anschließen.
Titel: Antw:Filtern von unplausieblen Temperaturwerten
Beitrag von: FEHMPiDi am 17 September 2015, 09:49:33
Ok. Könnte man dann den ds2482 parallel mit dem mcp23017 betreiben. Den habe ich nämlich als portexpander an meinem rpi dran und möchte darüber heizungsstellantriebe ansteuern.

Gesendet von meinem SM-G901F mit Tapatalk

Titel: Antw:Filtern von unplausieblen Temperaturwerten
Beitrag von: smurfix am 17 September 2015, 12:26:00
Solange die nicht dieselbe I²C-Adresse haben, ist das kein Problem. Und die kann man einstellen ...
Titel: Antw:Filtern von unplausieblen Temperaturwerten
Beitrag von: FEHMPiDi am 23 September 2015, 08:33:10
Ok, das hört sich gut an. Habe jetzt mal etwas gegoogelt und es gibt den ds2482 ja als 1 und 8 Chanel.  Was mir nicht ganz klar ist. Kann ich an einem Chanel nur einen Sensor anschließen oder mehrere. 

Gesendet von meinem SM-G901F mit Tapatalk

Titel: Antw:Filtern von unplausieblen Temperaturwerten
Beitrag von: smurfix am 23 September 2015, 08:53:38
ZitatWas mir nicht ganz klar ist. Kann ich an einem Chanel nur einen Sensor anschließen oder mehrere
*Channel.

1Wire ist ein Bus. Klar kann man da mehrere anschließen; denkst du, Leute mit 50 1Wire-Sensoren im Haus legen zu jedem ein Extrakabel?
Titel: Antw:Filtern von unplausieblen Temperaturwerten
Beitrag von: Prof. Dr. Peter Henning am 23 September 2015, 11:18:04
Der war gut ... ;D

LG

pah
Titel: Antw:Filtern von unplausieblen Temperaturwerten
Beitrag von: ritchie am 23 September 2015, 18:53:46
Hallo  FEHMPiDi,

schau Dir mal die Wiki hier an, da ist der Aufbau des 1-wire Bus grafisch dargestellt.

http://www.fhemwiki.de/wiki/1-Wire_Busverlegung#Topologie

Dieser besagte CHIP kann 8 solche Bus Strukturen versorgen.


Zitat
ich habe einige DS18B20 Sensoren an einem RasPi zu hängen und wie folgt in FHEM eingebunden:
War das nicht schon die Antwort ?

In diesem Fall ist 1 Channel in Betrieb (GPIO).

Hier auch die Verkabelung/Busbelegung: http://www.fhemwiki.de/wiki/1-Wire_Busverlegung#Belegung

ZitatDer war gut ... ;D
Sorry  FEHMPiDi, da musste ich aber auch schmunzeln.

Viele Grüße

R.