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 (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 :-).
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
Hallo Holger,
willkommen im Forum.
Zitatob 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
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
Hi Holger,
9d ff ff ff 7f ff ff ff 77 t=-6187
oder
b0 ff ff ff 7f ff ff ff a3 t=-5000
Meine letzte non-blocking-version gibt's hier (https://forum.fhem.de/index.php/topic,11142.msg1121527.html#msg1121527)
Grüße Markus
Super Marcus, vielen Dank.
Bei mir sieht das so aus:
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
ZitatDamit liegt es eindeutig unterhalb von FHEM
denk ich auch. Gib dem Sensor doch mal Wärme. Vielleicht bleibt er seltsam und
ZitatBei den negativen Außentemperaturen jetzt
war eine Ursache für einen Defekt, nicht aber nachstellbares Fehlverhalten des Systems.
Grüße Markus
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
Zitat von: hol am 12 Februar 2021, 20:56:04
,,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
sprintf('%1.f', ( hex('FC90') / 16 ) - 4096 ) = -55
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.
Hi Holger,
ZitatIch 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
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=0der erste Wert korrigiert: 4095875 - 4096000 = - 125 Temp: =-0,125
Ich bau das gleich mal im GPIO4-Thread(Einplatinencomputer) ein.
Grüße Markus