Intermittent connection issues with bk72xx ESPHome devices

[tyzen9]

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.

• My router is an Asus RT-AX86U running Asuswrt-Merlin v3004.388.6. I have tried running this as a Mesh with another Asus router, and without the Mesh (makes no difference)
• DHCP Lease time is set to 24 hours
• I have tried disabling the web portal (makes no difference)
• I have tried rebooting the router (makes no difference)
• I have tried eliminating all unnecessary YML diagnostic checks, logging, debugging and web_server (makes no difference)
• I have NOT tried static IP address. I want to avoid this if at all possible for simplicity, and the logs do not seem to indicate the IP address is changing

Let's take just one TreatLife DS01C device as an example.

• Device Name: dimmer-wd07
• LibreTiny Version: v1.5.1
• WiFi Signal: -37 dBm

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:

2024-04-25 08:14:35.560 WARNING (MainThread) [aioesphomeapi.connection] fan-wf02 @ 192.168.9.221: Connection error occurred: [Errno 104] Connection reset by peer
2024-04-25 08:14:46.942 WARNING (MainThread) [aioesphomeapi.connection] fan-wf02 @ 192.168.9.221: Connection error occurred: [Errno 104] Connection reset by peer
2024-04-25 08:19:45.406 WARNING (MainThread) [aioesphomeapi.connection] dimmer-wd03 @ 192.168.9.36: Connection error occurred: dimmer-wd03 @ 192.168.9.36: EOF received
2024-04-25 08:23:04.082 WARNING (MainThread) [aioesphomeapi.connection] switch-ws06-3w @ 192.168.9.14: Connection error occurred: switch-ws06-3w @ 192.168.9.14: EOF received
2024-04-25 08:23:33.763 WARNING (MainThread) [aioesphomeapi.connection] fan-wf02 @ 192.168.9.221: Connection error occurred: fan-wf02 @ 192.168.9.221: EOF received
2024-04-25 08:25:39.716 WARNING (MainThread) [aioesphomeapi.connection] dimmer-wd15-3w @ 192.168.9.80: Connection error occurred: dimmer-wd15-3w @ 192.168.9.80: EOF received
2024-04-25 08:28:07.171 WARNING (MainThread) [aioesphomeapi.connection] dimmer-wd02 @ 192.168.9.35: Connection error occurred: dimmer-wd02 @ 192.168.9.35: EOF received

Here is a portion of my config for a device

substitutions:
  device_name: dimmer-wd03
  device_friendly_name: Dimmer WD03
  device_location_descriptor: Large Front Porch
  device_type: Dimmer
  device_make: Treatlife
  device_model: DS01C
  device_chipset: Beken v1.1.17
  dimmer_minvalue: "50"
    # - 50 allows for dimming down to 5%
    # - 100 allows for dimming downto 10%
  dimmer_maxvalue: "1000"
    # - Typically 1000 (100%)

# Setup the wifi connection, and configure a possible local access point
wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: none
  ap:
    ssid: $device_name
    password: !secret wifi_ap_password

# Esphome core information
esphome:
  name: $device_name
  friendly_name: $device_friendly_name ($device_location_descriptor)
  comment: $device_make $device_model $device_type

# The board type for this device
bk72xx:
  board: generic-bk7231t-qfn32-tuya

# Provide LAN announcement using the multicast DNS (MDNS)
mdns:

# ESPHome native API is used to communicate with clients directly, 
# and if required for Home Assistant functionality
api:

# Permit OTA (Over The Air) updates
ota:

# After 1 minute of unsuccessful WiFi connection attempts, the ESP 
# will start a WiFi hotspot (using ap config below)
captive_portal:

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:

• Reddit - Treatlife Switches and Dimmers for Home Assistant in 2024
• Reddit - SPHome WiFi Issues - EOF Received/Connection reset by peer
• HA Community - ESPHOME: Connection error occurred: EOF received

ESPHome advised that

• Github ESPhome recommended that I open an issue here with libretiny.

[Cossid]

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.

[tyzen9]

I am able to get the OTA logs, but they really don't seem to tell me much:

15:03:19][V][sensor:043]: 'WiFi Signal': Received new state -44.000000
[15:03:19][V][sensor:043]: 'Heap Free': Received new state 73688.000000
[15:03:19][D][sensor:093]: 'Heap Free': Sending state 73688.00000 B with 0 decimals of accuracy
[15:03:19][V][sensor:043]: 'Heap Max Block': Received new state 0.000000
[15:03:19][D][sensor:093]: 'Heap Max Block': Sending state 0.00000 B with 0 decimals of accuracy
[15:03:19][V][sensor:043]: 'Loop Time': Received new state 20.000000
[15:03:19][D][sensor:093]: 'Loop Time': Sending state 20.00000 ms with 0 decimals of accuracy
[15:03:22][V][sensor:043]: 'Uptime': Received new state 297.053986
[15:03:22][D][sensor:093]: 'Uptime': Sending state 297.05399 s with 0 decimals of accuracy
[15:03:24][V][sensor:043]: 'Heap Free': Received new state 73688.000000
[15:03:24][D][sensor:093]: 'Heap Free': Sending state 73688.00000 B with 0 decimals of accuracy
[15:03:24][V][sensor:043]: 'Heap Max Block': Received new state 0.000000
[15:03:24][D][sensor:093]: 'Heap Max Block': Sending state 0.00000 B with 0 decimals of accuracy
[15:03:24][V][sensor:043]: 'Loop Time': Received new state 20.000000
[15:03:24][D][sensor:093]: 'Loop Time': Sending state 20.00000 ms with 0 decimals of accuracy
[15:03:25][I][ota:117]: Boot seems successful, resetting boot loop counter.
[15:03:25][D][lt.preferences:104]: Saving 1 preferences to flash...
[15:03:25][V][lt.preferences:115]: sync: key: 233825507, len: 4
[15:03:25][D][lt.preferences:132]: Saving 1 preferences to flash: 0 cached, 1 written, 0 failed
[15:03:29][V][sensor:043]: 'Heap Free': Received new state 73712.000000
[15:03:29][D][sensor:093]: 'Heap Free': Sending state 73712.00000 B with 0 decimals of accuracy
[15:03:29][V][sensor:043]: 'Heap Max Block': Received new state 0.000000
[15:03:29][D][sensor:093]: 'Heap Max Block': Sending state 0.00000 B with 0 decimals of accuracy
[15:03:29][V][sensor:043]: 'Loop Time': Received new state 22.000000
[15:03:29][D][sensor:093]: 'Loop Time': Sending state 22.00000 ms with 0 decimals of accuracy
[15:03:34][V][sensor:043]: 'Heap Free': Received new state 73712.000000
[15:03:34][D][sensor:093]: 'Heap Free': Sending state 73712.00000 B with 0 decimals of accuracy
[15:03:34][V][sensor:043]: 'Heap Max Block': Received new state 0.000000
[15:03:34][D][sensor:093]: 'Heap Max Block': Sending state 0.00000 B with 0 decimals of accuracy
[15:03:34][V][sensor:043]: 'Loop Time': Received new state 18.000000
[15:03:34][D][sensor:093]: 'Loop Time': Sending state 18.00000 ms with 0 decimals of accuracy
[15:03:39][V][sensor:043]: 'Heap Free': Received new state 73712.000000

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.

[Cossid]

You'll need the logs of when the disconnect actually happens, OTA likely won't be helpful and you'll need a serial connection.

[tyzen9]

Am I right in assuming I will need to solder "something" to get a serial connection to a "CloudCut" device?
Example link to product on Amazon: https://a.co/d/cEp1mD5

[Cossid]

Yes, you would likely need the 3.3V/GND/TX2 pins soldered to receive logs.

[tyzen9]

This will take me some time but I will dig into this. These switches are awesome, would be great if they were more "bulletproof".

[Cossid]

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.

[Cossid]

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.

[tyzen9]

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.

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...

[Cossid]

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).

[tyzen9]

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.

[rishabmehta7]

I have a similar device and on some hard reboot it goes from becoming bad to ok, Let me explain -
The device is bad when it reboots every 57 seconds (sometimes at 117 seconds mark) - uptime of 57s and 117s.
The device is ok when the uptime is a few thousand seconds.

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).

##Proper as on 9th April 2024##

esphome:
  name: tuya3gang-01
  friendly_name: Tuya-3Gang-01

bk72xx:
  board: generic-bk7231t-qfn32-tuya

logger:
  level: ERROR
  baud_rate: 0
api:
captive_portal:
ota:
  safe_mode: False

wifi:
  networks:
  - ssid: "SSID"
    password: !secret wifi_password
    priority: 2.0
  fast_connect: True
  reboot_timeout: 0s
  manual_ip:
    static_ip: 192.168.31.223
    gateway: 192.168.31.1
    subnet: 255.255.255.0
  use_address: 192.168.31.223
  ap:
    ssid: "Tuya 3Gang 01"
    password: !secret wifi_password

binary_sensor:
  - platform: status
    name: "Status"

sensor:
  - platform: wifi_signal
    update_interval: 10s
    id: wifi_signal_db
  - platform: uptime
    name: "Uptime"
  - platform: copy
    source_id: wifi_signal_db
    name: "WiFi Signal Percent"
    filters:
      - lambda: return min(max(2 * (x + 100.0), 0.0), 100.0);
    unit_of_measurement: "%"

  - platform: adc
    pin: P23
    id: button_adc
    update_interval: 0.2s
    internal: True
    on_value_range:
      - below: 0.4
        then:
          - light.toggle: tuya3gang_01_3
      - above: 0.8
        below: 1.1
        then:
          - light.toggle: tuya3gang_01_2
      - above: 1.5
        below: 1.7
        then:
          - light.toggle: tuya3gang_01_1

button:
  - platform: restart
    name: "Restart"

output:
  - platform: gpio
    pin: P24
    id: relay1
  - platform: gpio
    pin: P7
    id: relay2
  - platform: gpio
    pin: P8
    id: relay3

light:
  - platform: binary
    name: "Glass Brick Wall"
    id: tuya3gang_01_1
    icon: mdi:globe-light-outline
    restore_mode: RESTORE_DEFAULT_OFF
    output: relay1

  - platform: binary
    name: "GRID"
    id: tuya3gang_01_2
    icon: mdi:lightbulb-group
    restore_mode: RESTORE_DEFAULT_OFF
    output: relay2

  - platform: binary
    name: "Shoe Rack Light"
    id: tuya3gang_01_3
    icon: mdi:light-recessed
    restore_mode: RESTORE_DEFAULT_OFF
    output: relay3

  - platform: status_led
    id: "state"
    pin:
      number: P22
      inverted: false

time:
  - platform: homeassistant
    id: homeassistant_time

# debug:
#   update_interval: 5s

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "IP Address"
    ssid:
      name: "Connected SSID"
  - platform: libretiny
    version:
      name: LibreTiny Version
  # - platform: debug
  #   reset_reason:
  #     name: "Reset Reason"

[tyzen9]

@Cossid - I have made good progress with soldering up connections to a Treatlife SS01 3-way switch.
It's integrated BK7231T chip powers up via USB, and I the browser/PC recognizes its serial port.

Pins are hooked up as documented on the WBS3 Data Sheet.

1 - VSS (3.3V)
2 - Ground
3 - TXD1 (Connected to RXD on serial USB Connector)
4 - RXD1 (Connected to TXD on serial USB Connector)

When powered up, I can access the web_server, and see the OTA logging via the ESPHome dashboard.
I am still struggling with making the correct configuration to access the logs via USB/Serial, as I have not done this in the past.

Here is what I have at the moment that is NOT working:

logger:
  level: VERBOSE
  hardware_uart: UART1
  baud_rate: 115200

I'm researching now if I need a uart section.
Almost there...

[kuba2k2]

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:
https://docs.libretiny.eu/boards/wb3s/?h=wb3s#pinout

[tyzen9]

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: https://docs.libretiny.eu/boards/wb3s/?h=wb3s#pinout

Man @Cossid said TX2 didn't he... Thank you I will adjust.