esphome / issues

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

DS18B20 scratchpad invalid checksum error #4522

Open MarkoPaasila opened 1 year 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 11 months ago

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

Arkoxs commented 8 months 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 8 months 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 5 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 5 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 2 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; }/