[Gelöst] ESP32S mit DS18B20 Temp-Sensor

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!

MartinP

habe es doch geschafft, den Code wieder auf Grundlage der aktuellen Arduino IDE mit aktuellen Bibliotheken zum Laufen zu bringen, AsyncTCP ist nun eine andere

Vorher war die Obere installiert, jetzt die Untere.
Ziemliches Minenfeld diese Entwicklungsumgebung ...

Leider hat es bezüglich der Stabilität der Anbindung der Temperatursensoren keine Verbesserung gegeben..

Es ist eher wieder schlimmer geworden ... Hatte gehofft, dass ein Update der Bibliotheken hier Verbesserungen bringen würde..

EDIT: Mal schauen, bei genauer Betrachtung der Leiterplatte habe ich eine verdächtige Lötstelle erspäht, und diese noch einmal nachgelötet. Bleifreies Lot ist schon speziell... Aktuell laufen alle Sensoren wieder ...

MartinP

Das wäre WIRKLICH Peinlich ...

Nach dem Nachlöten der Thermosensor-Steckerleisten KEIN einziger Ausfall eines DS18B20 mehr ...

Ist zwar inzwischen eine richtige Leiterplatte, und keine Lochrasterplatte mit Vero-Lackdraht verdrahtet mehr, wie der Prototyp, aber ich hatte den Ehrgeiz, das Ding mit bleifreiem Lötzinn zu realisieren ...

Die Lötstellen ordentlich mit dem Flussmittel-Pen bearbeitet und nachgelötet. Nun ist alles glatt ...

dojodojo

Auf welche Zigbee Chips bezieht Ihr euch um mit dem DS18B20 18B20 Temperaturen übertragen zu können?

MartinP

@dojodojo Ich verwende kein Zigbee für meine DS18B20, sondern WLAN und MQTT

Es gibt einen anderen Thread, da bastelt User @skvarel alte Zigbee USB-Sticks zu Zigbee-Clients um, und pinnt da DS18B20 und anderes an die GPIO-Pins..

https://forum.iobroker.net/topic/78932/cc2530-cc2531-als-custom-zigbee-aktor-sensor/69?lang=en-GB