ESP32S mit DS18B20 Temp-Sensor

[Basti97]

Ich habe auch sehr viele (ca 50x) DS18b20 laufen bei mir alle mit 3.3V mit einem ESP in verschiedene Ausführungen immer mit Tasmota. Da der ESP bekanntlich nur 3.3V tolerant ist würde ich sie nie mit 5V betreiben. Kein Wunder warum es eventuell nicht mehr funktioniert oder der ESP kaputt geht.
Was halt wichtig ist ist der Pullup Widerstand der bei größerer Anzahl/ Leitungslänge verändert werden muss. Zu 99% liegt es immer an den Nutzer selbst

[Basti97]

@bahnuhr Ich auch sind vom Preis perfekt meistens löte ich sie aber auch selbst drauf bzw mit Kabel bisher hatte ich noch nie ausfälle gehabt.

[skvarel]

@basti97 sagte in ESP32S mit DS18B20 Temp-Sensor:

Ich habe auch sehr viele (ca 50x) DS18b20 laufen bei mir alle mit 3.3V mit einem ESP in verschiedene Ausführungen immer mit Tasmota. Da der ESP bekanntlich nur 3.3V tolerant ist würde ich sie nie mit 5V betreiben. Kein Wunder warum es eventuell nicht mehr funktioniert oder der ESP kaputt geht.
Was halt wichtig ist ist der Pullup Widerstand der bei größerer Anzahl/ Leitungslänge verändert werden muss. Zu 99% liegt es immer an den Nutzer selbst

Man kann ohne Probleme den ESP mit 3.3v und den DS18B20 mit 5v betreiben. Das mache ich seit Jahren so. Man muss den ESP ja nicht mit 5v befeuern

[MartinP]

@basti97 sagte in ESP32S mit DS18B20 Temp-Sensor:

Da der ESP bekanntlich nur 3.3V tolerant ist würde ich sie nie mit 5V betreiben. Kein Wunder warum es eventuell nicht mehr funktioniert oder der ESP kaputt geht

Naja, ich habe natürlich den Pull-Up an 3,3 Volt gehängt.
So sollte der DataPin des DS18B20 immer im erlaubten Spannungsfenster bleiben

[senior1418]

@skvarel

von diesen habe ich auch 5 Stück lange im Einsatz. Dazu noch weitaus länger 2x 5 Stück angelötete Sensoren für Fußbodenheizung.
Der Aufbau war eigentlich Prototype, funktionierte aber und ist somit geblieben.
Verwende zur Temperaturmessung bisher Wemos D1 Mini und ESP Easy.

[MartinP]

@senior1418 Die Schaltung scheint mir Merkwürdig: Der 4,7 kOhm Widerstand an gnd?

[senior1418]

@martinp

[senior1418]

@martinp sagte in ESP32S mit DS18B20 Temp-Sensor:

Die Schaltung scheint mir Merkwürdig: Der 4,7 kOhm Widerstand an gnd?

ja - habe ebene auch hin und her überlegt ob ich das so zu zeigen soll. Letztendlich ist der Deckel dort schon 3 Jahre drauf und misst zuverlässig.

[senior1418]

@senior1418 ok - nun doch mal nach den Schank verschoben. 4,7kOhm steckt zwischen 5V und 1Wire. Das geht leider aus dem Bild nicht wirklich hervor

[MartinP]

@senior1418 ja, wenn man das Bild ganz weit aufzieht, sieht man auch auf dem Foto, dass der Draht an gelben Ring nicht am Masse "Bus" eingesteckt ist.

[skvarel]

@senior1418 ... mittlerweile bin ich von ESP auf CC2531 (Zigbee) umgestiegen

Man benötigt auch keinen externen Widerstand, weil der CC2531 alles onBoard hat.

Die DS18B20 habe ich direkt an 5v und GND vom USB angelötet. Data dann auf die GPIOs vom SS2531.

Mir gefällt Zigbee einfach besser.

Hier ein Beispiel von meinem Vor- und Rücklauf der Heizung (klappt auch mit dem Zigbee-Adapter=:

[MartinP]

@skvarel naja, der ESP32 macht schon etwas mehr.
Schaltventil ansteuern
PWM für die Lüfter unter dem Heizkörper
Temperatursensoren
Fensterkontakt
Regelalgorithmus

Der Aufbau sollte im Notfall auch autark funktionieren.
Nur Nachtabsenkung/Solltemperatur und Auswertung wickelt Iobroker ab.

Ich finde aber das Konzept mit den altbackenen Zigbee Chips durchaus interessant, und inzwischen habe ich auch mehr Vertrauen in den Iobroker, sodass ich weniger Vorbehalte habe, die Regelung per Javascript machen zu lassen...

[skvarel]

@martinp .. die Zigbee-Chips können auch mehr, also nicht weniger als der ESP.

Ich habe mein Gewächshaus damit etwas smarter gemacht.

1x Luftfeuchtigkeit und Temperatur
1x Bodentemperatur
2x Bodenfeuchtigkeit
2x Reed für Fenster und Tür
2x Relais für Licht und Heizung

Alles an einem CC2530. Ja, nicht ganz autark, es braucht schon eine zusätzliche Software. In meinem Fall, Zigbee2mqtt ... würde also auch ohne ioBroker funktionieren.

Das ist aber ein anderes Thema. Hier geht es ja um einen ESP32. Ich will das Thema hier nicht mit meinem Zigbee vollmüllen.

[MartinP]

@skvarel sagte in ESP32S mit DS18B20 Temp-Sensor:

Alles an einem CC2530. Ja, nicht ganz autark, es braucht schon eine zusätzliche Software. In meinem Fall, Zigbee2mqtt ... würde also auch ohne ioBroker funktionieren.
Das ist aber ein anderes Thema. Hier geht es ja um einen ESP32. Ich will das Thema hier nicht mit meinem Zigbee vollmüllen.

Als Threadersteller sollte man das Recht haben, abzuschweifen

Kannst Du z.B. Sensoren mit Software, die auf dem CC2530 läuft autark mit den Aktoren verknüpfen?

z. B. Lufttemperatur unter Schwellwert -> Heizung anschalten?

Das war meine Motivation, einen Chip zu nehmen, dem so etwas aufprogrammiert werden kann...

Ich bin eher C/C++ Spezialist, und habe das auf dem ESP deshalb mit der Arduino IDE gemacht. Alternative wäre z.B.Tasmota, und ein Script, was auf dem Board läuft...
Dann würde der Thermostat auch bei Ausfall des WLAN oder des iobroker völlig autark mit der letzten eingestellten Solltemperatur weiter regeln.

Vorbesetzt nach dem Neustart ist die Tag-Soll-Temperatur. Falls der Ausfall Nachts erfolgt, kann man das Board also kurz resetten, und dann ist die Tagtemperatur eingestellt...

Zurück zum Thema des Threads ... Gestern habe ich die Firmware aktualisieren wollen, um den Fehler weiter einzugrenzen (fällt immer ein bestimmter Sensor aus?)
Dabei habe ich die Arduino-IDE und alle Libraries und Boards in der IDE aktualisiert.
Danach den letzten Stand der Firmware einmal durchgebaut und hochgeladen.
Boot-Schleife ....

11:19:07.396 -> *** SETUP ***
11:19:07.428 -> INFO: MqttName TestThern
11:19:07.428 -> WARN: No Debug setting found in preferences
11:19:07.428 -> Client TestThern Connecting to Wi-Fi...(SSID gelöscht)
11:19:07.524 -> Locating devices...Found 0 devices.
11:19:07.524 ->  swap devices ....
11:19:13.781 -> Connected to Wi-Fi -  Signal strength:-71
11:19:13.781 -> Connecting to MQTT...
11:19:13.781 -> 
11:19:13.781 -> assert failed: tcp_alloc /IDF/components/lwip/lwip/src/core/tcp.c:1851 (Required to lock TCPIP core functionality!)
11:19:13.781 -> 
11:19:13.781 -> 
11:19:13.781 -> Backtrace: 0x40082881:0x3ffb5260 0x4008c689:0x3ffb5280 0x40092ada:0x3ffb52a0 0x400f3313:0x3ffb53d0 0x400f3489:0x3ffb53f0 0x400dad5b:0x3ffb5410 0x400d2fac:0x3ffb5460 0x400d3247:0x3ffb54a0 0x400d3273:0x3ffb54c0 0x400d29b5:0x3ffb54e0 0x400d8099:0x3ffb55c0 0x400d80b5:0x3ffb56a0 0x4008d3d2:0x3ffb56c0

Tante Google hat geholfen...

https://github.com/me-no-dev/ESPAsyncWebServer/issues/1455

Downgrade der ESP32 Board Library auf 3.0.7 und der Code läuft wieder....

Das hat mir einen gehörigen Schreck bereitet, da ich ohne Netz und doppelten Boden direkt mit dem Modul im Thermostaten gearbeitet habe ...

Habe mir vorgenommen, solche Tests demnächst nur noch mit Boards aus dem Ersatzellager-Karton zu machen

RoelHermus created this issue in me-no-dev/ESPAsyncWebServer

open Required to lock TCPIP core functionality! #1455

[MartinP]

Update:
Ich habe inzwischen die Firmware des Thermostaten überarbeitet und erweitert...
Aus Bequemlichkeitsgründen habe ich ein Logging einfach über einen MQTT String Datenpunkt den der Thermostat nun liefert realisiert. in iobroker gibt es ein Blockly script, was die eine Zeile Logmessage in das Iobroker-Logging transferiert, wo die Logmessages dann sehr einfach mit Bordmitteln auszulesen sind ...

2025-03-12 12:27:35.542  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) lost
2025-03-12 12:27:45.538  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) regained
2025-03-12 12:30:05.541  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) lost
2025-03-12 12:30:15.530  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) regained
2025-03-12 12:30:25.533  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) lost
2025-03-12 12:30:35.537  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) regained
2025-03-12 12:32:35.529  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) lost
2025-03-12 12:33:05.526  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) regained
2025-03-12 12:33:35.547  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) lost
2025-03-12 12:34:25.522  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) regained
2025-03-12 12:34:45.521  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) lost
2025-03-12 12:34:55.522  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) regained
2025-03-12 12:35:45.519  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) lost
2025-03-12 12:36:05.518  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) regained
2025-03-12 12:37:35.514  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) lost
2025-03-12 12:38:25.512  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) regained
2025-03-12 13:42:15.341  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) lost
2025-03-12 13:47:05.339  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) regained
2025-03-12 15:14:05.110  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) lost
2025-03-12 15:18:25.089  - info: javascript.0 (299058) script.js.Geräteüberwachung: Thermosensensor[1] (3C1E0457CBD0/28) regained

Es kristallisiert sich wohl immer mehr heraus, dass der zweite Thermosensor mit der Seriennummer 3C1E0457CBD0 möglicherweise einen Hardwaredefekt hat... immer wieder fällt dieser kurz aus (lost) ... wird aber sehr häufig direkt im folgenden Loop-Zyklus wieder gefunden (10 Sekunden Durchlauf), manchmal dauert es aber mehrere Zyklen...

Update 2: 13-MÄRZ-2025

Es sind definitiv alle Sensoren betroffen - wenn auch in unterschiedlichem Maße..

martin@iobroker-test-sicher:/opt/iobroker/log$ cat *.log  |grep -c "Thermosensensor[0"
16
martin@iobroker-test-sicher:/opt/iobroker/log$ cat *.log  |grep -c "Thermosensensor[1"
288
martin@iobroker-test-sicher:/opt/iobroker/log$ cat *.log  |grep -c "Thermosensensor[2"
8
martin@iobroker-test-sicher:/opt/iobroker/log$ 

Offtopic - lustiger Tippfehler "Thermosensensor"

Kann natürlich immer noch sein, dass der Sensor 1 in der Zeit, wenn er ausfällt den 1Wire Bus blockiert, und daduch die anderen Sensoren blockiert.

[MartinP]

Neue Wasserstandsmeldung

Inzwischen gibt es einen Grafana-Plot für die Sensoren ... Habe extra noch einmal die Firmware angefasst, für zwei Bool-Datenpunkte, um den Status Errechbar/nicht erreichbar jedes Sensors wiederzugeben.

Habe dies über DS18B20 Clones gefunden.
https://github.com/cpetrich/counterfeit_DS18B20

Meine Codierung des Empfangenen scheint nicht dem zu entsprechen, was die meisten Arduino Programmierer voneinander abschreiben

      written = snprintf (pBuff,19,", %02X%02X%02X%02X%02X%02X/%02X", 
        // statDeviceAddress[DevIdx][7], <- skipped, CRC
        statDeviceAddress[DevIdx][6], // <- MSByte of serial number
        statDeviceAddress[DevIdx][5],
        statDeviceAddress[DevIdx][4],
        statDeviceAddress[DevIdx][3],
        statDeviceAddress[DevIdx][2], 
        statDeviceAddress[DevIdx][1], // <- LSByte of serial number
        statDeviceAddress[DevIdx][0]); // <- family code set to 0x28

Bei den meisten Programmierern wird einfach die Reihenfolge andersherum ausgegeben... scheint mir aber nicht zu stimmen.

Jedenfalls sind die Experten der Meinung, dass ....

If the ROM does not follow the pattern 28-xx-xx-xx-xx-00-00-xx then the DS18B20 sensor is a clone

Quelle https://github.com/cpetrich/counterfeit_DS18B20

Meine drei Sensoren melden sich mit... (nach obiger Sortierung)
3C13E381F66D
3C1E0457CBD0
3C610457DB22

Das könnten nach dem Github-Artikel diese sein...

Family D2: Interesting, No Parasitic Power Da gibt es drei Chips, die 3C als Byte direkt neben der CRC haben.

[MartinP]

Interessante Aussage in einer der Funde auf meiner Suche nach Ursachen meiner Probleme:

https://github.com/cpetrich/counterfeit_DS18B20

Above is an example of an authentic, Maxim-produced DS18B20 sensor in TO-92 case.
As of writing (2019), the topmark of original Maxim chips is lasered rather than printed.
The first two rows, DALLAS 18B20, specify that this part is a DS18B20 (Dallas Semiconductor being the original producer), parasitic power-only chips bear the maring DALLAS 18B20P.
The + in the 4th row indicates that the part is RoHS compliant ([1]).

Es gibt also anscheinend Varianten, die AUSSCHLIESSLICH für Parasitäre Versorgung ausgelegt sind!