UV Index with LTR390-UV sensor

tinker_ha · September 22, 2022, 8:24pm

I just started with this sensor and am getting (using defaults) on my window sill in direct sun.

Daylight: 52428.60156 lx
Ambient Light: 262143.00000
UV Index: 0.14000 UVI
UV: 322.00000

UV Index should be 6.5 right now.

I have the Waveshare UV (C) board with LTR390-UV-01 sensor.

For the glass you want Far UV Grade Fused Silica Quartz. This is frequently sold in 30mm squares. I have one and it does not affect the readings from quick testing. My regular windows reduce UVI reading by one decimal place (0.14 → 0.014).

Plan on installing this in a weather station so the readings will probably change.

alfwro13 · September 22, 2022, 9:18pm

looks like your UV Index value is equally weird

Aussi · March 27, 2023, 5:25pm

Sadly enough I have the same weird index values…

p3001 · April 3, 2023, 9:53pm

I have the same weird index values. And I think I figured out the issues. I opened an issue in the esphome github, the details are there:

github.com/esphome/issues

ltr390 light sensor reports very low UVI values and resolution settings not working

opened 03:11AM - 02 Apr 23 UTC

plee3001

### The problem Issue 1: When using the ltr390 sensor component, it reports ver…y low UVI values. For example, when under direct midday sun, when UVI of 7 or greater is expected, it would report UVI of less than 1. Issue 2: When changing the resolution to something other than default, the raw outputs, als or uvs, do not scale with the resolution. Instead the calculated light lux (lx) output would change by factors of 2 even though it should stay more or less the same under the same lighting conditions. Looking into the source file, I think I have found and fixed the issues. Attached is the modified .cpp file that seems to give reasonable values. I have no light measurement tool to verify. [ltr390.cpp.txt](https://github.com/esphome/issues/files/11130942/ltr390.cpp.txt) The cause of issue 1 seems to be the interpretation of the ambiguous datasheet. The UVI Conversion Formula in the datasheet has no terms to compensate for gain and resolution settings. While on Figure 4.6, it implies that the Sensitivity of 2300 counts/UVI is tied to Gain 18x and Resolution 20-bit. In my experiments, even under direct midday sun, the UV ADC output values are still a number of bits short of the max afforded by the ADC register at Gain 18x. So it is best to use Gain 18x for UV measurement all the time. In the .cpp file attached, it uses the user config gain setting for the ambient light measurement and uses 18x for UV measurement. The calculation of UVI is changed to include a factor ( 4 / INT ) to account for the different resolution settings. The cause of issue 2 is that the user config resolution setting is never applied to the ltr390 chip. There are a few lines in the original source in setup() with a comment of "Set resolution". But the few lines end up not really changing anything. In the attached .cpp, it has been modified to actually write the user config resolution setting to the ltr390 chip. ### Which version of ESPHome has the issue? 2022.12.8 is what I am using ### What type of installation are you using? pip ### Which version of Home Assistant has the issue? n/a, debug using esphome log ### What platform are you using? ESP8266 ### Board d1 mini ### Component causing the issue ltr390 ### Example YAML snippet ```yaml i2c: scl: 5 sda: 4 sensor: - platform: ltr390 address: 0x53 uv_index: name: ${esp_name} uv index uv: name: ${esp_name} uvs light: name: ${esp_name} alight ambient_light: name: ${esp_name} als resolution: 20 update_interval: 10s ``` ### Anything in the logs that might be useful for us? _No response_ ### Additional information _No response_

Until it is fixed in the esphome depository, here are the possible workarounds:

workaround 1:
The resolution config does not work, so leave it at 18-bit default.
The UVI calculation depends on the resolution config and gain config, so calculate your own using this formula:
UVI = ( uv / 2300 * wfac ) * 4 * ( 18 / gain )
The first part is the original formula.
The x 4 is to adjust for being at default 18-bit resolution instead of 20-bit.
The x 18 / gain is to adjust for actual gain configured vs x18 gain assumed in the original formula.

workaround 2:
Use the esphome external components method to override the ltr390 component.

Set up the external component by downloading the ltr390 files from the esphome github, you should get 4 files in the ltr390 directory. Overwrite the ltr390.cpp file by the file I attached in the opened issue above (the attached file should be renamed to ltr390.cpp).

alfwro13 · April 5, 2023, 2:15pm

It would be great if they could fix that, I would love to include that sensor in my new irrigation controller

jruben4 · August 13, 2023, 4:16pm

Does this lamda look right?
Also, are the wfac and gain correct assuming I’m not changing any of the defaults?
I’m still getting UVI values about 1/4 what is published for my zip code.

    lambda: |-
      const float wfac = 1.0;   // wfac
      const float gain = 3.0;   // gain
      return ( ((id(${devicename}_UV).state * wfac) / 2300) * 4 * ( 18 / gain ));

avsantos76 · November 24, 2023, 4:55pm

I haven’t read all the comments but I want to remmenber that the LTR390 UV measure doesn’t return the index, the index must be calculated.

pw44 · January 24, 2024, 2:23pm

Hi,

i’m trying this workaround, but it’s failing with:

Failed config

sensor.ltr390: [source <unicode string>:373]
  platform: ltr390
  uv_index: 
    name: Weather Station ltr390 UV index
    id: ltr390_uv_index
  uv: 
    name: Weather Station ltr390 uvs
    id: ltr390_uvs
    
    [lambda] is an invalid option for [uv]. Please check the indentation.
    lambda: |-
      float wfac = 1.0;   // wfac
      float gain = 3.0;   // gain
      return ( ((id(ltr390_uvs).state * wfac) / 2300) * 4 * ( 18 / gain ));
  light: 
    name: Weather Station ltr390 light
    id: ltr390_light
  ambient_light: 
    name: Weather Station ltr390 ambient light
    id: ltr390_ambient_light
  resolution: 20
  update_interval: 10s

for the sniplet.

# UV and Ambient Light
  - platform: ltr390
    uv_index:
      name: "${friendly_name} ltr390 UV index"
      id: ltr390_uv_index
    uv:
      name: "${friendly_name} ltr390 uvs"
      id: ltr390_uvs
      lambda: |-
        float wfac = 1.0;   // wfac
        float gain = 3.0;   // gain
        return ( ((id(ltr390_uvs).state * wfac) / 2300) * 4 * ( 18 / gain ));
    light:
      name: "${friendly_name} ltr390 light"  
      id: ltr390_light
    ambient_light:
      name: "${friendly_name} ltr390 ambient light"
      id: ltr390_ambient_light
    resolution: 20
    update_interval: 10s

Any advise, please?

Troon · January 24, 2024, 3:21pm

The error message makes it clear: you can’t have a lambda here.

See the docs: what are you trying to return? I think you want this in an on_value: section. See here:

pw44 · January 24, 2024, 3:28pm

Thank you, changed to:

# UV and Ambient Light
  - platform: ltr390
    uv_index:
      name: "${friendly_name} ltr390 UV index"
      id: ltr390_uv_index
    uv:
      name: "${friendly_name} ltr390 uvs"
      id: ltr390_uvs
      on_value: 
        then:
          lambda: |-
            float wfac = 1.0;   // wfac
            float gain = 3.0;   // gain
            return ( ((id(ltr390_uvs).state * wfac) / 2300) * 4 * ( 18 / gain ));
    light:
      name: "${friendly_name} ltr390 light"  
      id: ltr390_light
    ambient_light:
      name: "${friendly_name} ltr390 ambient light"
      id: ltr390_ambient_light
    resolution: 20
    update_interval: 10s

no syntx error, but by compling, error.

Dependency Graph
|-- AsyncTCP-esphome @ 2.0.1
|-- WiFi @ 2.0.0
|-- FS @ 2.0.0
|-- Update @ 2.0.0
|-- ESPAsyncWebServer-esphome @ 3.1.0
|-- DNSServer @ 2.0.0
|-- ESPmDNS @ 2.0.0
|-- noise-c @ 0.1.4
|-- Wire @ 2.0.0
|-- ArduinoJson @ 6.18.5
Compiling .pioenvs/weather-station/src/main.cpp.o
: In lambda function:
:386:71: error: return-statement with a value, in function returning ‘void’ [-fpermissive]
*** [.pioenvs/weather-station/src/main.cpp.o] Error 1
========================== [FAILED] Took 6.12 seconds ==========================

what could i be doing wrong?

zoogara · January 25, 2024, 12:40am

You are using on_value: when you should be using filters:, assuming you want to replace the value of the UV entity.

    uv:
      name: "${friendly_name} ltr390 uvs"
      id: ltr390_uvs
      filters: 
        lambda: |-
          float wfac = 1.0;   // wfac
          float gain = 3.0;   // gain
          return (x * wfac / 2300 * 4 * 18 / gain);

pw44 · January 25, 2024, 11:38am

Thank you so much!

xarmoda · January 27, 2024, 4:27am

I’m not having any luck receiving data from my Gravity LTR390-UV. It’s connected to a ESP32ThingPlus using the default pins SDA: GPIO23 and SCL: GPIO22.

I’m at a point where I at least get the device discovered. I have experimented with a few different approaches using code others have found works. What should I expect to see? has anyone any suggestions on how I could test to see if it’s even functional. beginning to think I’ve got a dud sensor.

[14:13:02][C][i2c.arduino:054]:   SDA Pin: GPIO23
[14:13:02][C][i2c.arduino:055]:   SCL Pin: GPIO22
[14:13:02][C][i2c.arduino:056]:   Frequency: 50000 Hz
[14:13:02][C][i2c.arduino:059]:   Recovery: bus successfully recovered
[14:13:02][I][i2c.arduino:069]: Results from i2c bus scan:
[14:13:02][I][i2c.arduino:075]: Found i2c device at address 0x1C

my yaml is as follows:

i2c:
  sda: GPIO23
  scl: GPIO22
  scan: true

sensor:
  - platform: ltr390
    uv:
      name: "UV"
    uv_index:
      name: "UV Index"
    light:
      name: "Light"
    ambient_light:
      name: "Ambient Light"
    resolution: 19
    gain: X3
    window_correction_factor: 1
    update_interval: 5s

Griizly · January 27, 2024, 3:15pm

Hi, Liteon, the manufacturer of the LTR390 made a revision of the datasheet were he say that UV sensivity for the sensor is not 2300 but 1400 FYI => LTR390/LTR-390UV-01_Final_ DS_V1.4.pdf at main · levkovigor/LTR390 (github.com)

pw44 · January 28, 2024, 12:18am

so, to have it right, shall 2300 in the formula ( ((id(ltr390_uvs).state * wfac) / 2300) * 4 * ( 18 / gain )); be replaced by 1400, so ( ((id(ltr390_uvs).state * wfac) / 1400) * 4 * ( 18 / gain ));?

xarmoda · January 28, 2024, 1:17am

no data. interestingly, no errors.

Griizly · January 28, 2024, 7:31am

In theory yes, I did it on my setup and UVI are now a 30% higher than expected so I think I will stick to 2300

sjtrny · February 1, 2024, 8:37am

Hi all, chiming in to say that the discussion has been updated over on Github ltr390 light sensor reports very low UVI values and resolution settings not working · Issue #4380 · esphome/issues · GitHub and I’ve submitted a PR to hopefully address the UVI issue.

jruben4 · June 18, 2024, 6:30pm

I know they updated the esphome page for this sensor, but I’m a little confused on which integration time to pick. There’s a chart at the bottom to find the correct integration time but:

They say the default gain should be X18
They say the default resolution should be 20

These are two different rows in the table - I would pick integration time of 100 based on the gain and 400 based on the resolution.

Any ideas what the correct integration time would be with those default gains/resolutions?

tefesp · July 10, 2024, 9:50am

Hi! I have exactly the same problem! Did you manage to solve it somehow?