search

esphome / issues

Issue Tracker for ESPHome
https://esphome.io/
291 stars 36 forks source link

DS18B20 scratchpad invalid checksum error #4522

Closed MarkoPaasila closed 3 months ago

MarkoPaasila commented 1 year ago

The problem

DS18B20 (apparently clones) don't work anymore, and give the "scratchpad invalid checksum error".

Which version of ESPHome has the issue?

2023.5.0 ->

What type of installation are you using?

pip

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP32

Board

devkit-c

Component causing the issue

dallas

Example YAML snippet

dallas:
  - pin: GPIO19
    update_interval: 10s

sensor:
  - platform: dallas
    address: 0x8C062018C89DC028
    name: "temperature-outside1"
    id: t1
    accuracy_decimals: 4
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    icon: "mdi:thermometer"
    disabled_by_default: false
    filters:
      - offset: 0.0625
      - exponential_moving_average:
          alpha: 0.1
          send_every: 1

Anything in the logs that might be useful for us?

No response

Additional information

Downgrading to 2023.4.4 solves the issue.

RoelHermus commented 1 year ago

I have a pull-up resistor 2.7k between the data line and the plus. When I remove that resister it gives the error you also have. In the Dalles data sheet they use a 4k7 resistor.

JamieR007 commented 1 year ago

For more information, see: https://github.com/esphome/issues/issues/3980 https://github.com/esphome/issues/issues/4543

Arkoxs commented 1 year ago

Same issue here. 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 length is about 2 meters

Pull-up resister 4k7 between red line and yellow line. 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

I've tried installing Tasmota and then all sensor report the correct temperature so it does not look to be a hardware issue.

I could send my hardware to one of the developers if you can't reproduce this.

Arkoxs commented 1 year ago

And to see if it was not an issue in previous versions I've used the Legacy ESPHome version add-on in Home Assistant provided by @khenderick to test if this was not an issue in ESPHome 2022.11.1.

Unfortunately the same error is generated in the older versions.

ddochstader472 commented 10 months ago

Did you ever resolve this issue? I am having checksum errors with a couple of clone sensors. They seem to work when I first connect them but then a couple of days later they get the checksum error. When I test them, they are seen but have checksum error?

Arkoxs commented 10 months ago

@ddochstader472 The invalid checksum error is still there. Nothing seems to help. For now I've flashed my temp sensor with Tasmota. I just needed to change the maximum number of ds12b20 sensors and it's reading my 11 sensors without issues.

I'll check in regularly to see of a solution is available.

ioiogamboa commented 7 months ago

A quick solution that worked for me was disabling the checksum. I didn't use this feature in previous Arduino-IDE projects, and it might be configurable in future ESPHome versions through the YAML configuration file. I temporarily bypassed the checksum by commenting out all CRC8 checks. This worked for my project, which allows for some error values each time. I modified the file dallas_component.cpp today, and it works, but I need time to check if I encounter any secondary problems. Maybe Tasmota don't make crc8 check and work fine, i don't known, i don't get inside Tasmota code.

I change source file dallas_component.cpp in three point following marked in bold font:

1) Changing class function check_scratch_pad(), forcing chksum_validity to true and log.

bool DallasTemperatureSensor::check_scratch_pad() { bool chksum_validity = true; // (crc8(this->scratchpad, 8) == this->scratchpad[8]);

switch (this->get_address8()[0]) { case DALLAS_MODEL_DS18B20: config_validity = ((this->scratchpad[4] & 0x9F) == 0x1F); break; default: config_validity = ((this->scratchpad[4] & 0x10) == 0x10); }

ifdef ESPHOME_LOG_LEVEL_VERY_VERBOSE

ESP_LOGVV(TAG, "Scratch pad: %02X.%02X.%02X.%02X.%02X.%02X.%02X.%02X.%02X (%02X)", this->scratchpad[0], this->scratchpad[1], this->scratchpad[2], this->scratchpad[3], this->scratchpad[4], this->scratchpad[5], this->scratchpad[6], this->scratchpad[7], this->scratchpad[8], true); this->scratchpad[5], this->scratchpad[6], this->scratchpad[7], this->scratchpad[8], true); // crc8(this->scratchpad, 8));

endif

2) Changing class function setup(), avoiding address crc8 address check.

void DallasComponent::setup() { ESP_LOGCONFIG(TAG, "Setting up DallasComponent...");

pin_->setup();

// clear bus with 480µs high, otherwise initial reset in searchvec() fails pin->pin_mode(gpio::FLAG_INPUT | gpio::FLAG_PULLUP); delayMicroseconds(480);

onewire = new ESPOneWire(pin_); // NOLINT(cppcoreguidelines-owning-memory)

std::vector raw_sensors; raw_sensors = this->onewire->search_vec();

for (auto &address : raw_sensors) { auto address8 = reinterpret_cast<uint8_t >(&address); /if (crc8(address8, 7) != address8[7]) { ESP_LOGW(TAG, "Dallas device 0x%s has invalid CRC.", format_hex(address).c_str()); continue; }/

abonyi91 commented 3 months ago

Hi together,

Based on https://github.com/esphome/issues/issues/4522#issuecomment-2049810474 I found the dallas_component.cpp in my HA/ESPhome integration. After I modified the file and I am hitting the install button on the gui the file is not built in the project. The build completed immediatelly meanwhile there is no .o file mentioned to any changed any .cpp file.

How can I force ESPhome to use the modified file?

I have a wemos d1 mini with 4 sensor. Latest HA with latest ESPhome integration. I saw the same issue from a long time but when I had to modify the sensor config in the *.yaml file (for platform and one wire/dallas usage) the measured values are useless. Sometime I getting the value but mostly not. Even If I get the value it is not a valid number.

ssieb commented 3 months ago

Have you tried the latest release? There's no dallas_component.cpp, so modifying it isn't going to work.

abonyi91 commented 3 months ago

Based on my log my esphome is the latest version:

INFO ESPHome 2024.7.3
INFO Reading configuration /config/esphome/bubuka2.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing bubuka2 (board: d1_mini; framework: arduino; platform: platformio/espressif8266@4.2.1)
--------------------------------------------------------------------------------
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
Dependency Graph
|-- ESPAsyncTCP-esphome @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 3.2.2
|-- DNSServer @ 1.1.1
|-- ESP8266WiFi @ 1.0
|-- ESP8266mDNS @ 1.2
|-- noise-c @ 0.1.4
RAM:   [====      ]  42.9% (used 35144 bytes from 81920 bytes)
Flash: [=====     ]  49.7% (used 519049 bytes from 1044464 bytes)
========================= [SUCCESS] Took 12.88 seconds =========================
INFO Successfully compiled program.
INFO Connecting to 192.168.0.21
INFO Uploading /data/build/bubuka2/.pioenvs/bubuka2/firmware.bin (523200 bytes)
INFO Compressed to 364014 bytes
Uploading: [============================================================] 100% Done...

INFO Upload took 5.43 seconds, waiting for result...
INFO OTA successful
INFO Successfully uploaded program.
INFO Starting log output from 192.168.0.21 using esphome API
INFO Successfully connected to bubuka2 @ 192.168.0.21 in 19.524s
INFO Successful handshake with bubuka2 @ 192.168.0.21 in 2.887s
[07:55:31][I][app:100]: ESPHome version 2024.7.3 compiled on Aug  5 2024, 21:30:50

The dallas_component.cpp was found in the following path on my HA server: /usr/local/lib/python3.11/dist-packages/esphome/components/dallas

I am still getting the errors: [08:00:14][W][dallas.temp.sensor:139]: 'SENSOR_NAME' - Scratch pad checksum invalid! [08:00:14][W][component:157]: Component dallas_temp.sensor set Warning flag: scratch pad checksum invalid

Do you have any suggestion?

ssieb commented 3 months ago

The dallas_component.cpp was found in the following path on my HA server: /usr/local/lib/python3.11/dist-packages/esphome/components/dallas

That's a leftover file that didn't get cleaned up by pip for some reason. It won't be used by anything.

What do you see in the logs in the one_wire section? Has this ever worked on this device?

abonyi91 commented 3 months ago

my one_wire section from the log:

[10:45:17][C][gpio.one_wire:020]: GPIO 1-wire bus:
[10:45:17][C][gpio.one_wire:021]:   Pin: GPIO16
[10:45:17][C][gpio.one_wire:080]:   Found devices:
[10:45:17][C][gpio.one_wire:082]:     0xf00000002a032c28 (DS18B20)
[10:45:17][C][gpio.one_wire:082]:     0x440000002d8c2528 (DS18B20)
[10:45:17][C][gpio.one_wire:082]:     0xd900000029fa4d28 (DS18B20)
[10:45:17][C][gpio.one_wire:082]:     0x0f000000289a5328 (DS18B20)

Sensors and cabling were tested with arduino. Wemod D1 mini and ESPhome worked with other 4 set of sensors before. And also my observation was it worked exactly this config with few errors earlier before one wire config modification was necessary. But after that the data nearly usable. (The device is a heat exchange ventillation system where I am generating PWM for 2 fans and driving 2 relay for bypass valve. The first observation was the bypass valve automation not works. It happened based on the 4 temperature sensors by HA.

My HW:

ssieb commented 3 months ago

It's finding the sensors, but those ids are very strange. What is your sensor config?

abonyi91 commented 3 months ago

Probably it is easire to read: config.txt