How to ignore further input state changes after a first state change

ESPHome
1

Hi,

I would like to use a Shelly dimmer (integrated into HomeAssistant via esphome) to dim the lights above the entrance door. The complication is that those lights are connected to a stairway lighting timer that makes them blink several times before switching off all lights.

I’d like to configure the esphome firmware for the Shelly dimmer in such a way that it does turn the entrance lights on once a switch is pressed in the stairway. But then ignores the additional “off” state changes generated by the stairway lighting timer so that the entrance lights don’t blink (and only those in the stairway do).

Is there a way to make esphome trigger once e.g. via “on_state” and then to ignore any further state changes, within a certain time window thereafter?

Thanks a lot for your help with this!

2

I not sure if you converted the shelly to esphome or if your using the shelly as normal. What I would do is use the shelly as normal and use HA as the timer and include conditions in your automation to do what ever you like…

if you are using esphome then yes you can do it under conditions… if you need help in your code we will have to see your code to help further…but…where is your timer is it sand alone or is it in HA or ESPHome. Looks like it is stand alone timer and when it turns off AH and or ESPHome see the state change and then turns it back on causing the “blink”. I would recommend using HA to control everything. Below is examples of conditioning in ESPHome.

3

You might pretend it’s a ‘debounce’ problem, for which ESPHome already has parameters for binary sensors (to deal with physical switch bouncing).
Normally, debounce timeouts are in the range of a few miliseconds, but in your case they might also be helpful with longer timings, in the range of several seconds.

4

Thanks for your reply. Yes, I flashed esphome on the Shelly and, ideally, the described behaviour would work without HA (I like to have as much functionality implemented standalone in esphome, e.g. in case the HA machine is down or so).

This is what I currently have in terms of code:

substitutions:
  device: entrance
  device_upper: Entrance

esphome:
  name: $device
  platform: ESP8266
  board: esp01_1m
  board_flash_mode: dout
  platformio_options:
    board_build.f_cpu: 80000000L
  arduino_version: latest

wifi:
  ssid: 'X'
  password: 'Y'
  fast_connect: True
  
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "${device_upper} Hotspot"
    password: "X"

captive_portal:

debug:

# Enable logging
logger:
  level: debug
  baud_rate: 0

# Enable Home Assistant API
api:
  encryption:
    key: "X"

## Use time
time:
  - platform: homeassistant
    id: homeassistant_time
    timezone: Europe/Berlin

# Text sensors with general information.
text_sensor:
  - platform: wifi_info
    ip_address:
      name: "${device_upper} IP Address"

sensor:
  - platform: wifi_signal
    name: "${device_upper} Wifi Signal Strength"
    filters:
      - sliding_window_moving_average:
          window_size: 4
          send_every: 4

  - platform: uptime
    name: "${device_upper} Uptime"
    
  # NTC Temperature
  - platform: ntc
    sensor: temp_resistance_reading
    name: "${device_upper} Temperature"
    unit_of_measurement: "°C"
    accuracy_decimals: 1
    icon: "mdi:thermometer"
    calibration:
      b_constant: 3350
      reference_resistance: 10kOhm
      reference_temperature: 298.15K
    on_value_range:
      above: 75
      then: # Security shutdown by overheating
        - switch.turn_on: _shutdown
        
  - platform: resistance
    id: temp_resistance_reading
    sensor: temp_analog_reading
    configuration: DOWNSTREAM
    resistor: 32kOhm
    
  - platform: adc
    id: temp_analog_reading
    pin: A0
    
switch:
  - platform: shutdown
    id: _shutdown
    name: "${device_upper} Shutdown"

## Over the air update
ota:
  password: "X"
  
uart:
    tx_pin: 1
    rx_pin: 3
    baud_rate: 115200

light:
    - platform: shelly_dimmer
      name: "${device_upper} Light"
      id: roomlight
      default_transition_length: 1s
      restore_mode: RESTORE_DEFAULT_OFF
      power:
        name: "${device_upper} Power"
      voltage:
        name: "${device_upper} Voltage"
      current:
        name: "${device_upper} Current"
      min_brightness: 100
      max_brightness: 1000
      firmware:
        version: "51.5"
        update: true

binary_sensor:
  - platform: gpio
    id: sw
    internal: true
    pin: 
      number: GPIO14
    on_state:
    - if:
        condition: # only toggle relay if button is enabled
          lambda: 'return (id(select_switch).state == "Enabled");'
        then:
          light.toggle: roomlight
    filters:
      - delayed_on_off: 100ms
        
select:
    # option to disable switch
  - platform: template
    name: "${device_upper} Enable/Disable"
    id: select_switch
    optimistic: true
    options:
      - Enabled
      - Disabled
    initial_option: Enabled
    restore_value: true
    icon: mdi:circle-double
5

Thanks also to you for your reply. I actually saw the delayed_{on,off,on_off} options in the documentation and felt this could be a potential solution. But I couldn’t figure out how exactly this could be done.

As I wrote - the very first (on) signal I want the shelly to react to (switch the light on) and the following (off) signals I want to ignore.

… Thinking about this more now - I essentially need to “filter out” the off events, i.e. if I set a delayed_off time that is larger than the off signal generated by the stairway lighting timer then it should work, right?!

6

Sorry I am just not following along what your trying to do.

7

If this is all controlled in Home Assistant, then it’s easy to do.
You just write an automation that’s triggered by the Shelly’s transition to ‘on’, and don’t write one that’s triggered by its transition to ‘off’.

8

Why can’t you seperate that totally? Are both devices on one power source? You should be able to control both devices on their own, shouldn’t you? :slight_smile:

9

It should NOT be within HA but on the Shelly directly (in esphome)

10

which “both devices” do you mean? the Shelly and the time? The problem is that the LED spots that we have are way to bright so I want to dim them → By means of a Shelly between the timer and the spots. Permanent power source for the Shelly is not a problem but that the “input” coming from the timer (as is common for these) has these “blinks” where the power is briefly interrupted to indicate that the lights will turn off completely soon. Those I don’t want the Shelly to react to

11

That’s what I mean. :slight_smile:

What you’re having is this:

power -> the blink thingy -> Shelly -> light (the non flashing)
                          -> the flashing light

Can’t you seperate these things, like so?

power -> Shelly -> light
      -> the blink thingy -> flashing light

I’m asking, because I don’t see the need to run both things together, if not something else is hindering you to seperate these. It would also have the advantage, that you can control both things without the other interfering. Or am I missing something here?

1 Like
12

Your description of the ‘blinks’ makes me wonder if they might not be shelly-caused at all.

For example, I have LED lamps that, if connected to a shelly dimmer will blink (rapidly) unless I run the Shelly app’s ‘calibrate’ function, which programs the dimmer not to fall below a certain level.

13

You are right - I could, of course, but then I’d have to run new wires all the way through the house from the distribution box to the lights in my particular case. Possible but I first wanted to see whether I can do this in software :wink:

If it turns out to be impossible there is no other way than what you described.

14

I know what you mean. No, it’s not that. It’s really the stairway lighting timer that causes these blinks. They are mandatory in houses with tenants so that somebody walking the stairs knows that the light will go off soon and won’t suddenly stand in the dark.

15

Thanks for the feedback. :slight_smile: I’m sure, this is just me, but can’t you split the power at that point, where you are doing the junction right now? You should already have everything you need (in my imagination), but just need to switch some cables. :slight_smile:

I’m not sure, that I can describe properly what I’m trying to say. If you are interested I could draw a pic… :rofl:

16

If your automation is in Home Assistant, perhaps all you need is to use the “…off, for N seconds” variant of the trigger clause.
So when the stairway lights blink, they won’t be “off for at least N seconds” and your automation will ignore the blinking.
And once they go off, and stay off, your automation will trigger and do what you want, such as turn off the entry light.

17

If I understand correctly, you want to block the turn_off for some time, why don’t you use millis?
Not tested:

globals:
  - id: previousMillis
    type: unsigned long
    restore_value: no
    initial_value: '0'

  - id: timer
    type: unsigned long
    restore_value: no
    initial_value: '900000'



binary_sensor:
  - platform: gpio
    name: "Something"
    pin: 23
    on_state:
      then:
        - lambda: |-
              if (id(light1) == 0 ) {

              id(previousMillis) = millis();
              auto call = id(light1).turn_on();
              call.perform();

              } else {
              if ((millis() - id(previousMillis)) >= id(timer)) {
              id(previousMillis) = 0;
              auto call = id(light1).turn_off();
              call.perform();
              }
              }



light:
  - platform: binary
    name: "Desk Lamp"
    output: light_output
    id: light1
    
output:
  - platform: gpio
    id: light_output
    pin: GPIO16
1 Like
18

I currently don’t have a junction :slight_smile: I have one cable (live, neutral, ground) going from the timer all the way to the entrance. The timer briefly switches the power off during the mentioned blinks on this one cable.

1 Like
19

Thanks a lot, I will give this a try and report back.

Out of curiosity: How is this different from when I’d use

    filters:
      - delayed_on_off: 100ms
20

And from that cable you’re powering the Shelly? That would mean, it has no power during the off-states of the timer?

I still don’t get how you wired that all up. :open_mouth: If you have the Shelly powered via a different cable, you should be able to work totally seperated from the timer. If not, the Shelly would be powerless for some (milli)seconds, so that won’t work either.

You leave me clueless, really. :rofl: