DALLAS DS18B20 configuration register check

[apaex]

The problem

My sensor DS18B20 returns zeros in 0-5 bits of the configuration register:

[23:26:11][VV][dallas.sensor:258]: Scratch pad: AD.01.4B.00.60.FF.03.10.7C (7C) [23:26:11][W][dallas.sensor:263]: 'Wired temperature' - Scratch pad config register invalid!

In the configuration register 60, that is 1100000b

3358 added a check that caused it to stop working.

Which version of ESPHome has the issue?

2023.3.2

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP8266

Board

No response

Component causing the issue

dallas

Example YAML snippet

dallas:
  - pin: GPIO15
sensor:
  - platform: dallas
    address: 0x8F06473B51760028
    name: "Wired temperature"
    id: temperature_sensor

Anything in the logs that might be useful for us?

[23:26:11][VV][dallas.sensor:258]: Scratch pad: AD.01.4B.00.60.FF.03.10.7C (7C)
[23:26:11][W][dallas.sensor:263]: 'Wired temperature' - Scratch pad config register invalid!

Additional information

No response

[DAVe3283]

I personally feel that esphome/esphome#3545 was not a good solution to catch a complete lack of communication (#3358). I prefer an explicit check for all zeros or all ones to indicate a bus problem on sensors with weak checksums (e.g. esphome/esphome@03944e6cd8858f42ab0cf730d8e1dbddd559aa81).

However, the DS18B20 datasheet clearly states that the configuration register reserves bit 7 and bits 4:0, so the check on that register is valid. If anything, I would have gone farther and verified scratch pad bytes 5 and 7 as well, which are defined in the datasheet as 0xFF and 0x10 respectively.

The only valid configuration register values are 0x1F, 3F, 5F, and 7F, but yours read as 0x60. So either your DS18B20 is malfunctioning, there are signaling (communication) problems (not super likely if you never see checksum fails), or you have some sort of a clone/fake sensor.

I am not sure what the right answer is here. The code could be rewritten to explicitly check for all zero/all one scratchpad, then allow invalid configuration register values. That would get your non-compliant sensor working, but it might also accept other incompatible sensors and produce garbage output.

Is your DS18B20 hard to swap out? I bet if you put a new genuine one in, it would work.

[apaex]

You are absolutely right, my sensor is a clone from AliExpress. However, it has been working well for several years. For myself, I turned off the check in the code so that everything would work further. If the problem is not relevant for other users, you can close it.

[apaex]

If you check the sensor model in the address[0] and crc and crc from sensor memory, won't that be enough?

[DAVe3283]

It seems reasonable to trust the family code (address[0]) and CRC (address[7]) from bootup, then just explicitly check for all 0 or 1 on every read to detect when a DS18B20 drops offline or wiring problems. That avoids relying on the configuration registers, which are technically reserved, and could theoretically be changed in a new revision of the part/datasheet.

The Dallas code is for the DS18S20, DS1822, DS18B20, and DS28EA00, but I only have the DS18B20 to test with. I can take a crack at it when I get some free time and submit a PR. I'd like to see someone with one of the other sensors test it out too.

[apaex]

I'd like to see someone with one of the other sensors test it out too.

Unfortunately, I only have a DS18B20 clone available :(

then just explicitly check for all 0 or 1 on every read to detect when a DS18B20 drops offline or wiring problems

The crc for memory, scratchpad[8], is not enough in this case?

[Gatlarf]

Looks like this may be related to the ongoing problems with Dallas sensors as described here: https://github.com/esphome/issues/issues/3909

[DAVe3283]

Looks like this may be related to the ongoing problems with Dallas sensors as described here: #3909

This is a separate issue. The linked issue is a timing problem caused by framework/header updates that causes some sensors not to communicate.

This issue is some clone sensors have reserved bits in the configuration register set differently than genuine sensors, and are being filtered out by the library. We are communicating with the sensors, but rejecting them.

When I get back from travel I plan to submit a PR to address this issue, but it will not solve the timing issue some people are experiencing. It will only enable more clones to work with the Dallas library.

If I had a Dallas sensor that was not working due to timing, I would try and fix that too, but I really need hardware on hand to debug that kind of an issue.

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[DAVe3283]

I really do intend to get around to making a PR for this, just been too busy lately.