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"" . ?
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?
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?
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.
In my case all connection is lost - wifi and according to this the connection with HA will be lost.
1 Like
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?
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
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.
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.
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.
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…
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:
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?
Hope these tests help narrow down the problem.
Good point I’l be testing this as well
Config. right now is :
esphome:
name: garaazi_andurid
platform: ESP8266
board: nodemcuv2
wifi:
ssid: "ssid"
password: "pass"
power_save_mode: none
manual_ip:
static_ip: 192.168.200.56
gateway: 192.168.200.254
subnet: 255.255.255.0
dns1: 194.126.97.30
dns2: 1.1.1.1
# Enable logging
logger:
# Enable Home Assistant API
api:
ota:
sensor:
- platform: uptime
name: Uptime garaaz
let’s see what happening.
-NO same - with this config still connection is losing.
So it still disconnects with mostly bare config, interesting.
Do you still have any abort/crash messages in logs? (It looked like they were coming from temperature sensor code that you removed, but who knows if they’d be caused somewhere else)
The bare minimum configuration you quoted above should work fine, what you’re experiencing means that either something is wrong with your particular device (unlikely but possible)
… or there’s a software problem, ie. something is wrong with the code that many others are relying on, but many others might be lucky to not hit the same set of conditions as you are… This latter option, even though it’s less likely makes the issue you’re experiencing worth investigating.
You could perhaps run it with log_level: VERBOSE or log_level: VERY_VERBOSE.
Perhaps you could strip down the config even further, I’m thinking along the lines of disabling dns and gateway, removing ota since you have serial, perhaps even removing API component, which makes it impossible for it to talk to home assistant but it should still be able to hold its wifi and not reboot.
At that point I’d say you’d have enough useful information to file an official bug with @OttoWinter.
If nothing else, Otto might be able to narrow it down even more, or perhaps sprinkle some more logging to make this easier to debug.
Perhaps we should include some general debugging/troubleshooting workflows in a doc/post somewhere.
A couple of example scenarios and what ifs.
Hi, did you disconnect all your gpio inputs before trying ?
As I noticed in your original post your using gpio 2
Can you share the code for how you implemented the uptime sensor? I’m having the exact same issue with all my NodeMCUs. I’d like to track iuptime as well to see just how bad it is. I really like the ESPhome features, especially the ease of deployment and monitoring. It would be a real shame to have to go back to MQTT, but this is driving me nuts.
1 Like
It’s just this one: https://esphome.io/components/sensor/uptime.html .
When you say “exactly the same issue”, do you mean crashes/aborts in logs, or wifi disconnects, or reboots, or stuckness, … there’s a couple of people with different underlying problems in this thread. Also, which version of nodemcu do you have, what do you have currently connected to your GPIO?
The disconnects which then resets the device- at least that’s what shows in the log. I have a dozen of these: CP2102 ESP-12E, they are ESP8266 Boards. Absolutely Rock solid using NodeMCU firmware and MQTT, even several hundred feet away from WiFi on 2.4 or 5ghz.
Right now the one under test just has a 3v relay and a push button and an led indicator. I keep it toggled on, but it randomly toggles off by itself. I installed the dev branch 1.15.0 last nite at 2am just for kicks, and toggled the switch on. It was still on at 8am when I just checked it.
I used to get log entries of connect/disconnect every few minutes but it cluttered the log so I suppressed those msgs. If it helps, I can reenable the log and post it here.
Uptime Sensor installed successfully.
Jeff