ESPHome devices lose their connection

ESPHome
,
1

After that when I added 4th device based on NodeMCU with over ESPHome (ver. 1.14.2) add-on in HASS.IO what siting on windows virtual machine. I discovered that My devices lost connection quit offen
I added uptime sensor an it’s look like this:

35
352678×570 65 KB

Bad wifi connection is definitely not a problem.
And configuration on device is quite simple, nothing that would burden the device

esphome:
  name: akvaarium
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: "MyWIFI"
  password: "MyWifiPass"

logger:

api:

ota:
text_sensor:
  - platform: wifi_info
    ip_address:
      name: ESP IP Address garaaz
    ssid:
      name: ESP SSID garaaz
    bssid:
      name: ESP BSSID garaaz


sensor:
  - platform: wifi_signal
    name: "WiFi Signal garaaz"
    update_interval: 60s
    
  - platform: uptime
    name: Uptime garaaz
    
  - platform: dht
    pin:
      number: GPIO4
    temperature:
      name: "Garaazi Temperatuur"
    humidity:
      name: "Garaazi Õhuniiskus"
    model: DHT22
    update_interval: 60s
    
binary_sensor:
  - platform: gpio
    pin:
      number: GPIO14
      mode: INPUT_PULLUP
      inverted: true
    name: garaazi uks kinni

  - platform: gpio
    pin:
      number: GPIO12
      mode: INPUT_PULLUP
      inverted: true
    name: garaazi uks lahti

  - platform: gpio
    pin:
      number: GPIO5
      mode: INPUT_PULLUP
      inverted: true
    name: garaazi uksenupp

  - platform: gpio
    pin:
      number: GPIO13
      mode: INPUT_PULLUP
      inverted: true
    name: garaazi_PIR

  - platform: gpio
    pin:
      number: GPIO2
      mode: INPUT_PULLUP
      inverted: true
    name: garaazi_siseuks
3 Likes
2

There’s another thread here discussing wifi connection stability.
It specified using a particular ESPHome option to disable power-saving.
Links coming in a few minutes.

Couldn’t find the exact thread. What you want is this option in the wifi: section.

power_save_option: none
1 Like
3

Any tip more - still nothing
I put ping on it, and 1,5 -2 % of pings are missing

[03:07:26][D][dallas.sensor:148]: 'akvaariumi kapp': Got Temperature=22.1°C
[03:07:26][D][sensor:092]: 'akvaariumi kapp': Sending state 22.06250 °C with 1 decimals of accuracy
WARNING Disconnected from API: Timeout while waiting for message response!
WARNING Error resolving IP address of akvaarium.local. Is it connected to WiFi?
WARNING (If this error persists, please set a static IP address: https://esphome.io/components/wifi.html#manual-ips)
WARNING Couldn't connect to API (Error resolving IP address: Error resolving address with mDNS: Did not respond. Maybe the device is offline., [Errno -5] No address associated with hostname). Trying to reconnect in 1 seconds
INFO Connecting to akvaarium.local:6053 (192.168.200.92)
INFO Successfully connected to akvaarium.local
[03:08:40][D][sensor:092]: 'Uptime akvaarium': Sending state 34.15500 s with 0 decimals of accuracy
[03:08:59][D][dallas.sensor:148]: 'akvaariumi vesi': Got Temperature=25.4°C
[03:08:59][D][sensor:092]: 'akvaariumi vesi': Sending state 25.43750 °C with 1 decimals of accuracy
[03:08:59][D][dallas.sensor:148]: 'akvaariumi kõrval': Got Temperature=24.1°C
[03:08:59][D][sensor:092]: 'akvaariumi kõrval': Sending state 24.12500 °C with 1 decimals of accuracy
[03:08:59][D][dallas.sensor:148]: 'akvaariumi kapp': Got Temperature=22.1°C
[03:08:59][D][sensor:092]: 'akvaariumi kapp': Sending state 22.06250 °C with 1 decimals of accuracy
[03:09:08][D][sensor:092]: 'WiFi Signal akvaarium': Sending state -52.00000 dB with 0 decimals of accuracy
[03:09:40][D][sensor:092]: 'Uptime akvaarium': Sending state 94.14800 s with 0 decimals of accuracy
[03:09:59][D][dallas.sensor:148]: 'akvaariumi vesi': Got Temperature=25.4°C
[03:09:59][D][sensor:092]: 'akvaariumi vesi': Sending state 25.43750 °C with 1 decimals of accuracy
[03:09:59][D][dallas.sensor:148]: 'akvaariumi kõrval': Got Temperature=24.1°C
[03:09:59][D][sensor:092]: 'akvaariumi kõrval': Sending state 24.12500 °C with 1 decimals of accuracy
[03:09:59][D][dallas.sensor:148]: 'akvaariumi kapp': Got Temperature=22.1°C
[03:09:59][D][sensor:092]: 'akvaariumi kapp': Sending state 22.12500 °C with 1 decimals of accuracy
[03:10:05][I][ota:046]: Boot seems successful, resetting boot loop counter.
[03:10:08][D][sensor:092]: 'WiFi Signal akvaarium': Sending state -51.00000 dB with 0 decimals of accuracy

for aquarium solution this OK, but I want put my old PIR sensors with ESPHOME as well to HomeAssistant

4

Same time my old ESP Easy in same network and over MQTT connected to my HASS.IO
Same NodeMCU
53

devices is right now side by side

5

I struggled with my esphome bases bed sensor (hx711) doing the same thing and unfortunately didn’t find a solution as of yet. I also noticed a delay in some LEDs that was being caused by the same disconnections.
Eventually I just moved everything over to tasmota.

1 Like
6

Uptime is not how long they’re connected, it’s time since last boot.

I have some d32 boards, and recently when I tried introducing a captive portal into their config they went slowly crash looping like that. Moving back to previous firmware version made it stable again.

I think there’s a chance that the software might log the reason it’s rebooting, and that might help debugging. If you could keep it connected via serial port long enough, you might be able to find the cause.

7

I’l try with serial debug today .
And when I want change version of ESP Home - then I must but on config something like that:
esphome_version": "v1.10.0"" . ?

8

I’ve been struggling with devices not being available to HA.

The device log (Sonoff RF Bridge) shows it continually disconnecting and reconnecting to the HA API:

[18:16:11][D][time:029]: Synchronized time: Mon Jan  6 18:16:11 2020
[18:16:11][D][api:067]: Disconnecting Home Assistant 0.103.2 (10.0.1.235)
[18:16:15][D][sensor:092]: 'Sonoff RF Bridge Wifi Signal': Sending state -67.00000 dB with 0 decimals of accuracy
[18:16:17][D][api.connection:583]: Client 'Home Assistant 0.103.2 (10.0.1.235)' connected successfully!
[18:16:17][D][time:029]: Synchronized time: Mon Jan  6 18:16:17 2020
[18:16:17][D][api:067]: Disconnecting Home Assistant 0.103.2 (10.0.1.235)
[18:16:22][D][api.connection:583]: Client 'Home Assistant 0.103.2 (10.0.1.235)' connected successfully!
[18:16:22][D][time:029]: Synchronized time: Mon Jan  6 18:16:22 2020
[18:16:23][D][api:067]: Disconnecting Home Assistant 0.103.2 (10.0.1.235)
[18:16:25][D][sensor:092]: 'Sonoff RF Bridge Wifi Signal': Sending state -67.00000 dB with 0 decimals of accuracy
[18:16:28][D][api.connection:583]: Client 'Home Assistant 0.103.2 (10.0.1.235)' connected successfully!
[18:16:28][D][time:029]: Synchronized time: Mon Jan  6 18:16:28 2020
[18:16:28][D][api:067]: Disconnecting Home Assistant 0.103.2 (10.0.1.235)
[18:16:33][D][api.connection:583]: Client 'Home Assistant 0.103.2 (10.0.1.235)' connected successfully!

I have another device (Node MCU) running ESPHome and it does not have this issue.

I have, by trial and error, determined that the problem occurs when the number of ‘remote_receiver’ devices exceeds 12.

If I drop below that number I don’t get the disconnection issue.

Here’s the yaml from the RF Bridge:

esphome:
  name: rf_bridge
  platform: ESP8266
  board: esp01_1m

wifi:
  ssid: !secret wifi_SSID
  password: !secret wifi_password
#  manual_ip:
#    static_ip: 10.0.1.99
#    gateway: 10.0.1.1
#    subnet: 255.255.255.0

# Enable logging
logger:

# Enable Home Assistant API
api:

ota:

switch:
  - platform: restart
    name: "RF Bridge Restart"

time:
  - platform: homeassistant
    id: homeassistant_time

web_server:
  port: 80
  
sensor:
  - platform: wifi_signal
    name: Sonoff RF Bridge Wifi Signal
    update_interval: 10s
  - platform: uptime
    name: Sonoff RF Bridge Uptime

binary_sensor:
#  - platform: status
#    name: Sonoff RF Bridge Status

  - platform: remote_receiver
    name: Test Tamper
    device_class: motion
    rc_switch_raw:
      code: '110101110001010110011011'
      protocol: 1
    filters:
      delayed_off: 5s

### Motion Sensors ###
  - platform: remote_receiver
    name: Garage Motion
    device_class: motion
    rc_switch_raw:
      code: '110100110010001001101110'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: Telegraph Pole Garage
    device_class: motion
    rc_switch_raw:
      code: '010100011111011001011010'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: Gym Motion
    device_class: motion
    rc_switch_raw:
      code: '011100010101111111111111'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: Garage Motion 2
    device_class: motion
    rc_switch_raw:
      code: '100111110001010100001010'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: Letterbox
    device_class: motion
    rc_switch_raw:
      code: '101001101000101100100011'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: Stable Motion
    device_class: motion
    rc_switch_raw:
      code: '000101000010000110000110'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: North East PIR
    device_class: motion
    rc_switch_raw:
      code: '010101001111011001011010'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: North Central PIR
    device_class: motion
    rc_switch_raw:
      code: '010001011111011001001010'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: North West PIR
    device_class: motion
    rc_switch_raw:
      code: '010011011111011001001010'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: Garage North PIR
    device_class: motion
    rc_switch_raw:
      code: '010010011111011001001010'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: Pergola PIR
    device_class: motion
    rc_switch_raw:
      code: '010110011111011001011010'
      protocol: 1
    filters:
      delayed_off: 5s

  - platform: remote_receiver
    name: Courtyard PIR
    device_class: motion
    rc_switch_raw:
      code: '011011011111011001101010'
      protocol: 1
    filters:
      delayed_off: 5s

remote_receiver:
  pin: 4
  dump: rc_switch
  tolerance: 50
  filter: 4us
  idle: 4ms

remote_transmitter:
  pin: 5
  carrier_duty_percent: 100%

status_led:
  pin:
    number: GPIO13
    inverted: yes

There’s nothing too onerous in there.

I can’t determine if the issue is the HA API, the ESPHome firmware or a hardware limitation of the RF Bridge.

Any idea what may be causing this?

9

does it also lose wifi connection when dropping connection to HA?

did you check you don’t have a double entry in integration for that device?

10

No, it’s keeping its Wi-fi connection. It’s just the connection to HA that disconnects. From the log it looks as if it’s deliberately disconnecting rather than losing the connection.

Are you referring to a duplicate physical device i.e. Sonoff Bridge or duplicate binary sensor device?

EDIT: I’ve just checked this and there are no duplicates.

11

In my case all connection is lost - wifi and according to this the connection with HA will be lost.

1 Like
12

So a couple of other hints:

  • EspHome 1.14.x seems to be not really stable connection wise (Link), try to install dev version (1.15)
  • in my experience Esp32 (Sonoff RF is based on ESP8266) drops connection when it is too loaded by I agree should not be the case in your situation
  • I have and an ESP32 with 8 RF sensor and no issues (EspHome 1.14.3)
  • are you sure the WiFi connection is not dropping on HA side?
13

I made some debug LOG with termit - I post it here someone find there any problem ?https://www.dropbox.com/s/rti3siev3guezvv/ESPHomeLog.txt?dl=0

14

I too had severer wifi stability issues. I fixed it by setting up a 2.4G only wifi network for my sensors (esphome) devices. I have a unifi setup so it was relativity easy to setup another network (SSID) and set it to only use the 2.4G radio.

Please note that my normal wifi network has multiple access points that are not all unifi devices so the issue also could have been the esphome device hopping between access points. I have not tested fully, as now my wifi stability is rock solid.

15

Moving from ESPHome 1.13.6 to the 1.14.x branch, I had a great many difficulties with connectivity ranging from devices that simply wouldn’t connect to wifi at all, to devices that would, but would lose connection to HA.

I resolved this for myself by reverting to 1.13.6, where I remain. But I have been thinking about reverting to an MQTT-based setup. It may not dovetail as tightly with HA, but there are features of MQTT that are quite attractive, such as the protocol’s inbuilt ability to remember the last state in the event of a disconnect. I think I will start looking at this for non-lightswitch devices, where possible MQTT latency doesn’t matter as much.

16

I’m sure it’s not a WiFi issue. The log suggests that it’s actively disconnecting rather than losing the connection.

I have 62 (at the last count) binary_sensors that I’m trying to add to the bridge. A combination of motion detectors, door switches, and the associated battery low signals.

I’ll see if I can give 1.15 a try. I’m running ESPHome in docker.

17

Any news on this? I have the same issue with my D1 mini. In the logs I keep seeing messages pop up that home assistant is disconnected, followed by the successful connection of home assistant…

18

There’s an open issue for this, I just added some details about my issue, please also report yours there otherwise this will marked as stale and not fixed. It’s been going on since I updated to ESPHome 1.14.0. This problem was not there on previous versions:

19

Looking at the Dropbox logs, the abort / crash messages are definitely a sign of some kind of bug. If you temporarily remove everything other that wifi / uptime sensors and log and ota, does it live through the hour?

20

Hope these tests help narrow down the problem.