esphome / issues

Issue Tracker for ESPHome
https://esphome.io/
290 stars 35 forks source link

Shelly i3 GPIO inputs bouncing #1459

Closed craggyh closed 3 years ago

craggyh commented 4 years ago

Operating environment/Installation (Hass.io/Docker/pip/etc.):

ESP (ESP32/ESP8266, Board/Sonoff):

Shelli i3 esp8285 **ESPHome version (latest production, beta, dev branch)**

Affected component:

Description of problem: Esphome flashed to Shelly i3 doesn’t behave as it does with other Shelly devices. The i3 has 3 inputs tied to Gpio12/13 and 14.

When a binary sensor is configured to use the gpio with input_pullup disabled the Sensor bounces between off/on continuously and doesn’t respond to the input being triggered. When configured with input_pullup enabled there is no response at all from the input line being switched.

I presume the inputs are in a floating state at boot but would have expected them to behave once the internal pull-up is enabled.

Problem-relevant YAML-configuration entries:

PASTE YAML FILE HERE

Logs (if applicable):

PASTE DEBUG LOG HERE

Additional information and things you've tried:

craggyh commented 4 years ago

@OttoWinter Any idea what needs to be done to get the i3 reading inputs correctly? I loaded the latest Tasmota on one of them and set the input type as switchN and it reads the inputs fine. Maybe it’s something simple I’m missing in esphome.

martinjuhasz commented 4 years ago

seems like more people are having the problem with floating inputs on the shelly i3

https://github.com/RavenSystem/esp-homekit-devices/issues/1049

craggyh commented 4 years ago

Yeah, these devices are becoming more popular because of their size and 3x inputs. I have some working with Tasmota without any issues but i hate MQTT for switches because of all the duplicate automation crap Homeassistant has to do. I really hope we can get Esphome working on these as it's waaaay better than Tasmota.

martinjuhasz commented 4 years ago

I tried both INPUT and INPUT_PULLUP without luck.

esphomeyaml:
  name: $deviceid
  platform: ESP8266
  board: esp01_1m
  board_flash_mode: dout

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO12
      mode: INPUT
    name: 'Switch 1'
    id: sensorid1
  - platform: gpio
    pin:
      number: GPIO13
      mode: INPUT
    name: 'Switch 2'
    id: sensorid2
  - platform: gpio
    pin:
      number: GPIO14
      mode: INPUT
    name: 'Switch 3'
    id: sensorid3
martinjuhasz commented 4 years ago

With help from EuroTrash on discord i managed to get it working. You need to add a small delayed_on_off to your config and it should work fine. For me 50ms was enough. If it still happens, you might want to increase it slightly. Everything under 100ms still feels good.

esphomeyaml:
  name: $deviceid
  platform: ESP8266
  board: esp01_1m
  board_flash_mode: dout

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO12
      mode: INPUT
    name: 'Switch 1'
    id: sensorid1
    filters:
      - delayed_on_off: 50ms
  - platform: gpio
    pin:
      number: GPIO13
      mode: INPUT
    name: 'Switch 2'
    id: sensorid2
    filters:
      - delayed_on_off: 50ms
  - platform: gpio
    pin:
      number: GPIO14
      mode: INPUT
    name: 'Switch 3'
    id: sensorid3
    filters:
      - delayed_on_off: 50ms
craggyh commented 4 years ago

Excellent work :-) I tried it just now on one of my i3's and it worked perfectly with a 50ms delay. I'm curious to know what in the hardware requires the delayed_off? Never had to do that on any other esp device.

martinjuhasz commented 4 years ago

I have no idea. Tasmota has a default delay of 50ms, so i guess thats why it worked there out of the box.

craggyh commented 4 years ago

Cool, it must be as simple as that. I'm off to convert a bunch of Tasmotas back to esphome. Thanks for your help.

mattapo commented 4 years ago

It was simple, i finally can use i3. Thank you so much!!

Lovely-Maisonette commented 3 years ago

Shelly original, comes from factory with a 500ms delay. This can be configured, and the minimum value allowed is 100ms. So yes, this must be a config required by the hardware for unknown reason.

stale[bot] commented 3 years ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.