1-wire DS18B20 negative Temperaturen

[hol]

Hallo,

über ein Jahr schon messen hier ein Paar Temperatursensoren DS18B20 zuverlässig. Sie sind auf einen Pi3 auf GPIO verdrahtet.
Bei den negativen Außentemperaturen jetzt, werden statt -9,125°C, 4085,875 °C angezeigt. Dies entspricht dem Wert aus der /sys/bus/w1/devices/28-xxx/temperature, mit korrigiertem Komma.
Nach dem Datenblatt von TI ist dieser Wert logisch. Die unteren vier Bit repräsentieren die Nachkommastellen. Wen man die von dem Wert in ,,temperature" abzieht bleibt 4085 (hex FF5) und das sind dann laut Tabelle -9°C.

https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf

Komischer Weise hat die Berechnung schon mal richtig funktioniert. In einer Logdatei von März 2020 habe ich -6°C. Verglichen mit einem Backup, ist  die Definition der Sensoren im FHEM nicht geändert worden.

Für FHEM erfolgt die Berechnung offenbar in der 58_GPIO4.pm, in der ,, sub GPIO4_Get($)".
In der Zeile ,,my $temp = $1/1000.0;" wird das Komma gesetzt. Eine Umrechnung wie ,,wenn Wert > 125 dann (Wert = Wert-4095)" vermisse ich. Auch hier wurde seit März keine Änderung vorgenommen.

Ich konnte mir erstmal mit einem userReading behelfen, auch wenn meine Programmierkentnisse sehr bescheiden sind. Dank der super Doku zu FHEM war es mir doch möglich .

Code Auswählen Erweitern

attr TempAussen userReadings temperature {if (ReadingsVal("TempAussen","temperature","")>=125) {return (sprintf("%.2f",ReadingsVal("TempAussen","temperature","")-4095))} else {return (sprintf("%.2f",ReadingsVal("TempAussen","temperature","")))}}

Ich wüsste jetzt zu gern was ich falsch mache oder ob sich seit März mit irgendeinem Update etwas geändert hat.


Vielen Dank
Holger

[KölnSolar]

Hallo Holger,
willkommen im Forum.

ob sich seit März mit irgendeinem Update etwas geändert hat

Nein, da es gar nicht offiziell ist, also nur eine eher ältere Version in fhem/contrib. Such mal, dann findest Du eine aktuellere im Forum.

Schon komisch Dein Fehler. Negative Temp funktionieren bei meinen 4 Aussensensoren problemlos.

Vielleicht ein physikalisches Problem. Gibt ja einige Berichte über Fehler bei China-Klone.

Zur einfacheren Korrektur müsste attr tempOffset funktionieren.

Grüße Markus

[hol]

Hallo Marcus,

vielen Dank für Deine Antwort.

Das mit dem China-Klone kann ich nicht ausschließen, aber der negative Wert entspricht den Angaben von TI. Die haben das Original entwickelt.
Kannst Du mal bitte nach sehen welcher Wert bei Dir in der /sys/bus/w1/devices/28-xxx/temperature steht wenn negative Temperaturen angezeigt werden?
Das wäre eine große Hilfe!

Vielen Dank
Holger

[KölnSolar]

Hi Holger,

Code Auswählen Erweitern

9d ff ff ff 7f ff ff ff 77 t=-6187
oder

Code Auswählen Erweitern

b0 ff ff ff 7f ff ff ff a3 t=-5000

Meine letzte non-blocking-version gibt's hier

Grüße Markus

[hol]

Super Marcus, vielen Dank.
Bei mir sieht das so aus:

Code Auswählen Erweitern

6b ff 4b 46 7f ff 0c 10 c0 t=4086687


Damit liegt es eindeutig unterhalb von FHEM und ich muss wohl im Pi im System suchen was da vergeigt ist.

Vielen Dank
Holger

[KölnSolar]

Damit liegt es eindeutig unterhalb von FHEM

denk ich auch. Gib dem Sensor doch mal Wärme. Vielleicht bleibt er seltsam und

Bei den negativen Außentemperaturen jetzt

war eine Ursache für einen Defekt, nicht aber nachstellbares Fehlverhalten des Systems.
Grüße Markus

[hol]

Mit einem Fön war ich schon dran. Er verhält sich wie in der Tabelle des Herstellers beschrieben.


TEMPERATURE    DIGITAL OUTPUT      DIGITAL OUTPUT   
(°C)                        (BINARY)                 (HEX)
----------------------------------------------------------
+125      0000 0111 1101 0000    07D0h
+85*       0000 0101 0101 0000    0550h
+25.0625   0000 0001 1001 0001    0191h
+10.125    0000 0000 1010 0010    00A2h
+0.5    0000 0000 0000 1000    0008h
0       0000 0000 0000 0000    0000h
-0.5       1111 1111 1111 1000    FFF8h
-10.125    1111 1111 0101 1110    FF5Eh
-25.0625    1111 1110 0110 1111    FE6Fh
-55       1111 1100 1001 0000    FC90h

Am Sensor liegt es nicht. Die Formatierung des dezimalen Wertes stimmt nicht.
Dank dem Temperatur.log kann ich genau sehen ab wann der Fehler auftrat. Ich hatte kurz zuvor einen neuen Zigbee-Stick (CC2652) in betrieb genommen.
Seit dem anschließenden Reboot ist die Formatierung des Dezimalwertes hin.
Die Log-Dateien in /var/log/*.* bin ich durch. Da finde keinen Hinweis. Die syslog.gz wird ja leider nach 8-Tagen gelöscht. Die hätte vielleicht noch geholfen.
Vom FHEM mache ich gelegentlich ein backup. Vom OS zu selten. Das rächt sich hier. Ich muss wohl neu aufsetzen.
Vielen Dank Markus

Holger

[Wzut]

,,wenn Wert > 125 dann (Wert = Wert-4095)"

Warum "nur" > 125 es geht doch um das höchste gesetzte Bit (2^7 = 128) , d.h. > 127
und ich ziehe auch nicht "nur" 4095 ab sondern (2^12) = 4096   

Code Auswählen Erweitern

sprintf('%1.f', ( hex('FC90') / 16 ) - 4096 ) = -55

[hol]

die ">125" habe ich gewählt, da der Bereich des Sensors mit -55 bis +125 angegeben ist.
Die 4095 resultieren aus den oberen drei Nibbel, die die Stellen vor dem Komma repäsentieren. Binär 1111 1111 1111, oder hex ff f entspricht 4095. Ich hoffe, ich hab da keinen Denkfehler.

[KölnSolar]

Hi Holger,

Ich hoffe, ich hab da keinen Denkfehler

Doch hast Du. Mich haben die Negativtemperaturen auch seit gestern erwischt.  Grund ist mein Systemupdate vom 28.2.

Beispiele von heute früh

Code Auswählen Erweitern

fe ff ff ff 7f ff ff ff 53 : crc=53 YES
fe ff ff ff 7f ff ff ff 53 t=4095875

00 00 ff ff 7f ff ff ff cb : crc=cb YES
00 00 ff ff 7f ff ff ff cb t=0

der erste Wert korrigiert: 4095875 - 4096000 = - 125    Temp: =-0,125

Ich bau das gleich mal im GPIO4-Thread(Einplatinencomputer) ein.

Grüße Markus