Need help with an analog sensor

ESPHome
1

here is the sensor in question:

sensor:
  # Attic Brightness
  - platform: adc
    pin: A0
    name: ${device_name} Brightness
    unit_of_measurement: ''
    update_interval: 2s
    filters:
    - lambda: return x * 100;

    on_value_range:
      - below: 40.0
        then:
          - light.turn_off: indicator_led
      - above: 40.0
        then:
          - light.turn_on: indicator_led

This is basically an LDR on A0 (Wemos D1 Mini) to detect is someone left the light on in the Attic.

The problem I am seeing is that at a random time the indicator_led turns off. But nothing in the downloaded logs show the value on A0 going below 80, let alone the threshold of 40. And, no matter the level at A0, the indicator_led will not turn on again until I cover the sensor forcing the A0 level below 40 then back above 40.

Does anyone see an issue here?

2

Could be noise that you somehow canā€™t see? ADC is noisy.

So you could try something to filter for outliers/noise.

I really like medians with window size 3 (filter single spike) or 5 (filter double spike).

or a for condition?

Or implement multi-sampling.

I always had issues with those range type actions so I usually create a templte binary sensor and then drive actions off of thatā€¦

binary_sensor:
#Low tank water alert
  - platform: template
    id: tank_water_level_is_ok
    name: Tank Level Ok
    icon: mdi:water-remove-outline
    device_class: moisture
    lambda: |-
      if (id(water_tank_level).state > id(low_tank_water_threshold).state) 
          {return true;}
        else if (id(water_tank_level).state <= id(low_tank_water_threshold).state) 
          {return false;}
        else
          return {};
    on_press:
       ......
    on_release: 
       ......
1 Like
3

I thought we were on to something. I added median filter and thought this would eliminate any false readings. Note, I never saw any on the log output.

sensor:
  # Attic Brightness
  - platform: adc
    pin: A0
    name: ${device_name} Brightness
    unit_of_measurement: ''
    update_interval: 2s
    filters:
    - lambda: return x * 100;
    - median:

    on_value_range:
      - above: 40.0
        then:
          - light.turn_on: indicator_led
      - below: 40.0
        then:
          - light.turn_off: indicator_led

What I did see, for the first time, was:

no client
no client818Ɨ235 53.4 KB

4

Hmm right. Adding an uptime sensor is an easy way to keep an eye on reboots.

Could be inaccurate values close to boot.

You could adjust send_first_at: or skip_initial: ?

ā€¦ and ideally address the cause of reboot;(

5

I think the ā€œNo client connected to APIā€ was the problem. As I just learned a few days ago, the device has to be added to the integration in Home Assistant to keep the API connection live. So I added it to the integration and an hour later the issue hasnā€™t presented again.

I hadnā€™t added it to the integration because I was just experimenting and only watching the web_server output.

Someday I will do another experiment with an ESPHome device with no api: component. My guess is that the device was periodically checking for the API.

1 Like
6

You can also disable, in ESPHome, the automated reboot-on-no-HA-connection.

Look for ā€˜reboot_timeoutā€™ here: Native API Component ā€” ESPHome

7

Thanks, I didnā€™t know that existed. There are times that I donā€™t want to configure a device into the ESPHome integration, like this experiment with an LDR sensor.

Bottom line, though, adding the device to the integration has solves the erratic behavior.

8

See the esphome FAQ for reboot reasons (WiFi, API, MQTT)

ESPHome reboots on purpose when something is not going right, e.g. wifi connection cannot be made or api connection is lost or mqtt connection is lost. So if you are facing this problem youā€™ll need to explicitly set the reboot_timeout option to 0s on the components being used.