All the devices are ESP8266, all use ESPHome. They are from a variety of origins. Some are Adafruit Huzzah, some are impostor Wemos D1 Minis, some came embedded in a variety of Sonoff switch-plugs a few came in Etekcity/VeSync plugs from Amazon.
OpenWRT 21.02.1
I will test it, maybe tomorrow.
Did you get to test the default driver or did you go straight to non-CT?
Since dropouts were bound to happen eventually using the default composition, I replaced them with non-CT before putting the AP into service.
Changed to non-CT on one of my AP just to see how it goes. Updated one esphome device and no problem, but I was only having occasional problem anyway.
I’m already seeing random dropouts on the devices that have more distance to the AP (weaker signals), so sadly it doesn’t look like the driver change solved it.
I updated to version 21.02 with non-CT drivers/firmware last night.
It did not resolve and it seems that it is worse.
Before upgrading I used the D1 mini that was with ESPhome and installed the tasmota, and although the Sonoff mini works fine with the tasmota, the D1 mini did not work well on the main AP.
Archer C2:
Archer C7:
I’ll test with version 21.02 without changing drivers/firmware, but until I solve this problem I won’t use any more board with ESP8266, since returning the main AP to the original firmware is not an option today that suits me.
Despite preferring OpenWRT, I’m sticking with factory AP firmware until this is solved.
And I remembered something: At one point I, like you, was using the OpenWRT integration in HA for device tracking.
I abandoned it long ago because it did not reliably report departures for me.
e.g., If I turn WiFi ‘off’ on a phone, OpenWrt would trigger a departure event promptly, as one would hope and expect.
However, if I just walk or drive away, the WiFi ‘session’ (or whatever’s the proper term) doesn’t terminate right away. The AP seems to just wait for the device to reappear on the air, and only terminates it (and report departure) after several minutes to hours. This wasn’t acceptable.
So having OpenWRT installed wasn’t as useful as I’d hoped for device tracking.
Ping on the other hand has proven very consistent as a way of telling if a device is on the LAN or not, and it can be tuned to tolerate devices like phones which may drop offline and only go online for brief periods when their screen is off.
Which OpenWRt integration are you talking about?
I now use UBUS and another device tracker from rmoesbergen.
For me it’s quite reliable, I use UBUS (to avoid false negative with iphone) on C7 and rmoesbergen tracker on C7 and C2. UBUS takes a little longer to close the session and when I leave the house I’m always connected to C2, so it can’t take long to close the session
As soon as I get home, the devices are detected and the departure delay, if I’m not mistaken, is 1 to 3 minutes, I have to check.
Before I started using Home Assistant, I was able to create a firmware to run on ESP32, log into Archer C2 with the original firmware (it was my main router at the time) and return the connected MACs to me, this way I was able to activate or deactivate the alarm system, but it had this delay that you say to end the session, if I’m not mistaken I only managed to reduce this delay after removing Bind ARP, or something like that.
Bit off topic but I’m curious, how did you all get uBus integration working? When I enable it, all I get is this error:
home-assistant.log.1:2021-12-12 01:57:29 INFO (MainThread) [homeassistant.components.device_tracker] Setting up device_tracker.ubus
home-assistant.log.1:2021-12-12 01:57:34 ERROR (MainThread) [homeassistant.components.device_tracker] Error setting up platform legacy ubus
home-assistant.log.1: File "/usr/src/homeassistant/homeassistant/components/device_tracker/legacy.py", line 245, in async_setup_legacy
home-assistant.log.1: File "/usr/src/homeassistant/homeassistant/components/ubus/device_tracker.py", line 43, in get_scanner
home-assistant.log.1: File "/usr/src/homeassistant/homeassistant/components/ubus/device_tracker.py", line 87, in __init__
I’ve confirmed it’s reachable with curl.
It’s always worked in my experience, and all I’ve had to do is follow the steps here:
As an extra data point: I started experiencing issues with my ESP8266-based ESPHome devices after introducing an Archer C7 v5 AP running OpenWrt 21.02.
Seems to affect a random ~50% of ESP8266-based ESPHome clients attached to that AP, 10-20% packet loss, delayed response to commands from Home Assistant & device regularly becomes unavailable. And OTA upgrade timeouts. Sometimes e.g. light 1 is fine and light 2 is unreliable, other times (with a different set of clients associated with the AP?) the issue is reversed.
ESP32-based ESPHome devices seem to be unaffected
No issue with any clients attached to my existing APs, Archer C7 v2 & hAP ac also running OpenWrt 21.02 with pretty much identical config.
I’ve tried swapping channels, switching from ath10k-ct to ath10k firmware & drivers (not that I thought that would help as that’s the 5GHz radio…), and switching to a build of OpenWrt 22.03.
Common denominator seems to be the Archer C7 v5, I’ve disabled its 2.4GHz radio in the meantime though I intend to do some packet sniffing to try and narrow down further. Maybe this affects all QCA9563 based devices running OpenWrt but I don’t have access to any others to test.
I and others have wrangled this problem for a few years. Several old threads on here with plenty of discussion, ‘try this’, ‘try that’ and nothing ever seems to work.
The only thing that fixed it for me on the A7 was to install the factory firmware which handled ESP’s like a charm. But I hated that I could not use OpenWrt.
For me, then, the final solution was to ‘accidentally’ brick my A7v5 and replace it with a Cudy wr2100 running OpenWrt. Works a treat. Perfect link maintenance, regardless of signal levels.
Glad to be rid of that problem.
(oh, and the bricking of the A7 was really an accident, although it may have been subconscious on my part, as I typed an ‘erase all’ command to the bootloader while desparate to get it to accept a flash of an updated OS. Of course, the bootloader dutifully erased itself before I’d realized the mistake. With no JTAG, the board became unrecoverable.)
Can’t say enough about the Cudy, though. Same price point, different chipset and thus different drivers.
ESPHome’s WiFi stack seems quite happy with it.
I do hope you find a solution you are happy with.
Hello.
Any news about this problem?
Lately I’ve been more careful before updating the ESPHome version, so I’ve been taking a long time to update and even skipping a few versions.
It seems to me that at least from version 2022.1.2 the problem was solved.
Today I managed to upgrade 3 esp8266 from version 2022.1.2 to 2022.6.1 without any problem.
I don’t remember changing anything on my archer C7, so if you’re using any version older than 2022.1.2, I think it’s worth a try.
One more update on the subject.
After upgrading to version 2022.6.1, I no longer had problems updating via OTA, but I continued to have issues with boards being unavailable for a short period of time.
So last week I found a configuration for the router that helped a lot:
config wifi-device ‘radio1’
option ldpc ‘0’
From this:
To this:
But one of the boards was still unavailable, a sonoff touch on the same wall where the router is:
And yesterday I found this:
From this:
To this:
NONE(least power saving, Default for ESP8266)LIGHT(Default for ESP32)HIGH(most power saving)
I’ve never tried high mode as I don’t need to save power on any of these devices. I will test for a few more days, but I think now the problem is totally solved.
Sorry to bother you,
I have simular issues as you have, which means connections cutting off during OTA update and ESPHome crashing.
I thing it is related to the combination ESPHome/OpenWRT. and while not using OTA the connection is stable.
I use ESPHome 2022.9 en 2022.10 and still have issues.
Do you have any suggestions for me? personally I think it’s some advances OpenWRT setting, but I can’t figure what it is.
I can’t say what solved the problem and looking at my logbook, from 10/09 to today, I don’t see any device becoming unavailable.
I suggest changing the power_save_mode to HIGH in your yaml and changing/adding the options below in the /etc/config/wireless file on your router
config wifi-device ‘radio1’
option ldpc ‘0’
The boards I had problem are running version 2022.8.0
ESPHome crashing.
I’ve never had any problems with Esphome crashing.
Have you tried using web_server to update?
I tried all that but nothing helps.
I’m trying at the OpenWrt forum now.
power_save_mode I have high by default.
web_server update either works or craps out with the message “not enough space”.
The reason I want to use ESPHome over Tasmota is that I can maintain all my devices at one place, If update isn’t possible this kind of beats the purpose.
Crashing only happens on ESP8285, not on ESP8566.
What is your router and version of openwrt do you use?
I’ve only had issues with tplink C7, my tplink C2 has always worked, and the C7 is known to have various WIFI related issues. My C7 is with firmware 21.02.1
Can you test the update with another router or hotspot?
Using hotspot for me always worked, so I was able to relate the problem to C7/openwrt
I use OpenWrt 22.03.2(the latest as of today)
And my device is a tplink M4R.
For what I can see the issue actually is related to the ATH10k driver in OpenWrt. Also when checking other sources, it’s always only with ATH10k devices.
the only other AP I have laying around is a tplink C7, already flashed with OpenWrt, so that’s a bit of a pity.