Sensirion devices give wrong values with "extended" configuration variables (scd30, scd4x)

ShurikenGitHub commented 1 year ago

The problem

So I saw that the sensirion sensors have been refactored in pr3374 (https://github.com/esphome/esphome/pull/3374) and that the functionality of scd4x had been extended pr3409 (https://github.com/esphome/esphome/pull/3409).

I have a scd40 and scd30, every time I use one of the "extended" configuration variables (so not the "standard" co2, temp, hum) the sensors stars to give me completely incorrect numbers (2500 for scd40 which is out of its range, -600c) and stops reporting after a while (temp and hum stay the same and co2 is completely wrong).

When I reset the values with an arduino sketch from adafruit (scd4x.factory_reset doesn't work), it gives me normal values again. #3063 So it seems to me that something is wrong with the values that are set with the "extended options".

Anyone else experiencing similar issues?

Which version of ESPHome has the issue?

2022.8.0

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

2022.8.7

What platform are you using?

ESP8266

Board

D1 mini

Component causing the issue

scd4x/scd30

Example YAML snippet

- platform: scd4x
    co2:
      name: "Workshop CO2"
    temperature:
      name: "Workshop Temperature"
    humidity:
      name: "Workshop Humidity"
# These "extended" values seem to be broken:
    temperature_offset: -4.3
    measurement_mode: low_power_periodic
    ambient_pressure_compensation: 1014

Anything in the logs that might be useful for us?

[11:38:24][W][scd4x:175]: Data not ready yet!

Additional information

Same problems go for scd30 with the temperature_offset and ambient_pressure_compensation

lorki97 commented 1 year ago

After removing ambient_pressure_compensation from my configuration, I too get correct values again as opposed to my description in https://github.com/esphome/issues/issues/3407#issuecomment-1220995065

I am pretty sure that this does indeed stem from the changes in https://github.com/esphome/esphome/pull/3374 (I already suspected this after some investigation).

github-actions[bot] commented 1 year ago

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.

esphome / issues