Hallo Leute,
ich habe in kleines Problem mit folgendem Aufbau:
Hardware:
ESP8266 (Sonoff POW) + DS18B20 mit ca. 1m Kabel und 4.7k Pullup an GPIO3
(RXD, 3.3V, GND)
Software:
Tasmota (5.13.1a)
Problem:
Der Sensor zeigt nach dem Booten des ESP8266 etwa 2,5 Grad zu viel an
(reproduzierbar).
Nach ca. 4 Betriebsstunden sind es 2 Grad zu wenig!
Wir der gleiche Sensor an ein Pollin Net-io angeschlossen stimmt die
Temperatur exakt !!!
Nutze ich einen "nackten" ESP8266 mit folgenden Arduino Script tritt der
gleiche Messfehler auf.
Ein "nackter" AVR auf dem Breadboard, programmiert mit BASCOM misst
ebenfalls richtig!
Dabei ist es völlig egal ob der "alte" Sensor oder ein frisch
ausgepackter angeschlossen wird.
Kann mir das mal Jemand erklären ???
Danke schonmal
Michael
Egal ob TO92 oder in Metallhülse, der Fehler bleibt der gleiche. Auch
wenn ich alle 5 Minuten manuell eine Messung anstoße ...
Der Sensor hängt im Pool, die ganze Zeit war ein Net-io dran (Ethersex
Firmware), da lief der Sensor seit vorletzten Jahr völlig problemlos,
auch durch die Winter hinweg.
Michael schrieb:> Kann mir das mal Jemand erklären ???
Ich versuche es mal mit Fragen:
Die Prüfsumme des DS1B20 wird richtig empfangen?
Die Versorgung des DS18B20 erfolgt extern/parasitär?
Die Versorgungsspannung ist stabil, insbesondere während des Strompeaks
des ESP8266?
Die Stromversorgung erfolgt vom Sonoff bzw. Labornetzteil, nicht
parasitär.
Mit dem Oszi kann ich keine Auffälligkeiten bei der Stromversorgung
erkennen, auch nicht wenn der Esp mal etwas mehr zieht.
Ob die Prüfsumme bei der Tasmota Firmware korrekt ist kann ich nicht
sagen. Bei den AVRs (Bascom) passt alles und auch die Temperatur.
Es sind auch alle Arduino libs für den Esp auf dem neuesten Stand.
In meinem Bascom Programm Standard mit 12 Bit und ~750ms.
Bei Tasmota und der Standard-Arduino-Lib auch mit 12 Bit und ~750ms.
Ist ja nicht mein erstes Mal mit diesen Sensoren ...
Mein Problem ist ja nur dass der ESP8266 mit einem DS18B20 falsche
Temperaturen misst.
> Ist ja nicht mein erstes Mal mit diesen Sensoren ...
Dann schau Dir doch einfach mal hüben und drüben die Rohdaten an, damit
kannst Du extrem einfach entscheiden ob der Fehler in der Hardware oder
in der Software liegt.
Michael schrieb:> In meinem Bascom Programm Standard mit 12 Bit und ~750ms.>> Bei Tasmota und der Standard-Arduino-Lib auch mit 12 Bit und ~750ms.>>> Ist ja nicht mein erstes Mal mit diesen Sensoren ...> Mein Problem ist ja nur dass der ESP8266 mit einem DS18B20 falsche> Temperaturen misst.
Und meine These ist, das der ESP8266 den Sensor anders konfigriert, als
die anderen Boards, das Problem also nicht am sensor liegt sondern am
Steuerprogramm. Welche Konfig werte beeinflussen noch die ausgegebene
Temperatur? Muss erst irgend eine Kalbrieroutine gestartet werden?
Ich würde auch die Werte jetzt nicht als komplett "falsch" bezeichnen
sondern als "mit deutlich geringer Genauigkeit". Das kann auf
Unterschiede bei der Initialisierung rückführbar sein. Am besten mal
alle Register auslesen und deren Inhalte vergleichen.
Vielleicht liegt ja das Problem an den verwenden typen und bei der 12(?)
bit zu float Umwandlung wird sehr grosszügig gerundet. Wäre nicht das
erste mal, das der Sensor richtig misst aber bei der Formatierung der
Anzeige passiert Marks. Oder der Klassiker; 1/x ist nicht das gleiche
wie 1.0/x.
T-Fühler schrieb:> Vielleicht liegt ja das Problem an den verwenden typen und bei der 12(?)> bit zu float Umwandlung wird sehr grosszügig gerundet. Wäre nicht das> erste mal, das der Sensor richtig misst aber bei der Formatierung der> Anzeige passiert Marks. Oder der Klassiker; 1/x ist nicht das gleiche> wie 1.0/x.
Ich glaube da liegt der Hund begraben ...
Tasmota rechnet so:
t = ConvertTemp(sign temp12 0.0625);
t (float)
ConvertTemp (rechnet bei Bedarf in Fahrenheit um)
sign (Vorzeichen)
temp12 (12 Bit Wert vom Sensor)
Ich habe das jetzt mal wie folgt geändert:
t = sign * temp12;
t = t / 16;
Nun zeigt mir der Sonoff auf der Weboberfläche 17.12 statt 15.10 Grad.
Werde gleich mal mit dem analogen Thermometer nachmessen.
Sieht nach Software Fehler aus. Im 12-bit modus braucht der Sensor 750ms
bis das Ergebnis der Messung im scatchpad steht. Holst du die Daten dort
früher ab bekommst du das Ergebnis der vorherigen Messung oder auch
Mist.
Nach einem Reset oder Power_On (ohne einen Messbefehl) steht im
scratchpad
+85°C als ein Testwert des Sensors. Das hilft vielleicht bei der
Fehlersuche.
Michael schrieb:> Ich habe das jetzt mal wie folgt geändert:> t = sign * temp12;> t = t / 16;
NB: Mir kam die Methode, das Zweierkomplement des Sensors zunächst in
sign/magnitude umzurechnen, um es anschliessend zusammen zu
multiplizieren, anfangs etwas umständlich vor:
1
int8_tsign=1;
2
uint16_ttemp12=(data[1]<<8)+data[0];
3
if(temp12>2047){
4
temp12=(~temp12)+1;
5
sign=-1;
6
}
Aber eines muss man diesem Code lassen. Er funktioniert völlig konform
zum C Standard, selbst dann, wenn die Hardware Integers im dafür m.W.
längst ausgestorbenen Einerkomplement darstellt. Respekt. Andernfalls
erhält man mit
1
int16_ttemp12=(data[1]<<8)+data[0];
bereits Sechzehntel mitsamt Vorzeichen.
Negativ fällt dann aber doch auf, dass bei
1
int8_tsign=...
2
uint16_ttemp12=...
3
...
4
...sign*temp12*0.0625...
die Teilrechnung sign * temp12 auf einem 16-Bitter sinnigerweise ohne
Vorzeichen stattfindet, weil
int8_t * uint16_t => int * unsigned => unsigned * unsigned
während es auf einem 32-Bitter wie dem ESP8266 zu
int8_t * uint16_t => int * int
wird. Besser wäre beispielsweise
Nach diversen Experimenten mit unterschiedlichen Boards (Arduinoi Pro
Mini und ESP8266), unterschiedlichen Bibliotheken, unterschiedlichen
Stromversorgungen (Schatnetzteile, Batterien, Stützkondensatoren) und
einem Versuchsaufbau mit 1 bis 5 daran angeschlossenen DS18B20 habe ich
zuletzt folgenden Effekt reprodzieren können:
Ist der DS18B20 nahe am ESP8266 angeschlossen, dann wird eine um zirka 1
bis 2 Kelvin zu hohe Raumtemperatur angezeigt.
Schliesst man dagegen den DS18B20 mit einem mindestens zirka 30 cm
langen Kabel am ESP8266 an, dann bekommt man eine einwandfreie
Temperatur-Anzeige.
Claus K. schrieb:> Ist der DS18B20 nahe am ESP8266 angeschlossen, dann wird eine um zirka 1> bis 2 Kelvin zu hohe Raumtemperatur angezeigt.
Und du meinst nicht, dass der ESP8266 durch seine Stromaufnahme wirklich
wärmer als die Umgebung sein könnte?
Wie verhinderst du, dass Wärmeleistung über die Anschlussbeine zum
DS18B20 fließt?
Ich hatte exakt die selben Probleme. Mein Aufbau war:
ESP8266/ESP32(espeasy) <-> DS18B20. Dabei lag die Temperatur immer
1..2°C daneben. Nach gefühlt Wochen des Suchens in der Firmware bin ich
darauf gekommen, dass die Einstrahlungen des WLANs vom ESP in den
DS18B20 zu den falschen Temperaturen geführt haben. Ich habe die
Sensoren dann an 1,5m Kabel (nicht prarasitär) etwas vom ESP entfernt
messen lassen. Und siehe da: kein Temperatur-Offsets mehr.
Claus K. schrieb:> Ist der DS18B20 nahe am ESP8266 angeschlossen, dann wird eine um zirka 1> bis 2 Kelvin zu hohe Raumtemperatur angezeigt.> Schliesst man dagegen den DS18B20 mit einem mindestens zirka 30 cm> langen Kabel am ESP8266 an, dann bekommt man eine einwandfreie> Temperatur-Anzeige.
Ich schätze dein DS18B20 wird sich etwas HF vom ESP8266 WLAN einfangen,
und dadurch gestört werden.
Ursache ist sicherlich eine EMV-Einstrahlung (keine thermische). Auch
ich hatte zunächst das WLAN/WiFi im Verdacht, was sich allerdings durch
Messungen mit versuchsweisem Aus- und Wiedereinschalten nicht bestätigte
(siehe die Ergebnisse ab 17:00 und 18:40 Uhr im beigefügten
Messprotokoll). Somit ist liegt es wohl am Prozessor selbst, der ja im
Vergleich z.B. zu einem Arduino Mini Pro mit deutlich höherer
Taktfrequenz und Leistungsaufnahme arbeitet. So oder so: Abstand schafft
Abhilfe.
Dabei muss es nicht unbedingt ein Kabel sein (insofern korrigiere ich
meinen ersten Beitrag); etwas mehr Abstand auf der Platine tut's auch
(siehe Pos. 3 im beigefügten Foto).
Solche Messungen IMMER in einer 10er Schleife mit Abfragen alle 3
Sekunden.
Dann den Mittelwert berechnen.
Wert = 0
for i = 1 to 10
wert = wert + abfrage_sensor()
next i
Ergebnis = wert / 10
Diese Sensoren neigen meiner Meinung nach zu Toleranzmessungen. Die
Mittelwertbildung korrigiert das aber brauchbar.
Schlaumaier schrieb:> Diese Sensoren neigen meiner Meinung nach zu Toleranzmessungen. Die> Mittelwertbildung korrigiert das aber brauchbar.
Kann ich nicht bestätigen. Ich habe die an einem Warmwasserspeicher und
die Abkühlungskurve zeigt kein Rauschen. Nur wenn es über die
Auflösungspunkte geht kippelt der ein wenig, dann wieder "flat line"
Die Sensoren sind mit 5V versorgt, alles drahtgebunden, kein Wlan.
Messung 1x pro Minute, eine Messung.
Claus K. schrieb:> Ursache ist sicherlich eine EMV-Einstrahlung (keine thermische).
soso, klingt wie LCD-Display . . .
Schon mal überlegt, wofür die Abkürzung EMV steht?
Falk B. schrieb:> Claus K. schrieb:>> Ursache ist sicherlich eine EMV-Einstrahlung (keine thermische).>> soso, klingt wie LCD-Display . . .>> Schon mal überlegt, wofür die Abkürzung EMV steht?
Laut Wikipedia ...
"Elektromagnetische Verträglichkeit (EMV) bezeichnet die Fähigkeit eines
technischen Geräts, andere Geräte nicht durch ungewollte elektrische
oder elektromagnetische Effekte zu stören oder durch andere Geräte
gestört zu werden."
... sind aber beide Richtungen betroffen: Einstahlung und Abstrahlung.
Insofern ist die Einschränkung auf "Einstrahlung" durchaus sinnvoll und
entspricht nicht dem "LCD-Display"-Problem...
Vielleicht ist auch nur der Sensor defekt.
Schon mal mit einen anderen Sensor versucht. ?? Bei so Sachen teste ich
immer mit 2-3 Sensoren.
Besonders seit ich mal 4 Std. an einen Problem gehangen habe, weil ich
gedacht habe die Chinesen können Platinen richtig beschriften.
Naja, es gibt bekannte Probleme mit den ESP8266. Oder es liegt ein
Problem in der Software vor.
Ich würde mal den Treiber wechseln. Eine Github-Libs nehmen und das Teil
mit einer fertigen Testsoftware füttern. Vielleicht liegt ja einfach nur
ein Rechenfehler in der Libary vor. Keine Ahnung.
Oder er hat eine Arduino-Libary für einen ESP benutzt. Da sind
Unterschiede. Jedenfalls muss ich bei meinen Entwicklungssystem darauf
achten die modifizierte Libs für den ESP zu nehmen.
Mir reicht übrigens die ONEWIRE Libs. völlig aus zum auslesen des Pins.
De Rest berechne ich selbst.
Ganz allgemein gesehen mag es sicherlich zutreffen, dass falsche
Treiber, falsche sketches, falsche Libraries, Fehler in der
Floating-Point-Mathematik und defekte Sensoren zu Problemen mit
Temperaturmessungen führen könnTen.
Im speziell hier beschriebenen und dokumentierten Fall bleibt für mich
nach wie vor nur die These, dass irgendeine HF den Sensor stört.
Die Vermutung, es könne das WLAN sein, hatte ich bereits neulich
untersucht.
Die Vermutung, es könne das LCD sein, habe ich heute untersucht: Ein
Abklemmen des LCD bewirkt (leider) ebenfalls keine Änderung am
beschriebenen Phänomen. Somit tippe ich weiterhin auf die 80 MHz.
Für diejenigen, die einfach nur ein erprobtes Kochrezept zur Lösung des
in diesem Thread zur Rede stehenden Problems suchen (wobei der TE ja um
2 K zu niedrige Temperaturen beklagte, während sie bei mir um 2 K zu
hoch sind), bleibt es dabei: Montiert Euren DS18B20 nicht zu nahe am
ESP8266.
An diejenigen, die mir Tipps geben wollen, hätte ich den Wunsch: Schaut
Euch vorher bitte genau die beschrifteten Fotos von vor einigen Tagen
sowie den beigefügten Dump von heute an und diskutiert danach auf Basis
dessen, was daraus offensichtlich hervorgeht. "Er" hat ja hiermit
immerhin auch jede Menge einwandfreie Ergebnisse erzielt.
Claus K. schrieb:> An diejenigen, die mir Tipps geben wollen
Bist du beim Aufbau mit Kabel auch Mal in die Nähe des ESP gegangen?
Dann müsstest du ja live sehen wie die Temperatur bei Annäherung
schlecht wird...
Für mich hört sich es so an als wäre eine Lib fehlerhaft! Irgendwo ein
Shift falsch und deshalb zeigt er einen falschen Wert an bei dem einen
uC und beim Anderen ist alles IO weil dort ein anderer Sourcecode
verwendet wird..
Aschom schrieb:> Für mich hört sich es so an als wäre eine Lib fehlerhaft! Irgendwo ein> Shift falsch und deshalb zeigt er einen falschen Wert an bei dem einen> uC und beim Anderen ist alles IO weil dort ein anderer Sourcecode> verwendet wird..
Das kommt vom absolut hörigen Benutzen irgendeiner lib. Man sollte
wenigstens mal in der Lage sein, die 1Wire Kommunikation mit einem LA zu
betrachten und mal die Kommandos und die Rohdaten anzusehen und zu
schauen was der Sensor wirklich liefert. Einfach hirntot eine lib nutzen
und dann beten dass das Ergebnis schon irgendwie stimmen wird bringts
halt nicht.
Wer in das Datenblatt dieser Sensoren schaut, sieht dass man deren
Auflösung einstellen kann. Je nach Einstellung müssen die Rohdaten
anders umgerechnet werden. Da weiß man doch schon woher der Wind weht.
Ich will mal hoffen das du ein Widerstand in die Datenleitung getan
hast.
Hier ist eine sehr gute Anleitung.
https://randomnerdtutorials.com/esp8266-ds18b20-temperature-sensor-web-server-with-arduino-ide/
Ich persönlich habe meine mit den "dichten DS18b20" im 2 Bild den mit
Kabel, genau SO geschaltet und es hat funktioniert.
Allerdings muss ich zugeben, das ich wie immer b4x modifizierte Libs
benutzt habe.
In den Link gibt er auch genau an WELCHE ONEWIRE er benutzt. Die gibt es
nämlich zu haufe.
Aschom schrieb:> Für mich hört sich es so an als wäre eine Lib fehlerhaft! Irgendwo ein> Shift falsch und deshalb zeigt er einen falschen Wert an bei dem einen> uC und beim Anderen ist alles IO weil dort ein anderer Sourcecode> verwendet wird..
Dann ist aber komisch, dass mal die Temperatur richtig gemessen wird und
dann gibt es für geraume Zeit einen Sprung um 2K nur um danach wieder
korrekt gemessen zu werden. Das spricht IMO nicht für einen Fehler im
Code sondern für einen Störsender der das System nur sporadisch stört.
Ein falscher Shift müsste jede Messung verhauen, nicht nur ab und an mal
für zwei Stunden. ;)
M. K. schrieb:> Dann ist aber komisch
Wie meinst du das? "Haha"-Komisch oder "merkwürdig"-Komisch, wie die Art
von Leuten die "Like a Girl" von Ipanema auf Vollanschlag aufdrehen und
anschließen sämtliche Haushaltsgeräte der Größe nach sortiert aus dem
Fenster werfen um anschließend auf die Frage weshalb sie das tun mit:
"halten Sie mal bitte den Salzstreuer, mein Aquarium klingelt!" zu
antworten?
Bastler_HV schrieb:> Schlaumaier schrieb:>> Diese Sensoren neigen meiner Meinung nach zu Toleranzmessungen. Die>> Mittelwertbildung korrigiert das aber brauchbar.>> Kann ich nicht bestätigen. Ich habe die an einem Warmwasserspeicher und> die Abkühlungskurve zeigt kein Rauschen.
Genau.
hier eine Abkühlkurve aus meinem Beitrag:
Wolle G. schrieb:> Jetzt Bild 2Beitrag "DS18B20 Sensor"
N. M. schrieb:> Claus K. schrieb:>> An diejenigen, die mir Tipps geben wollen>> Bist du beim Aufbau mit Kabel auch Mal in die Nähe des ESP gegangen?> Dann müsstest du ja live sehen wie die Temperatur bei Annäherung> schlecht wird...
Ja, genau das habe ich getan.
Und ja, genau das war das Ergebnis.
Reproduzierbar und reversibel (d.h. es wird umgekehrt auch wieder gut).
Dazu unten ein Auszug aus meinem gestern hochgeladenen
Versuchsprotokoll.
Acht der neun darin gemeldeten Temperaturwerte sind einwandfrei.
Der um 06:27 Uhr vom Sensor (2) gemeldete um fast 3 K zu hohe Wert ist
die Reaktion auf die um 06:24 Uhr durchgeführte Maßnahme.
[Protokoll]
06:23:27.962 -> Start der Versuche mit 3 Sensoren, einer hat ein 30 cm
langes Kabel
06:23:27.962 -> 0) 289037E40C000086: Res=11 Temp=20.13øC
06:23:27.962 -> 1) 2846A8E50C0000A7: Res=11 Temp=20.13øC
06:23:28.009 -> 2) 28E343E40C000035: Res=11 Temp=20.13øC
06:24:38.893 -> Den Sensor mit Kabel nun oberhalb des Prozessors
platziert
06:27:27.966 -> 0) 289037E40C000086: Res=11 Temp=20.38øC
06:27:27.966 -> 1) 2846A8E50C0000A7: Res=11 Temp=20.38øC
06:27:28.013 -> 2) 28E343E40C000035: Res=11 Temp=23.25øC
06:36:56.809 -> Den Sensor mit Kabel nun wieder neben den anderen
beiden platziert
06:39:51.921 -> 0) 289037E40C000086: Res=11 Temp=21.63øC
06:39:51.968 -> 1) 2846A8E50C0000A7: Res=11 Temp=21.63øC
06:39:51.968 -> 2) 28E343E40C000035: Res=11 Temp=21.63øC
[/Protokoll]
Dietrich L. schrieb:> ... sind aber beide Richtungen betroffen: Einstahlung und Abstrahlung.> Insofern ist die Einschränkung auf "Einstrahlung" durchaus sinnvoll und> entspricht nicht dem "LCD-Display"-Problem...
So ein Schmarn.
EMV steht für "Elektromagnetische Verträglichkeit", was genau bedeutet,
dass es KEINE störende Beeinflussung gibt.
"EMV-Einstrahlung" ist wie ein SCHWARZER Schimmel.
Wolfgang schrieb:> "EMV-Einstrahlung" ist wie ein SCHWARZER Schimmel.
p.s.
Und selbst da krümmen sich einem noch sämtliche ...
EMV ist eine Eigenschaft, Einstrahlung eine Feldstärke,
Bestrahlungsstärke oder was auch immer.
Content B. schrieb:> Da schein wohl das WLAN des ESP reinzuballern
Nein, der Effekt tritt auch auf, wenn das WLAN/WiFi ausgeschaltet wird,
s.o. meinen Beitrag #6651083
Wolfgang schrieb:> "EMV-Einstrahlung" ist wie ein SCHWARZER Schimmel.
Ich wollte damit verdeutlichen, dass es sich (anders als in einem
Beitrag zuvor vermutet) höchstwahrscheinlich nicht um eine thermische,
sondern um eine elektromagnetische Beeinflussung handelt.
Wolfgang schrieb:> EMV steht für "Elektromagnetische Verträglichkeit", was genau bedeutet,> dass es KEINE störende Beeinflussung gibt.
Ich habe "EMV" als Abkürzung verwendet für das ganze Themengebiet,
welches sich mit dieser Frage befasst. Und nach meinem Verständnis
gehört auch eine elektromagnetische Un-Verträglichkeit (in der es dann
eben doch störende Beeinflussungen gibt) in diese Themengebiet.
Wolfgang schrieb:> Und selbst da krümmen sich einem noch sämtliche ...
Es tut mir leid, dass mein Beitrag nicht Dein Niveau erreicht hat.
W.A. schrieb:> Und du meinst nicht, dass der ESP8266 durch seine Stromaufnahme wirklich> wärmer als die Umgebung sein könnte?
Mittlerweile: Doch, Du könntest Recht haben.
Claus K. schrieb:> dass es sich ... höchstwahrscheinlich nicht um eine thermische,> sondern um eine elektromagnetische Beeinflussung handelt.
Nachtrag: Mittlerweile kommen mir Zweifel.
Habe heute mal einen kräftigen Lüfter zum Einsatz gebracht. Ohne Lüftung
zeigte der "Sensor oben" diesmal sogar bis zu 3 K zuviel an. Aber nach
15 Minuten mit Lüftung meldeten alle Sensoren brav dieselben
glaubwürdigen Temperaturwerte.
Bleibt für mich die Frage: Woher kommt das? Ich hätte nicht gedacht,
dass die vom Prozessor abgegebene Wärme sich in einem derart offenen
Versuchsaufbau (siehe die heute hochgeladene Skizze) so einflussreich
ausbreitet und fest setzt. Daher halte ich es immer noch für möglich,
dass auch HF aus dem Prozessor eventuell zu einer inneren Erwärmung im
Sensor führen könnte. Was meint Ihr?
Aschom schrieb:> M. K. schrieb:>>> Dann ist aber komisch>> Wie meinst du das? "Haha"-Komisch oder "merkwürdig"-Komisch, wie die Art> von Leuten die "Like a Girl" von Ipanema auf Vollanschlag aufdrehen und> anschließen sämtliche Haushaltsgeräte der Größe nach sortiert aus dem> Fenster werfen um anschließend auf die Frage weshalb sie das tun mit:> "halten Sie mal bitte den Salzstreuer, mein Aquarium klingelt!" zu> antworten?
Geklaut von Barlow
Claus K. schrieb:> Was meint Ihr?
Ist die Skizze Maßstabsgetreu? Dann könnte in der Tat die Erwärmung des
Prozessors daran schuld sein. Aber dass die vom Prozessor abgestrahlte
HF in den Sensor einkoppelt und da drinnen zu einer Erwärmung führt
halte ich schlicht für unmöglich. Die abgestrahlte HF dürfte unter 100
mW liegen. Ich glaube nicht, dass sie auch nur annähernd die Power hat
den Sensor signifikant zu erwärmen.