problem with d1_mini board version and Dallas sensor

[catdogmaus]

The problem

I have a problem with d1_mini board v.3 and Dallas sensor cooperation. Unfortunately, the results are very inconsistent. Sometimes I can see the sensor in logs, sometimes not. Failure seems to be related with "Scratch pad checksum invalid!" I have tested with 2 similar boards and 3 different sensors. Figured out that when I use resistor about 2.5K about 50% of data comes thru. It must be ESPHome bug because when I migrated this device to Tasmota everything works perfectly. (I use Aliexpress sensors but with other boards they have so far worked always perfectly, also they now work with Tasmota.)

Which version of ESPHome has the issue?

2023.6.4 but the issue has been presistent numerious previous versions

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2023.x.x

What platform are you using?

ESP8266

Board

d1_mini board v.3

Component causing the issue

dallas

Example YAML snippet

esphome:
  name: "water"

esp8266:
  board: d1_mini 

dallas:
  - pin: GPIO4

sensor:
  - platform: dallas
    address: 0xa83ce10457f4ed28
    name: "water"

Anything in the logs that might be useful for us?

[21:33:17][W][dallas.sensor:131]: 'water' - Resetting bus for read failed!
[21:33:18][D][sensor:093]: 'water': Sending state nan °C with 1 decimals of accuracy
[21:34:17][W][dallas.sensor:131]: 'water' - Resetting bus for read failed!
[21:34:18][D][sensor:093]: 'water': Sending state nan °C with 1 decimals of accuracy
[21:35:17][W][dallas.sensor:131]: 'water' - Resetting bus for read failed!
[21:35:17][D][sensor:093]: 'water': Sending state nan °C with 1 decimals of accuracy
[21:36:16][E][dallas.sensor:112]: Requesting conversion failed
[21:36:16][D][sensor:093]: 'water': Sending state nan °C with 1 decimals of accuracy
[21:37:17][W][dallas.sensor:261]: 'water' - Scratch pad checksum invalid!
[21:37:17][D][sensor:093]: 'water': Sending state nan °C with 1 decimals of accuracy
[21:38:17][D][dallas.sensor:143]: 'water': Got Temperature=26.9°C
[21:38:17][D][sensor:093]: 'water': Sending state 26.93750 °C with 1 decimals of accuracy
[21:39:17][D][dallas.sensor:143]: 'water': Got Temperature=26.9°C
[21:39:17][D][sensor:093]: 'water': Sending state 26.93750 °C with 1 decimals of accuracy
[21:40:16][E][dallas.sensor:112]: Requesting conversion failed
[21:40:16][D][sensor:093]: 'water': Sending state nan °C with 1 decimals of accuracy
[21:41:17][W][dallas.sensor:261]: 'water' - Scratch pad checksum invalid!
[21:41:17][D][sensor:093]: 'water': Sending state nan °C with 1 decimals of accuracy

Additional information

As I mentioned I migrated the device to Tasmota so I am not able to create additional logs or anything additional to this bug related.

[ghost]

Can you share circuit schematic, power supply, wire length (d1 mini ~ dallas sensor) details.

[catdogmaus]

Circuit schematic is probably unnecessary bcs it is standard minimal - board, sensor to 3V (u can see data pin from yaml) and resistor. (I could download a schematic pic from somewhere on the web but it's pointless bcs it's always the same.) Power is standard (generic) 2W USB supply. Board: wemos mini v.3.0 clone. Sensor: No idea. It's dallas ds18b20 with 3m cable. My point is all this works in Tasmota flawlessly. I watched Tasmota logs about 20min and did not see any glitches so it is really unlikely to have some hardware problem.

[ghost]

One last query can you send a picture of how you join sensor to board. You mentioned minimal circuit power over usb

[ghost]

This issue happened with me a long time ago, continuous disconnection of dallas sensor. The issue happen due to 2 factor:

1. lose connection Note: don't try solder sensor wire to module - instead use Pitch Plug-in Screw Terminal Block Connector.
2. happen only if data cable is long (>= 1m), d1 mini software power up before dallas sensor. Solve by direct connection to sensor ~ power supply. Optional:
3. Pullup resistor always close to module.
4. Decrease the dallas resolution to 9bit.

On the basis of logs issue happening due to lose wire connection.

[catdogmaus]

A loose wire is the most unlikely thing imaginable! I tried three different sensors and two boards. This means that every time miraculously the exactly same loose wire problem had to appear, and even more miraculously, just before I converted the board to Tasmota, this loose wire problem fixed itself. It is difficult to say how it would have been with changing the resolution because I can no longer test it. It is possible that Tasmota has some more robust method to solve the resolution problem when it exists and it gave at the end a positive result, but I'm not a programmer, just an ordinary user, and I can't take a stand here.

[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.

[Arkoxs]

I have almost the same issues that were also resolved by switching to Tasmota. I can however easily switch back to ESPHome., What would you like to know? I have the following setup:

All sensors register correctly but I'm getting an "Scratch pad checksum invalid" error when trying to get the sensor info on all sensors.

ESPHome: 2023.10.3 Hardware: Wemos D1 mini (8266) Cable is about 2 meters of unshielded 4 lines (red/blue/black/yellow)

red line: 5V blue line: GND yellow line: 10x Sensors genuine Dallas on D2 black line: 1x Sensor clone AliExpress on D4 Pull-up resister 4k7 between red line and yellow line at the Wemos module side. Power is provide by an 230V USB adapter (5V/1A) and also tested with a Switching Power supply (5V/8A)

Tuning down the resolution from 12 to 11, 10 or 9 did not make any difference. Rearranging the sensors does not make a difference. Also addressing just 1 sensor did not make a difference. I've tried adjusting the time_constant in the esp_one_wire.cpp file I've tried removing the Interrupt Lock in the dallas_component.cpp

If you want photo's let me know, I can provide yaml and verbose logging.

[chrwei]

I'm also having this issue. the hardware works fine with Arduino's examples, even when adding a web server. i enabled log level VERY_VERBOSE and get this

[D][dallas.sensor:083]:   Found sensors:
[D][dallas.sensor:085]:     0xf400000400c49b28
[C][dallas.sensor:090]:   Device 'Temperature'
[C][dallas.sensor:090]:     Device Class: 'temperature'
[C][dallas.sensor:090]:     State Class: 'measurement'
[C][dallas.sensor:090]:     Unit of Measurement: '°C'
[C][dallas.sensor:090]:     Accuracy Decimals: 1
[V][dallas.sensor:090]:     Unique ID: 'dallas-289bc400040000f4'
[C][dallas.sensor:098]:     Address: 0x289bc400040000f4
[C][dallas.sensor:099]:     Resolution: 12

[VV][scheduler:225]: Running interval 'update' with interval=10000 last_execution=6284 (now=16286)
[VV][scheduler:032]: set_timeout(name='0x289bc400040000f4', timeout=750)
[VV][scheduler:225]: Running timeout '0x289bc400040000f4' with interval=750 last_execution=16289 (now=17039)
[VV][dallas.sensor:256]: Scratch pad: FF.FF.FF.FF.FF.FF.FF.FF.FF (C9)
[W][dallas.sensor:262]: 'Temperature' - Scratch pad checksum invalid!
[V][sensor:043]: 'Temperature': Received new state nan
[D][sensor:093]: 'Temperature': Sending state nan °C with 1 decimals of accuracy

What's interesting here is that the Found Sensor address and the device address are reversed and checking the code I'm really not sure why. They all are a format_hex() of a uint64_t of which that value all comes from the same place, unless I'm readding it wrong. If it is getting reversed somewhere, that would explain why it's getting FF.FF.FF.FF.FF.FF.FF.FF.FF.

[chrwei]

I've verified that this is the problem. I hard coded the wire->select(this->address_); to wire->select(0xf400000400c49b28); and now it's working.

[VV][scheduler:225]: Running interval 'update' with interval=10000 last_execution=101859 (now=111865)
[VV][scheduler:032]: set_timeout(name='0x289bc400040000f4', timeout=750)
[VV][scheduler:225]: Running interval '' with interval=60000 last_execution=52370 (now=112370)
[VV][scheduler:225]: Running timeout '0x289bc400040000f4' with interval=750 last_execution=111869 (now=112619)
[VV][dallas.sensor:259]: Scratch pad: 4F.01.60.68.7F.FF.01.10.DB (DB)
[D][dallas.sensor:143]: 'Temperature': Got Temperature=20.9°C
[V][sensor:043]: 'Temperature': Received new state 20.937500
[D][sensor:093]: 'Temperature': Sending state 20.93750 °C with 1 decimals of accuracy

so the question is, why is it getting reversed and what's the right way to fix it...

[chrwei]

ok, code is fine, my process for adding the sensor was wrong. I had used Arduino's oneWireSearch example, it prints a uint8_t array and the order of that is backwards from what the esphome config needs.