Intermittent connection issues with bk72xx ESPHome devices

tyzen9 commented 5 months ago

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:

ESPHome advised that

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

Cossid commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

tyzen9 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

soldering

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 commented 5 months ago

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 commented 5 months ago

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.

rishabmehta7 commented 5 months ago

@tyzen9 Are your uptimes similar to mine - 57s and 117s?

tyzen9 commented 5 months ago

@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 EOF Received and Connection reset by peer errors I see in the home-assistant.log to something happening on the device itself.

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

tyzen9 commented 5 months ago

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.

I am now seeing the logs via serial connection. 🎉

I am tailing the home-assistant.log hoping for an EOF Received or a Connection reset by peer error for this device so I can let the group know what I see in the serial logs.

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.

rishabmehta7 commented 5 months ago

@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 EOF Received and Connection reset by peer errors I see in the home-assistant.log to something happening on the device itself.
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

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.

tyzen9 commented 5 months ago

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 home-assistant.log:

2024-05-01 09:05:21.319 WARNING (MainThread) [aioesphomeapi.connection] switch-ws05-3w @ 192.168.9.163: Connection error occurred: [Errno 104] Connection reset by peer
2024-05-01 09:05:21.408 WARNING (MainThread) [aioesphomeapi.connection] switch-ws05-3w @ 192.168.9.163: Connection error occurred: switch-ws05-3w @ 192.168.9.163: EOF received
2024-05-01 09:05:21.409 WARNING (MainThread) [aioesphomeapi.reconnect_logic] Can't connect to ESPHome API for switch-ws05-3w @ 192.168.9.163: switch-ws05-3w @ 192.168.9.163: EOF received (SocketClosedAPIError)

Where do we go from here?

rishabmehta7 commented 5 months ago

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 home-assistant.log:
2024-05-01 09:05:21.319 WARNING (MainThread) [aioesphomeapi.connection] switch-ws05-3w @ 192.168.9.163: Connection error occurred: [Errno 104] Connection reset by peer
2024-05-01 09:05:21.408 WARNING (MainThread) [aioesphomeapi.connection] switch-ws05-3w @ 192.168.9.163: Connection error occurred: switch-ws05-3w @ 192.168.9.163: EOF received
2024-05-01 09:05:21.409 WARNING (MainThread) [aioesphomeapi.reconnect_logic] Can't connect to ESPHome API for switch-ws05-3w @ 192.168.9.163: switch-ws05-3w @ 192.168.9.163: EOF received (SocketClosedAPIError)
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.

tyzen9 commented 5 months ago

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?
I have Windows, and Mac laptops as well as Apple mobile devices I can test with.

rishabmehta7 commented 4 months ago

Any updates?

tyzen9 commented 4 months ago

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.

rishabmehta7 commented 4 months ago

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? I'd like to see that graph if its available...

tyzen9 commented 4 months ago

@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 EOF Received and Connection reset by peer errors I see in the home-assistant.log to something happening on the device itself.
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

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.

bkbartk commented 3 months ago

Here is the most recent output from the serial logs: https://pastebin.com/eFNNKvsr

not that I can help you in any way, but I'm just curious on line 32:

[W][wifi_lt:286]: Event: Disconnected ssid='' bssid=00:00:00:00:00:00[redacted] reason='Beacon Timeout'

did you also redact ssid? or is it just empty her.

on none of the connected/disconnected lines I actually see the ssid.

tanishqmanuja commented 3 months ago

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: false

I can control the device like this and it works every time.

~
❯ curl -X POST "http://192.168.0.75/light/light/turn_on?r=200&g=100&b=0&brightness=200"

~
❯ curl -X POST "http://192.168.0.75/light/light/turn_off"

jcam commented 1 month ago

Without HA using the the esphome api to connect to the device it works flawlessly forever without any reboot.

Have you tried using MQTT instead of the esphome/homeassistant API connection?

tanishqmanuja commented 1 month ago

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.

joukio commented 1 month ago

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.

tyzen9 commented 1 month ago

Without HA using the the esphome api to connect to the device it works flawlessly forever without any reboot.

Have you tried using MQTT instead of the esphome/homeassistant API connection?

This is a great idea - I will give this a try in the coming week or so and report back.

gurrier commented 1 month ago

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.

@joukio Interested in how you went over the last 3 days with v1.6.0?

joukio commented 1 month ago

Flashed some other shp102's as well, and they are all doing ok. Haven't seen any disconnects

gurrier commented 1 month ago

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 https://github.com/libretiny-eu/libretiny/issues/280#issuecomment-2322174955, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQ6R7GGRJCVYJJZVSF63X3ZUC7DTAVCNFSM6AAAAABGY5TMBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMRSGE3TIOJVGU . You are receiving this because you are subscribed to this thread.Message ID: @.***>

joukio commented 1 month ago

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:

gurrier commented 1 month ago

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.

tyzen9 commented 3 weeks ago

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

tyzen9 commented 3 weeks ago

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:

2024-09-05 08:42:05.017 WARNING (MainThread) [aioesphomeapi.connection] dimmer-wd15-3w @ 192.168.9.79: Connection error occurred: dimmer-wd15-3w @ 192.168.9.79: EOF received
2024-09-05 08:42:05.268 WARNING (MainThread) [aioesphomeapi.connection] dimmer-wd05 @ 192.168.9.92: Connection error occurred: dimmer-wd05 @ 192.168.9.92: EOF received
2024-09-05 08:48:18.521 WARNING (MainThread) [aioesphomeapi.connection] fan-wf02 @ 192.168.9.223: Connection error occurred: fan-wf02 @ 192.168.9.223: EOF received
2024-09-05 08:50:01.957 WARNING (MainThread) [aioesphomeapi.connection] dimmer-wd15-3w @ 192.168.9.79: Connection error occurred: dimmer-wd15-3w @ 192.168.9.79: EOF received
2024-09-05 08:50:02.200 WARNING (MainThread) [aioesphomeapi.connection] dimmer-wd05 @ 192.168.9.92: Connection error occurred: dimmer-wd05 @ 192.168.9.92: EOF received
2024-09-05 08:57:59.134 WARNING (MainThread) [aioesphomeapi.connection] dimmer-wd05 @ 192.168.9.92: Connection error occurred: dimmer-wd05 @ 192.168.9.92: EOF received
2024-09-05 08:59:32.315 WARNING (MainThread) [aioesphomeapi.connection] dimmer-wd15-3w @ 192.168.9.79: Connection error occurred: dimmer-wd15-3w @ 192.168.9.79: EOF received

bkbartk commented 3 weeks ago

just a comment on my side, I'm running ESPHome with LibreTiny 1.6.0 for a few weeks now, and I have to say, WIFI is much more stable, still I sometimes have some connectivity and delay issues.

tyzen9 commented 3 weeks ago

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:

TreatLife DS01C Dimmer
TreatLife DS01C3 3-Way Dimmer
TreatLife DS03 Fan

@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

kuba2k2 commented 3 weeks ago

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.

tyzen9 commented 3 weeks ago

@kuba2k2 - that's a great call out. Is there anything that you think I should consider adding to my ESPHome YAML to account for or configure the TuyaMCU further?

Looking here: https://esphome.io/components/tuya.html the only intriguing that is mentioned is:

ignore_mcu_update_on_datapoints: A list of datapoints to ignore MCU updates for. Useful for certain broken/erratic hardware and debugging.

I can't help but wonder if I should look at OpenBeken 🤔

bkbartk commented 3 weeks ago

having a closer look, I have the following

Logger: aioesphomeapi.connection
Source: runner.py:190
First occurred: September 3, 2024 at 22:12:23 (182 occurrences)
Last logged: 21:54:39

bulb-kamer-voor @ 192.168.170.218: Connection error occurred: bulb-kamer-voor @ 192.168.170.218: EOF received
plafond-slaapkamer @ 192.168.170.233: Connection error occurred: plafond-slaapkamer @ 192.168.170.233: EOF received
bulb-kamer-voor @ 192.168.170.218: Connection error occurred: Ping response not received after 90.0 seconds
bulb-kamer-achter @ 192.168.170.244: Connection error occurred: bulb-kamer-achter @ 192.168.170.244: EOF received

my board is configured like this for all 3 of the devices.

bk72xx:
  board: generic-bk7231t-qfn32-tuya
  framework:
    version: 1.6.0

I don't know if this is TuyaMCU or not, but I actually just assumed the devices have a poor wifi antenna.

bkbartk commented 3 weeks ago

I don't know which change in 1.7.0 does the trick, but with this new version. 2 of my 3 libretiny devices don't have any connection issues anymore.

tyzen9 commented 3 weeks ago

I will try 1.7.0 today on my TreatLife TinyMCU switches today and report back. Thanks @bkbartk

tyzen9 commented 3 weeks ago

OK I updated to 1.7.0 on all my TreatLife TinyMCU switches here are the results after 21 hours:

TreatLife DS03 Fan - 🎉 NO MORE ERRORS
TreatLife DS01C Dimmer - 👎 Errors persist
TreatLife DS01C3 3-Way Dimmer - 👎 Errors persist

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!

gurrier commented 1 week ago

Libretiny v1.7.0 is now deployed by default with ESPHome in HomeAssistant.

rishabmehta7 commented 1 week ago

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.

chpatrick commented 1 week ago

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 https://github.com/libretiny-eu/libretiny/issues/280#issuecomment-2182487477, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGLJT4LTIFR3LS2BT7VJATZIP6Q3AVCNFSM6AAAAABGY5TMBOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBSGQ4DONBXG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

libretiny-eu / libretiny

Intermittent connection issues with bk72xx ESPHome devices #280