esphome / issues

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

Senseair sensor stopped working after upgrading ESPHome from 2022.3.1 to 2022.12.3 #4019

Open ahuhta opened 1 year ago

ahuhta commented 1 year ago

The problem

Senseair sensor is not responding after finally upgrading ESPHome from 2022.3.1 to 2022.12.3. I assume this is because somehow the pause time between the wake up byte and actual payload is shortened. That strange because the senseair code hasn't changed. I tested to increase the delay from 5 to 6 and that solved the problem. Scope screenshots attached.

Same problem and fix also with esp32-c3-devkitm-1 board. That board I couldn't measure with the scope.

Maybe someone should also look the root cause. Why the actual time with function delay has changed.

Which version of ESPHome has the issue?

2022.12.3

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2023.1.2

What platform are you using?

ESP32-IDF

Board

esp32dev

Component causing the issue

senseair

Example YAML snippet

esphome:
  name: senseair-co2

esp32:
  board: esp32dev
  framework:
    type: esp-idf

logger:

api:

ota:
  password: !secret ota_password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

uart:
  rx_pin: GPIO22
  tx_pin: GPIO23
  baud_rate: 9600

sensor:
  - platform: senseair
    co2:
      name: "Senseair CO2 Value"
    update_interval: 60s

Anything in the logs that might be useful for us?

[E][uart:015]: Reading from UART timed out at byte 0!
[W][senseair:024]: Reading data from SenseAir failed!

Additional information

Original code:

bool SenseAirComponent::senseair_write_command_(const uint8_t *command, uint8_t *response, uint8_t response_length) {
  // Verify we have somewhere to store the response
  if (response == nullptr) {
    return false;
  }
  // Write wake up byte required by some S8 sensor models
  this->write_byte(0);
  this->flush();
  delay(5);
  this->write_array(command, SENSEAIR_REQUEST_LENGTH);

  bool ret = this->read_array(response, response_length);
  this->flush();
  return ret;
}

Fixed code working properly:

bool SenseAirComponent::senseair_write_command_(const uint8_t *command, uint8_t *response, uint8_t response_length) {
  // Verify we have somewhere to store the response
  if (response == nullptr) {
    return false;
  }
  // Write wake up byte required by some S8 sensor models
  this->write_byte(0);
  this->flush();
  delay(6);
  this->write_array(command, SENSEAIR_REQUEST_LENGTH);

  bool ret = this->read_array(response, response_length);
  this->flush();
  return ret;
}

Scope screenshot ESPHome 2022.3.1: 2022_3_1

Scope screenshot ESPHome 2022.12.3: 2022_12_3 Scope screenshot ESPHome 2022.12.3 with delay(6): 2022_12_3_delay_6

DAVe3283 commented 1 year ago

The scope shots seem to show the older version having a little over 6ms delay from delay(5), while the newer version is just a smidge under 5ms. Hard to see in those scope shots.

Was the old version using the esp-idf or arduino framework? The difference may be in how the two frameworks implement delays.

With more accurate scope measurements, it might show the real problem is the esp-idf delay implementation is under-shooting the delay.

Can you try compiling with the arduino framework and see if the delay is different vs. the esp-idf framework?

Glenf commented 1 year ago

I have the same issue, but no scope (or knowledge to use one) available. I tried building with both frameworks with same results in logs. Hope this helps.

Snips of yaml

esp32:
  board: wemos_d1_mini32
  framework:
    type: esp-idf
esp32:
  board: wemos_d1_mini32
  framework:
    type: arduino

Log (same result with both platforms)

[11:54:33][E][uart:015]: Reading from UART timed out at byte 0!
[11:54:33][W][senseair:024]: Reading data from SenseAir failed!

Which version of ESPHome has the issue? 2022.12.8

What type of installation are you using? Home Assistant Add-on

Which version of Home Assistant has the issue? Home Assistant 2023.2.4

Glenf commented 2 months ago

I managed to get this working by changing GPIO pins used from GPIO9 and GPIO10 to GPIO1 and GPIO3 (rx and tx labeled pins). For some reason my d1_mini wasn't working correctly with other pins. I didn't try out all of them.