[Bug] 1.14+ Multiple time based covers on one ESP cause position errors

[sandervandegeijn]

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

Docker image esphome

ESP (ESP32/ESP8266, Board/Sonoff):

ESP32

ESPHome version (latest production, beta, dev branch)

1.14.X, 1.15 Affected component:

https://esphome.io/components/cover/time_based.html

Description of problem: I've been noticing strange behavior of my covers/screens. esphome seems to lose the position somehow, I regularly need to "calibrate" by closing and opening fully so that the actual position of the screen is in sync with the position calculated by esphome. After a reboot this is logical, but I need to do it much more often (multiple times each day)

At first I thought it was because I had 5 screens connected to this ESP and another esp8266 serving another screen does work correctly. So I replaced the ESP32 with another, same result. Disabled the 4 of the 5 screens in the config, same result. Then I added the webserver to rule out Home Assistant. Video here:

https://download.neofoto.nl/github.mp4

00:04: cover position closed, open button does not work 00:12 the switches always work 00:27 Clicked the open button in Home Assistant, get's some response but look at position: it jumps from 0% to 100%

Buttons not working again half an hour later: https://download.neofoto.nl/github2.mp4

I'm unsure how to debug further. The hardware seems okay, the switch entries that control the relays always work.

Problem-relevant YAML-configuration entries:

esphome:
  name: screensfront
  platform: ESP32
  board: esp-wrover-kit

<<: !include common.yaml

web_server:
  port: 80

switch:
  - platform: gpio
    pin: 32
    inverted: yes
    id: "gpio32"
    name: "Screensfront GPIO32"
    restore_mode: "ALWAYS_OFF"
  - platform: gpio
    pin: 18
    inverted: yes
    id: "gpio18"
    name: "Screensfront GPIO18"
    restore_mode: "ALWAYS_OFF"

cover:
  - platform: time_based
    name: "Bay window left"
    open_action:
      - switch.turn_on: gpio32
    open_duration: 34s
    close_action:
      - switch.turn_on: gpio18
    close_duration: 33s
    stop_action:
      - switch.turn_off: gpio32
      - switch.turn_off: gpio18

Common.yaml

wifi:
  ssid: "X"
  password: "X"

mqtt:
  broker: X.lan
  discovery: True

logger:
  level: DEBUG

ota:
  password: 'X'

time:
  - platform: sntp
    id: sntp_time
    timezone: "Europe/Amsterdam"

Logs (if applicable):

I've dumped the debug log to a file for a whole night; unit seems stable. Noticed the problem also in the time frame, maybe there is something to be seen in the log:

screensfront.log

Additional information and things you've tried:

[sandervandegeijn]

Okay, have been testing further. With only one cover active everything seems okay after a few days. Maybe it does have something to do with the number of covers used on one ESP. My other sunscreen on a seperate ESP with only one cover active has been fine for months.

Upping to two screens active on one ESP.

[sandervandegeijn]

Okay, I think I found it. Adding the second cover almost immediately triggers the problems described in the first post.

[probot-esphome[bot]]

cover source cover issues cover recent changes _{^{(message by IssueLinks)}}

[sandervandegeijn]

Okay, built two new units, same problem again unfortunately.

[sandervandegeijn]

Okay, configuring multiple covers on one unit does not immediately triggers the problem. Using one of the configured entries while not using the others works okay. Problems start when you start to use multiple covers, the positions seem to be confused.

[stale[bot]]

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.

[sandervandegeijn]

Still valid..

[stale[bot]]

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.