Intermittent connection issues with bk72xx ESPHome devices #280
Comments
|
You'll need to provide logs from the ESPHome side (and probably with Verbose level), not the HA side. The HA side includes no context of why/how it disconnected, only that it has. |
|
I am able to get the OTA logs, but they really don't seem to tell me much: Because this is a "CloudCut" device, I don't know how to access the serial logs directly. Looks like the device reboots at 15:03 and the OTA access is cut off. Memory looks good, but no other tell tale signs. Im not afraid to solder to get access to the logs via a serial port, but don't really know where to get started on this task. |
|
You'll need the logs of when the disconnect actually happens, OTA likely won't be helpful and you'll need a serial connection. |
|
Am I right in assuming I will need to solder "something" to get a serial connection to a "CloudCut" device? |
|
Yes, you would likely need the 3.3V/GND/TX2 pins soldered to receive logs. |
|
This will take me some time but I will dig into this. These switches are awesome, would be great if they were more "bulletproof". |
|
Not sure what module that device has, but be aware some modules do not have an accessible TX2. If that is the case, you'll have to configure the logger component to change the hardware uart port to TX1 via https://esphome.io/components/logger?highlight=hardware_uart if that is the case. |
|
Also, it's worth throwing an uptime sensor on the device to see if the device is rebooting when it disconnects, and if so, a debug reset_reason sensor to hint to why. |
OK, the switches I am using contain a WB3S Module with an integrated BK7231T chip. This Video gives me what I need to make the connections. I don't want to fry anything (including but not limited to... ME) so I have been poking around to understand what I do after I make these connections. I know to connect the newly soldered leads to my USB Serial Converter Adapter and then to my PC. From here, I can access the serial logs via the ESPHome dashboard. My question is: do I then wire the light switch back up to 110v power while the USB is connected to my PC? Everywhere I read, this was a no-no when flashing devices to the old-fashioned way... |
No, absolutely not, you will fry the device if you are hooked up to both. Hopefully the TTL you use will be able to sufficiently power the module (but the device won't have full physical functionality). |
|
Thanks for confirming, that's what I thought. Well, it won't be an apples-to-apples comparison, but since the behavior is independent of controlling the relay, I hope we will see the same behavior. I will get back to this thread as soon as I can give this a go. Thanks again for responding. |
|
I have a similar device and on some hard reboot it goes from becoming bad to ok, Let me explain - I had enabled ALL logs but saw nothing out of the ordinary. The only thing I think that might help is a Watchdog timer reset was the reason for the reboot. 
The device starts bad and becomes ok on 21st April hard reboot. Later it goes bad again on 23rd April till 27th April. It went bad again today morning. Also attaching the uptime from the same time for 2 other libre devices which are working great. Do note in this image my problematic device's uptime is a very small set of spikes. 
Below is my YAML (I have also removed all unnecessary blocks removed but nothing helped). |
|
@Cossid - I have made good progress with soldering up connections to a Treatlife SS01 3-way switch.
Pins are hooked up as documented on the WBS3 Data Sheet.
1 - VSS (3.3V) When powered up, I can access the Here is what I have at the moment that is NOT working: I'm researching now if I need a |
|
No, you don't need the UART section to view logs. You've connected the wrong UART port, you need TX2 to view logs - TX1 is for flashing only. Refer to LibreTiny pinouts: |
Man @Cossid said TX2 didn't he... Thank you I will adjust. |
|
@tyzen9 Are your uptimes similar to mine - 57s and 117s? |
I think we might be experiencing different symptoms - although, to be fair, I have not measured uptime as closely. My main issue is that my Treatlife (Tuya) switches become unavailable. During this time, the LED indicator on the face of the plate becomes red, and any automation executing at this time will fail. I am trying to correlate these |
I am now seeing the logs via serial connection. 🎉 I am tailing the One annoyance is that the serial logs do not contain a timestamp like the OTA logs. I'm looking into ways to add a timestamp to the serial logs but I am coming up empty so far. |
I think it might be the same issue as I too see similar logs. Lets hope there is a fix for ur isssue and I can apply the same to see if it fixes my problem. |
|
Good news, I was able to capture the error via the USB serial connection twice in the past 12 hours. Here is the most recent output from the serial logs: https://pastebin.com/eFNNKvsr Looks like the wifi is just randomly disconnecting, and then struggling to reconnect. I can assure you that no WiFi issue with any other devices correlate with this messaging. Here is what is logged in Where do we go from here? |
I think we might both be seeing the same issue. I used to see similar issues with WiFi and I ended up adding another AP right next to the device. It did not help at all. I am now eagerly waiting for a solution and I am quite confident it will fix my issue and give me the confidence to move a few more devices from OpenBeken to ESPHome. |
|
Agreed, and I do not think that WiFi is my issue, I think it is something in ESPHome/libretiny. However, I feel compelled to make 100% certain there is no issue with my WiFi dropping. When connected, my ESPHome devices report a consistently solid signal strength so I do not think I have a range issue. That said I am looking for a free tool I can install on my laptop or mobile device to monitor my WiFi connectivity throughout the day. Any wifi connectivity monitoring software recommendations? |
|
Any updates? |
|
I was wondering the same thing. I really do not know where to go from here. My only thought was to find some software to closely monitor my wifi to make sure its not an issue with my network - but I'm not sure where to start here. |
Did you look at your uptimes? |
Hi everyone - any thoughts on this? After I posted this message, responses went cold... @rishabmehta7 I will process a graph for you and post it later this week, I have been traveling and not spent much time on this since the feedback went cold. |
not that I can help you in any way, but I'm just curious did you also redact ssid? or is it just empty her. on none of the connected/disconnected lines I actually see the ssid. |
|
Similar issue for me device keeps disconnecting randomly. I couldn't even flash OTA update until I stop my HA docker container. Without HA using the the esphome api to connect to the device it works flawlessly forever without any reboot.
Compiled yaml substitutions:
DEVICE_NAME: wiprobulb01
FRIENDLY_NAME: WiproBulb01
IP: 192.168.0.75
esphome:
name: wiprobulb01
build_path: build/wiprobulb01
friendly_name: ''
area: ''
platformio_options: {}
includes: []
libraries: []
name_add_mac_suffix: false
min_version: 2024.6.1
bk72xx:
board: generic-bk7231n-qfn32-tuya
framework:
version: 1.5.1
loglevel: WARN
debug: []
sdk_silent: all
gpio_recover: true
options: {}
source: null
family: BK7231N
component_id: bk72xx
wifi:
manual_ip:
static_ip: 192.168.0.75
gateway: 192.168.0.1
subnet: 255.255.255.0
dns1: 192.168.0.1
dns2: 0.0.0.0
ap:
ssid: WiproBulb01 Fallback AP
password: "redacted"
ap_timeout: 1min
domain: .local
reboot_timeout: 15min
power_save_mode: NONE
fast_connect: false
passive_scan: false
enable_on_boot: true
networks:
- ssid: "redacted"
password: "redacted"
priority: 0.0
use_address: 192.168.0.75
captive_portal: {}
ota:
- platform: esphome
version: 2
port: 8892
logger:
baud_rate: 115200
tx_buffer_size: 512
deassert_rts_dtr: false
hardware_uart: DEFAULT
level: DEBUG
logs: {}
api:
port: 6053
password: ''
reboot_timeout: 15min
mdns:
disabled: false
services: []
web_server:
port: 80
version: 2
enable_private_network_access: true
include_internal: false
ota: true
log: true
css_url: ''
js_url: https://oi.esphome.io/v2/www.js
text_sensor:
- platform: libretiny
version:
name: LibreTiny Version
disabled_by_default: false
icon: mdi:cellphone-arrow-down
entity_category: diagnostic
output:
- platform: libretiny_pwm
id: output_red
pin:
number: 8
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
analog: false
inverted: false
zero_means_zero: false
frequency: 1000.0
- platform: libretiny_pwm
id: output_green
pin:
number: 24
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
analog: false
inverted: false
zero_means_zero: false
frequency: 1000.0
- platform: libretiny_pwm
id: output_blue
pin:
number: 26
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
analog: false
inverted: false
zero_means_zero: false
frequency: 1000.0
- platform: libretiny_pwm
id: output_cold
pin:
number: 7
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
analog: false
inverted: false
zero_means_zero: false
frequency: 1000.0
- platform: libretiny_pwm
id: output_warm
pin:
number: 6
mode:
output: true
input: false
open_drain: false
pullup: false
pulldown: false
analog: false
inverted: false
zero_means_zero: false
frequency: 1000.0
light:
- platform: rgbww
id: light_rgbww
name: Light
color_interlock: true
cold_white_color_temperature: 153.84615384615384
warm_white_color_temperature: 370.3703703703704
red: output_red
green: output_green
blue: output_blue
cold_white: output_cold
warm_white: output_warm
disabled_by_default: false
restore_mode: ALWAYS_OFF
gamma_correct: 2.8
default_transition_length: 1s
flash_transition_length: 0s
constant_brightness: falseI can control the device like this and it works every time. |
Have you tried using MQTT instead of the esphome/homeassistant API connection? |
|
Nope, It was unstable so I reverted to the original firmware of my device, which is tuya based. Now I am using local tuya to connect to HA .. although it offers less control of the device than esphome but for now I prefer stability over features. |
|
I had the same issues with an SHP102. Changed the libretiny version to 1.6.0 and at least 1 device is now running for a day without issues. Will flash the other devices and test them as well. |
This is a great idea - I will give this a try in the coming week or so and report back. |
@joukio Interested in how you went over the last 3 days with v1.6.0? |
|
Flashed some other shp102's as well, and they are all doing ok. Haven't seen any disconnects |
|
Thanks. Any tips on how you built the firmware using 1.6.0?
…On Sat, 31 Aug 2024, 05:06 Jouk Hettema, ***@***.***> wrote:
Flashed some other shp102's as well, and they are all doing ok. Haven't
seen any disconnects
—
Reply to this email directly, view it on GitHub
<#280 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQ6R7GGRJCVYJJZVSF63X3ZUC7DTAVCNFSM6AAAAABGY5TMBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRSGE3TIOJVGU>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
From esphome within homeassistant: substitutions:
devicename: "shp102-ff5fb7"
esphome:
name: shp102-ff5fb7
friendly_name: shp102-ff5fb7
bk72xx:
board: generic-bk7231n-qfn32-tuya
framework:
version: 1.6.0
loglevel: debug
debug:
- wifi
- ota
# Enable logging
logger: |
|
Thanks, I've just added that to my Aldi-bought Bauhn 5-way powerboard. It's been "ok" lately but I'll see if I get any troubles now with 1.6.0. |
|
Wow @joukio. All this time, and I thought that the LibreTiny would update to the latest version if one was not specified. I updated one of my MANY Treatlife switches to 1.6.0 just now. I will keep an eye on it and report back. Is this because the "recommended" framework version still points to 1.5.1? What is the catalyst to 1.6.0 becoming "recommended"? reference: https://esphome.io/components/libretiny.html |
|
I changed all 19 of my TreatLife (Tyua) devices to LibreTiny 1.6.0, and restarted home assistant. Sadly, I am still seeing these in my logs: |
|
just a comment on my side, |
|
Here is something interesting, this has been running since last night now and I'm still getting the message I listed above -- However, EOF errors for all my TreatLife SS01 and SS01S switches have stopped. EOF Errors persist for:
@joukio - Any idea why these devices would behave differently? NOTE: All my ESPHome YAML for these devices is located here: https://www.tyzen9.com/HomeAssistant/Devices/TuyaDevices |
|
I can't tell why the error happens, but as a suggestion I might add that the DS devices likely have TuyaMCU inside, while the SS devices probably don't. |
|
@kuba2k2 - that's a great call out. Looking here: https://esphome.io/components/tuya.html the only intriguing that is mentioned is:
I can't help but wonder if I should look at OpenBeken 🤔 |
|
having a closer look, I have the following my board is configured like this for all 3 of the devices. I don't know if this is TuyaMCU or not, but I actually just assumed the devices have a poor wifi antenna. |
|
I don't know which change in 1.7.0 does the trick, but with this new version. |
|
I will try 1.7.0 today on my TreatLife TinyMCU switches today and report back. Thanks @bkbartk |
|
OK I updated to 1.7.0 on all my TreatLife TinyMCU switches here are the results after 21 hours:
As always, I am happy to help support this. I can connect to the serial ports and provide logs, whatever might help to get the Dimmers to have the same results. Thank you for helping resolve the DS03 EOF issues! |
|
Libretiny v1.7.0 is now deployed by default with ESPHome in HomeAssistant. |
|
What I recently realised was my device had a bad capacitor that made the supply voltage less than 5V. This caused the beken to go into the reboots. Just check if your Vcc is stable 5V. |
|
Thanks, it's also been stable for me since using 1.6.0.
…On Fri 21 Jun 2024, 13:33 Tanishq Manuja, ***@***.***> wrote:
Similar issue for me device keeps disconnecting randomly. I couldn't even
flash OTA update until I stop my HA docker container.
—
Reply to this email directly, view it on GitHub
<#280 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGLJT4LTIFR3LS2BT7VJATZIP6Q3AVCNFSM6AAAAABGY5TMBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBSGQ4DONBXG4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
|
Testing a Milfra MFA05F which has a Tuya MCU, I see the same EOF disconnect errors. Sure seems like that is a Tuya MCU issue. |
I have been struggling with this for quite sometime. Many posts exists concerning ESPHome WiFi connection issues resulting in "EOF received" and "Connection reset by peer" messages in HA logs when using libretiny. Links to some of these discussions are at the bottom of this message.
I have 13 TreatLife (Tyua) switches that I have put ESPHome on using CloudCutter. For the most part, these devices are functional. However, they are constantly flipping between available and unavailable resulting in a ton of unnecessary state checking login my automations to prevent lights from randomly turning on/off.
I am using the Latest version of HA (2024.4.3) and ESPHome (2024.4.0) on a Raspberri Pi 4 with 8GB of RAM.
Let's take just one TreatLife DS01C device as an example.
I see THOUSANDS of warning messages like these a day in the HA logs for all 13 of these ESPHome devices that look like this:
Here is a portion of my config for a device
What suggestions does anyone have for helping me to troubleshoot these error messages and make them go away for good!!
There are extensive conversations in several places here are some examples:
ESPHome advised that
The text was updated successfully, but these errors were encountered: