Shelly 1L SW1 bouncing when disconnected from Wi-Fi

I recently bought a Shelly 1L for experimentation before I purchase more. It is connected to the mains with the neutral wire (no bypass), and there’s a smart light connected downstream of the relay. A regular toggle light switch is connected to SW1.

The intent is to have it decoupled when it’s online, and fallback to coupled when offline. That works without any issue. I am using ESPHome addon version 2022.9.4.

However, I found an odd behaviour. When I bring the wireless network down and the relay is off and SW1 is off, then SW1 starts randomly bouncing (causing the relay to switch on/off very quickly, faster than what’s humanly possible, with random pauses between bounces). If the relay is on, it does not bounce. If the Wi-Fi is up, it does not bounce. If the switch connected to SW1 is on, it does not bounce.

A on/off delay of 50ms results in a lot of bouncing. There’s way less bouncing at 200 ms, but it still does so. Even 500 ms does not eliminate it entirely. I didn’t try larger values.

The interesting thing is that SW2 does not have this issue. If I move the on/off logic to SW2 and connect the switch to it, no issues whatsoever with a delay of 50 ms. I need to remove the actions from SW1, since the switch is permanently off, and then it bounces when the other conditions apply.

I tried removing almost everything from the config file to have a minimal test case, making it a dumb switch, and yet the bouncing persists.

Can this be a hardware or wiring issue? I’m inclined to think that it is a software issue, because how else it would manifest only when Wi-Fi is off?

My config with actions attached to SW1 (so it bounces):

substitutions:
  device_name: "my-switch"
  light: "light.my_light"
  debounce: "50ms"

esphome:
  name: ${device_name}
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: ${device_name}
    password: !secret wifi_password
captive_portal:
logger:
api:
ota:

switch:
- platform: gpio
  pin: GPIO5
  id: power
  name: "${device_name}: power"

binary_sensor:
- platform: gpio
  pin:
    number: GPIO4
  id: switch_1
  name: "${device_name}: switch 1"
  filters:
  - delayed_on_off: ${debounce}
  on_press:
    then:
    - switch.turn_on: power
    - if:
        condition:
          and:
            - wifi.connected:
            - api.connected:
        then:
        - homeassistant.service:
            service: homeassistant.turn_on
            data:
              entity_id: ${light}
  on_release:
    then:
    - if:
        condition:
          and:
          - wifi.connected:
          - api.connected:
        then:
        - homeassistant.service:
            service: homeassistant.turn_off
            data:
              entity_id: ${light}
        else:
        - switch.turn_off: power
- platform: gpio
  pin:
    number: GPIO14
  id: switch_2
  name: "${device_name}: switch 2"
  filters:
    - delayed_on_off: ${debounce}

sensor:
  - platform: ntc
    sensor: temp_resistance_reading
    name: "${device_name}: 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: "80.0"
        then:
          - switch.turn_off: power
  - platform: resistance
    id: temp_resistance_reading
    sensor: temp_analog_reading
    configuration: DOWNSTREAM
    resistor: 32kOhm
  - platform: adc
    id: temp_analog_reading
    pin: A0

status_led:
  pin: GPIO0
  id: led

This seems very similar to this other report.

I’m seeing something that I’m sure has the same root cause, tho I haven’t investigated as deeply as you.

I have two 1Ls, both in marginal WiFi reception (1 more than the other). Occasionally, I find them having turned on uncommanded. Looking at the HA logs, this event is clearly associated with a WiFi disconnection/reconnection.

I’m looking at a local automation to turn off on WiFi reconnect as a workaround, but ofc that doesn’t resolve the underlying issue, and leave local control when isolated non-functional.

Must be a software issue…