[Gelöst] ESP32S mit DS18B20 Temp-Sensor

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!

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