fix(ltr390): stuck ALS values when configured for ALS+UV readings

[CodeInPolish]

What does this implement/fix?

I have been experiencing stuck values for ALS readings when the sensor was configured to provide ALS & UV readings. By stuck values, I mean that only the first sample of ALS readings is taken and subsequent values are always exactly the same as the first while UV readings were changing as expected.

(ALS at the top, UV at the bottom)

If the sensor is configured for ALS only, the problem isn't there. So the issue isn't the sensor itself but how we interact with it.

I have made multiple experiments but it's still not exactly clear why the sensor behaves likes it does. The datasheet does mention a few interesting facts.

The datasheet is very vague. But my theory is the following:

1. The device is configured
2. The update method is triggered, setting the FSM to ALS mode
3. Device is configured for ALS mode, we get ALS measurement n°1
4. The FSM state is set to UV mode
5. The device is configured for UV mode, we get UV measurement n°1
6. we wait update_interval
7. update method is triggered again, setting FSM to ALS mode
8. Device is configured for ALS mode, we get the same values as measurement n°1
9. The FSM state is set to UV mode
10. The device is configured for UV mode, we get UV measurement n°2

The "error" would be somewhere between step 5 and 8. After step 5, the device is still in measurement mode and would produce an UV measurement that we won't read before changing the mode to ALS.
The device only clears the UVS/ALS Data Status after a read.

So we're actively reading MAIN_STATUS, possibly preventing the sensor from updating the stored measurement. Then we're possibly assuming that the 'UVS/ALS Data Status' is reset after changing measurement modes.

To boil it down:

• An UV measurement is ready, that we do not read
• We change measurement mode and the data available bit is still set from the UV reading
• We interpret this data ready bit as valid data for ALS measurements (while it's still in progress)
• Directly after reading ALS data, we change measurement mode to UV, cancelling the in-progress ALS measurement

I am not sure this is exactly what happens but I have experimented with a few fixes and the most elegant one is pretty obvious: when we're done with measurements, just put the sensor in standby.

This is done by setting LTR390_CTRL_EN to 0. When we want to take new measurements, we set it to 1 in addition to the measurement mode. I have added two extra delays: one for wakeup and one for the ADC settle time (taken from the datasheet)

In addition to fixing stuck values for ALS, the sensor is only pulling 1uA (in standby) compared to 100-110uA.

Data after the fix

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Other

Test Environment

• ESP32
• ESP32 IDF
• ESP8266
• RP2040
• BK72xx
• RTL87xx

Example entry for config.yaml:

- platform: ltr390
    i2c_id: bus_a
    update_interval: 5s
    uv_index:
      name: "UV Index"
    light:
      name: "Light"

Checklist:

• The code change is tested and works locally.
• Tests have been added to verify that the new code works (under tests/ folder).

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated in esphome-docs.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 54.23%. Comparing base (4d8b5ed) to head (86c52e9).
Report is 564 commits behind head on dev.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #6723      +/-   ##
==========================================
+ Coverage   53.70%   54.23%   +0.52%     
==========================================
  Files          50       50              
  Lines        9408     9584     +176     
  Branches     1654     1689      +35     
==========================================
+ Hits         5053     5198     +145     
- Misses       4056     4062       +6     
- Partials      299      324      +25     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[probot-esphome]

Hey there @sjtrny, mind taking a look at this pull request as it has been labeled with an integration (ltr390) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}