DS18B20 sensors randomly disappearing

[djsomi]

Device

ITEAD_SONOFF_POW_R3

Version

ESPURNA 1.15.0-dev built 2023-11-30 19:03:55

Question

Hi All,

Recently I faced an issue that DS18B20 sensors randomly disappears from my temp metering device on my heating.
I am using 6pcs of DS18B20 sensors fixed to specific sections of the heatpump pipes to monitor it. It worked perfectly fine in the past. But recently it started randomly dropping sensors. I thought its a HW failure, so replaced everything. Flashed a new sonoff unit and hooked up 6 new sensors, but issue still exist.

Issuing a reboot, sometimes helps, but sometimes makes even more sensor offline.

Is there anything what I can do or check? Any recommendation or suggestion?

(all pipes and metal parts are grounded to avoid interfenece)

Many Thanks
Zoltan

[mcspr]

Recently I faced an issue that DS18B20 sensors randomly disappears from my temp metering device on my heating.

Recently compared with a single version of sw or after updating to a more recent one?
By disappearing, do you mean sensor data is no longer reported? What do [SENSOR] logs say on the device?

Issuing a reboot, sometimes helps, but sometimes makes even more sensor offline.

Meaning, just sw reboot is enough or it is also power on->off->on? Do single sensors work?

[djsomi]

Thank you for your reply!

The problem is that I cant recall from what version I've updated and is it comes from an update or anything else. Device only used at wintertime, and I did an update somewhere in the summer, tested for just a few minutes, that time was ok.

Disappearing means that no sensor discovered at all, sometimes I can see CRC errors and no data. But usually missig completly. Sometimes all of them sometimes 3-4 of six.

Reboot means power cycle, I found it helps more.

I cant see any specific in the logs, just that mqtt and influxdb sending data, do I have to activate some higher level logging?

Thanks!

[mcspr]

DEBUG tab shows everything happening in the console, which includes logs. Telnet connection also works. MQTT reports sensor data, but not any state info. Something to improve, perhaps.

Don't have any ds18b20 at hand, so only judging from sw side.
DallasSensor.h history / git log -p -- code/espurna/sensors/DallasSensor.h do not reveal any massive changes to DallasSensor specifically.

One thing to note is #2543 (comment) and inconsistent error checking. Meaning, just one erroneous read would invalidate all other reads from all other sensors in a chain. This would have to be fixed from sw side.

Other possible issue is mentioned in datasheet (https://datasheets.maximintegrated.com/en/ds/ds18b20.pdf / 'Powering the DS18B20') and mentioned in various issues /ds18b20/ across Tasmota, ESPEasy, esphome, etc. possibly related to inconsistent power usage when transitioning from conversion to actual data reads. This is something happening on hw, and only reliable fix is to disable parasite mode sw side and add an external power.

edit: ...or maybe we are missing _wire->depower() call after reading. this is mentioned in OneWire code.

[djsomi]

Grabbed the log, as mentioned nothing special:

[813150] [MQTT] Sending HEATPUMP/status => 1 (PID 1)
[813151] [MQTT] Sending HEATPUMP/app => ESPURNA (PID 1)
[813151] [MQTT] Sending HEATPUMP/version => 1.15.0-dev (PID 1)
[813154] [MQTT] Sending HEATPUMP/board => ITEAD_SONOFF_POW_R3 (PID 1)
[813155] [MQTT] Sending HEATPUMP/host => HEATPUMP (PID 1)
[813158] [MQTT] Sending HEATPUMP/ssid => SWIFI (PID 1)
[813160] [MQTT] Sending HEATPUMP/ip => 192.168.1.247 (PID 1)
[813164] [MQTT] Sending HEATPUMP/mac => A4:CF:12:B7:7D:8D (PID 1)
[813166] [MQTT] Sending HEATPUMP/rssi => -53 (PID 1)
[813168] [MQTT] Sending HEATPUMP/uptime => 1813 (PID 1)
[813176] [MQTT] Sending HEATPUMP/datetime => 2024-01-21 08:10:52 (PID 1)
[813177] [MQTT] Sending HEATPUMP/freeheap => 17400 (PID 1)
[813180] [MQTT] Sending HEATPUMP/loadavg => 1 (PID 1)
[813181] [MQTT] Sending HEATPUMP/vcc => 3540 (PID 1)
[813184] [MQTT] Sending HEATPUMP/relay/0 => 0 (PID 1)
[862168] [MQTT] Sending HEATPUMP/current => 0.000 (PID 1)
[862169] [MQTT] Sending HEATPUMP/voltage => 0 (PID 1)
[862170] [MQTT] Sending HEATPUMP/power => 0 (PID 1)
[862171] [MQTT] Sending HEATPUMP/reactive => 0 (PID 1)
[862172] [MQTT] Sending HEATPUMP/apparent => 0 (PID 1)
[862173] [MQTT] Sending HEATPUMP/factor => 0 (PID 1)
[862174] [MQTT] Sending HEATPUMP/energy => 0.000 (PID 1)
[862175] [MQTT] Sending HEATPUMP/temperature/0 => 11.06 (PID 1)
[862177] [MQTT] Sending HEATPUMP/temperature/1 => 12.43 (PID 1)
[862178] [INFLUXDB] Sending to 192.168.1.110:8080
[862188] [INFLUXDB] Connected to 192.168.1.110:8080
[862493] [INFLUXDB] Success response after 306ms
[863035] [INFLUXDB] Disconnected
...

And I forgot to mention that I am using sensors in normal mode.

Is there something that I can change in the code to test?

Many Thanks

[mcspr]

First thing that comes to mind is to swap OneWire mode to normal, changing 1 -> 0

espurna/code/espurna/sensors/DallasSensor.h

Line 24 in 238dc13

#define DS_PARASITE 1

Also note the 5v vs. 3v3, logic from esp is 3v3

[djsomi]

Hi All,

Recently I have a little time to do some testing on this issue. It turned out one of the 6 sensor was faulty, and assuming sometimes makes the other ones failing randomly. I've removed the faulty one, and testing the rest right now.

For curiosity removed the steel cap from the faulty sensor and it turned out that is not even an original Dallas DS18B20, its a copy MY18E20.
Also tested my new spare sensors from my last purchase, 3 of them was not worked it all, one of them is in short circuit also...

So I assuming this issue is maybe related to low quality copy sensors.

[mcspr]

One issue I have noticed after ordering some is pull-up sometimes messing up data line status. i.e. ESP8266 reboot sometimes would cause a sensor to be undiscoverable. Removing our pin init seems to fix it for me, so will do an update.

I am still figuring out a better way to sync sensor instances though, so no commits just yet :)

low quality copy sensors.

Based on 15 random ones... Every single one works, but 4 (labeled as DS18B20, but obviously counterfeit) are either defective or use some unknown payload format, causing sensor readings to show -31 degrees instead of +25 :/