Home Assistant API repeatedly disconnects

[bk8190]

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

Hass.io latest v143 running on Debian on KVM, Home Assistant version 0.87.1

ESP (ESP32/ESP8266/Board/Sonoff):

ESP8266 (Both Lolin D1 Mini and Sonoff S21)

Affected component:

https://esphome.io/components/api.html

Description of problem: I use the HTTP API and my Home Assistant shows that all of my boards (Lolin D1 Mini and Sonoffs) temporarily become "unavailable" about 20-30 times per day. They always reconnect within several seconds of becoming unavailable

Sometimes it happens to multiple devices at once, where multiple devices drop out at once and then rejoin several seconds later.

Problem-relevant YAML-configuration entries:

esphomeyaml:
  name: test_esp
  platform: ESP8266
  board: d1_mini

wifi:
  ssid: 'abc'
  password: '123'

  manual_ip:
    static_ip: 192.168.86.X
    gateway: 192.168.86.1
    subnet: 255.255.255.0

# Enable Home Assistant API
api:
  password: "secret"
ota:
  password: 'secret'

# Enable logging
logger:

i2c:
  scan: False

sensor:
  - platform: sht3xd
    temperature:
      name: "Test Temperature"
      filters:
        - lambda: return x * (9.0/5.0) + 32.0;
      unit_of_measurement: "°F"
    humidity:
      name: "Test Humidity"
    address: 0x45
    update_interval: 30s

  - platform: bh1750
    name: "Test Illuminance"
    address: 0x23
    update_interval: 30s

binary_sensor:
  - platform: status
    name: "test_esp status"

  - platform: gpio
    device_class: motion
    name: "Test Motion"
    pin:
      number: D3
      mode: INPUT_PULLUP

Traceback (if applicable):

Home Assistant logs:
2019-02-12 15:55:05 INFO (MainThread) [aioesphomeapi.client] 192.168.86.X: Ping Failed!
2019-02-12 15:55:05 INFO (MainThread) [homeassistant.components.esphome] Disconnected from ESPHome API for 192.168.86.X
2019-02-12 15:55:05 INFO (MainThread) [aioesphomeapi.client] 192.168.86.X: Error while reading incoming messages: Error while receiving data: 0 bytes read on a total of 1 expected bytes
2019-02-12 15:55:07 INFO (MainThread) [homeassistant.components.esphome] Can't connect to ESPHome API for 192.168.86.X: Timeout while waiting for API response!
2019-02-12 15:55:07 INFO (MainThread) [homeassistant.components.esphome] Trying to reconnect in 2 seconds
2019-02-12 15:55:07 INFO (MainThread) [aioesphomeapi.client] 192.168.86.X: Error while reading incoming messages: Error while receiving data: 0 bytes read on a total of 1 expected bytes
2019-02-12 15:55:09 INFO (MainThread) [homeassistant.components.esphome] Successfully connected to 192.168.86.X

ESP logs (via USB):
[D][sensor.bh1750:090]: 'Test Illuminance': Got illuminance=0.0lx
[D][api:241]: 'Home Assistant 0.87.1 (192.168.86.Y)' disconnected.
[D][sensor.sht3xd:083]: Got temperature=26.79C humidity=30.06%
[D][sensor.sensor:131]: 'Test Temperature': Sending state 80.22523 F with 1 decimals of accuracy
[D][api:241]: 'Home Assistant 0.87.1 (192.168.86.Y)' disconnected.
[D][api:531]: Client 'Home Assistant 0.87.1 (192.168.86.Y)' connected successfully!
[D][sensor.bh1750:090]: 'Test Illuminance': Got illuminance=0.0lx

Additional information: Let me know if I can get additional info - e.g. increasing log verbosity

[OttoWinter]

It seems like two Home Assistant instances (or two integrations) are connecting to ESP (two disconnect messages). Please see the integration screen on HA and see if there are duplicate entries.

Also, the native API is not an "HTTP API". It is a custom TCP protocol (and has much lower overhead than http).

[bk8190]

Hi Otto, Thanks for the response! I have been also having duplicate entity problems. Upon rebooting HA, sometimes the esphome integration will create a new "sensor.test_temperature_2" in addition to "sensor.test_temperature". I only have one HA instance. To fix this, I have to remove the entities from the entity registry, remove the integration, and re-add it.

One thing that may be relevant... I've been having Docker DNS issues where my Hassio esphomeyaml container cannot resolve "test_esp.local", so I have been using the bare IP address to connect.

Could this be some kind of issue with the asynchronous HA logic?

[brandond]

Were you previously using MQTT instead of the native API? If so, you may need to clean out the discovery topics. It's mentioned in the MQTT->API migration docs but it seems like a lot of folks skip it.

[bk8190]

I have the MQTT discovery turned off. The problem seems to have resolved itself, over the past few days it has been much more stable... I will update if the problem comes back

[OttoWinter]

Closing due to inactivity