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.

[rishabmehta7]

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

[tyzen9]

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

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]

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

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]

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]

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]

Any updates?

[tyzen9]

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]

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]

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

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]

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]

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]

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.