Web server showing no controls for Tuya devices

justlikeef commented 4 months ago

The problem

After upgrade to 2024.5.0, no controls appear on the web page for devices with Tuya integration

Before:

After:

Which version of ESPHome has the issue?

2024.5.0

What type of installation are you using?

Home Assistant Add-on

Which version of Home Assistant has the issue?

No response

What platform are you using?

ESP8266

Board

No response

Component causing the issue

tuya?

Example YAML snippet

substitutions:
  device_name: "hall-bath-counter-lights-dimmer"
  friendly_name: Hall Bathroom Counter Lights Dimmer
  icon: "mdi:light-switch"

esphome:
  name: ${device_name}
  friendly_name: ${friendly_name}

bk72xx:
  board: cb3s

# Enable logging
logger:

web_server:
  auth:
    username: !secret web_server_username
    password: !secret web_server_password

captive_portal:

mdns:

api:
  encryption:
    key: "ZYRqxwXCAxKZN8CPVehDPlS2vZRgdJ0EAf29pT+TP+8="

ota:
  password: "81c77eaf15fe7f161f2c177fac70f2b3"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: "hall-bathroom-counter-dimmer"
    password: "kIN44A6Wqjxx"

button:
  - platform: restart
    name: Restart

debug:
  update_interval: 30s

text_sensor:
  - platform: debug
    reset_reason:
      name: Reset Reason
  - platform: libretiny
    version:
      name: LibreTiny Version

uart:
  rx_pin: RX1
  tx_pin: TX1
  baud_rate: 9600

tuya:

sensor:
  - platform: wifi_signal
    name: ${friendly_name} WiFi Signal
    update_interval: 60s

  - platform: uptime
    name: ${friendly_name} Uptime

light:
  - platform: "tuya"
    name: ${friendly_name}
    dimmer_datapoint: 2
    switch_datapoint: 1
    min_value: 100
    max_value: 1000

Anything in the logs that might be useful for us?

javascript error:

www.js:3 Uncaught (in promise) Error: invalid template strings array
    at Ct (www.js:3:335)
    at Mt (www.js:3:1057)
    at new H (www.js:3:1221)
    at T._$AC (www.js:3:4731)
    at T.g (www.js:3:4433)
    at T._$AI (www.js:3:4089)
    at qt (www.js:3:7409)
    at yt.update (www.js:3:7811)
    at yt.performUpdate (www.js:1:6064)
    at yt.scheduleUpdate (www.js:1:5716)

Additional information

No response

justlikeef commented 4 months ago

Logs:

INFO ESPHome 2024.5.0
INFO Reading configuration /config/esphome/hall-bathroom-counter-lights-dimmer.yaml...
INFO Starting log output from 192.168.99.218 using esphome API
INFO Successfully connected to hall-bath-counter-lights-dimmer @ 192.168.99.218 in 0.043s
INFO Successful handshake with hall-bath-counter-lights-dimmer @ 192.168.99.218 in 0.239s
[11:13:31][I][app:100]: ESPHome version 2024.5.0 compiled on May 15 2024, 08:13:07
[11:13:31][C][wifi:580]: WiFi:
[11:13:32][C][wifi:408]:   Local MAC: A0:92:08:06:1C:2C
[11:13:32][C][wifi:413]:   SSID: [redacted]
[11:13:32][C][wifi:416]:   IP Address: 192.168.99.218
[11:13:32][C][wifi:419]:   BSSID: [redacted]
[11:13:32][C][wifi:421]:   Hostname: 'hall-bath-counter-lights-dimmer'
[11:13:32][C][wifi:423]:   Signal strength: -48 dB ▂▄▆█
[11:13:32][C][wifi:427]:   Channel: 6
[11:13:32][C][wifi:428]:   Subnet: 255.255.255.0
[11:13:32][C][wifi:429]:   Gateway: 192.168.99.1
[11:13:32][C][wifi:430]:   DNS1: 192.168.99.1
[11:13:32][C][wifi:431]:   DNS2: 192.168.99.1
[11:13:32][C][logger:185]: Logger:
[11:13:32][C][logger:186]:   Level: DEBUG
[11:13:32][C][logger:188]:   Log Baud Rate: 115200
[11:13:32][C][logger:189]:   Hardware UART: UART2
[11:13:32][C][uart.lt:101]: UART Bus:
[11:13:32][C][uart.lt:102]:   Type: hardware
[11:13:32][C][uart.lt:104]:   Port number: 1
[11:13:32][C][uart.lt:106]:   TX Pin: 11
[11:13:32][C][uart.lt:107]:   RX Pin: 10
[11:13:32][C][uart.lt:109]:   RX Buffer Size: 256
[11:13:32][C][uart.lt:111]:   Baud Rate: 9600 baud
[11:13:32][C][uart.lt:112]:   Data Bits: 8
[11:13:32][C][uart.lt:113]:   Parity: NONE
[11:13:32][C][uart.lt:114]:   Stop bits: 1
[11:13:32][C][uptime.sensor:031]: Uptime Sensor 'Hall Bathroom Counter Lights Dimmer Uptime'
[11:13:32][C][uptime.sensor:031]:   Device Class: 'duration'
[11:13:32][C][uptime.sensor:031]:   State Class: 'total_increasing'
[11:13:32][C][uptime.sensor:031]:   Unit of Measurement: 's'
[11:13:32][C][uptime.sensor:031]:   Accuracy Decimals: 0
[11:13:32][C][uptime.sensor:031]:   Icon: 'mdi:timer-outline'
[11:13:32][C][light:103]: Light 'Hall Bathroom Counter Lights Dimmer'
[11:13:32][C][light:105]:   Default Transition Length: 0.0s
[11:13:32][C][light:106]:   Gamma Correct: 1.00
[11:13:32][C][restart.button:017]: Restart Button 'Restart'
[11:13:32][C][tuya.light:101]: Tuya Dimmer:
[11:13:32][C][tuya.light:103]:    Dimmer has datapoint ID 2
[11:13:32][C][tuya.light:106]:    Switch has datapoint ID 1
[11:13:32][C][captive_portal:088]: Captive Portal:
[11:13:32][C][web_server:173]: Web Server:
[11:13:32][C][web_server:174]:   Address: hall-bath-counter-lights-dimmer.local:80
[11:13:32][C][mdns:115]: mDNS:
[11:13:32][C][mdns:116]:   Hostname: hall-bath-counter-lights-dimmer
[11:13:32][C][ota:096]: Over-The-Air Updates:
[11:13:32][C][ota:097]:   Address: hall-bath-counter-lights-dimmer.local:8892
[11:13:32][C][ota:100]:   Using Password.
[11:13:32][C][ota:103]:   OTA version: 2.
[11:13:32][C][api:139]: API Server:
[11:13:32][C][api:140]:   Address: hall-bath-counter-lights-dimmer.local:6053
[11:13:32][C][api:142]:   Using noise encryption: YES
[11:13:32][C][wifi_signal.sensor:009]: WiFi Signal 'Hall Bathroom Counter Lights Dimmer WiFi Signal'
[11:13:32][C][wifi_signal.sensor:009]:   Device Class: 'signal_strength'
[11:13:32][C][wifi_signal.sensor:009]:   State Class: 'measurement'
[11:13:32][C][wifi_signal.sensor:009]:   Unit of Measurement: 'dBm'
[11:13:32][C][wifi_signal.sensor:009]:   Accuracy Decimals: 0
[11:13:32][C][lt.component:013]: LibreTiny:
[11:13:32][C][lt.component:014]:   Version: v1.5.1 on cb3s, compiled at May 15 2024 08:12:12, GCC 10.3.1 (-O1)
[11:13:32][C][lt.component:015]:   Loglevel: 3
[11:13:32][D][text_sensor:064]: 'LibreTiny Version': Sending state 'v1.5.1 on cb3s, compiled at May 15 2024 08:12:12, GCC 10.3.1 (-O1)'
[11:13:32][C][debug:067]: Debug component:
[11:13:32][D][debug:079]: ESPHome version 2024.5.0
[11:13:32][D][debug:083]: Free Heap Size: 14888 bytes
[11:13:32][D][debug:359]: LibreTiny Version: 1.5.1
[11:13:32][D][debug:360]: Chip: BK7231N (7b1c) @ 120 MHz
[11:13:32][D][debug:361]: Chip ID: 0x2C1C06
[11:13:32][D][debug:362]: Board: cb3s
[11:13:32][D][debug:363]: Flash: 2048 KiB / RAM: 256 KiB
[11:13:32][D][debug:364]: Reset Reason: SW Reboot
[11:13:32][D][text_sensor:064]: 'Reset Reason': Sending state 'SW Reboot'
[11:13:32][C][tuya:041]: Tuya:
[11:13:32][C][tuya:058]:   Datapoint 2: int value (value: 1000)
[11:13:32][C][tuya:056]:   Datapoint 1: switch (value: OFF)
[11:13:32][C][tuya:058]:   Datapoint 3: int value (value: 148)
[11:13:32][C][tuya:062]:   Datapoint 4: enum (value: 0)
[11:13:32][C][tuya:074]:   Product: '{"p":"qyiudfgrhtqwtbuy","v":"6.6.4","m":0}'

chrisazzopardi commented 4 months ago

got the same issue here

Klorins commented 4 months ago

Ye, me too. Some are bekken and others esp8266. Neither work.

bkaufx commented 4 months ago

I don't think this is a Tuya thing at all. I think the web_server component is bugged out.

(1) The browser will only connect to /events maybe 10-20% of the time, so most of the time the only thing that shows up in the browser window is an empty entity table, the log header, and Scheme switch. On Firefox the dev tools tell me Firefox can’t establish a connection to the server at http://server-test.local/events. www.js:3:23713, but Chrome gives no error or anything that I can see.

(2) I'm seeing the following error 100% of the time:

www.js:3 Uncaught (in promise) Error: invalid template strings array
    at Ct (www.js:3:335)
    at Mt (www.js:3:1057)
    at new H (www.js:3:1221)
    at T._$AC (www.js:3:4731)
    at T.g (www.js:3:4433)
    at T._$AI (www.js:3:4089)
    at qt (www.js:3:7409)
    at yt.update (www.js:3:7811)
    at yt.performUpdate (www.js:1:6064)
    at yt.scheduleUpdate (www.js:1:5716)

This is my entire config:

esphome:
  name: server-test
  friendly_name: Server Test

esp8266:
  board: esp01_1m

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

ota:
logger:
web_server:
api:

sensor:
  - platform: uptime
    id: uptime_seconds
    update_interval: 2s
    name: Uptime

justlikeef commented 4 months ago

I am not seeing the proper controls in HA for Tuya devices either. ESP32 device both the web and HA seem to be fine.

spanner3003 commented 4 months ago

I'm experiencing the same behaviour. tuya smart led strip bk7231t chip esphome dev channel.

AndyB117 commented 4 months ago

The same with DIY module on ESP8266.

Jilas commented 4 months ago

Getting the similar issues with range of esp8266 d1 mini's, esp32's (d1's) and rf bridges. Using the default of:

web_server: port: 80

This generates the screens as above, with no data, and more often that not disconnects the esp from HA as well. Reflashing OTA is problematic if the web page is open as well.

Adding versions.

Version 1 makes the interface more likely to start and show sensor values, but if refreshed can break and lock the web waiting 5-10 seconds and then refreshing version 1 does come back.

Version 2 never loads correctly.

Version 3 just states started in 0 seconds, shows a debug window.. but nothing appears sensor wise (the light/dark controls do work here).

Linwood-F commented 4 months ago

Same here. Any issue with rolling back (I know sometimes flash layout changes but didn't see such).

Jilas commented 4 months ago

Same here. Any issue with rolling back (I know sometimes flash layout changes but didn't see such).

I've rolled back, everything came back and is as solid as before.

justlikeef commented 4 months ago

hall-bath-counter-lights-dimmer.local.har.zip

KyleStilkey commented 4 months ago

Same issue here, the web interface seems to be broken, all my ESPHome devices are Tuya converted devices, guess I'll have to rollback until this gets resolved.

justlikeef commented 4 months ago

Looks like a Cloudflare cache miss. Work around is to use "local: true" in your web server definition if you have enough flash.

Jilas commented 4 months ago

Looks like a Cloudflare cache miss. Work around is to use "local: true" in your web server definition if you have enough flash.

I did try that setting, with a version 2 interface and didn't change anything. Still unreliable. (doesn't work/isn't needed for v1). The page loads up the stock graphics it seems and just gets stuck loading the sensors doesn't appear to make any difference.

V1 they do load, but a refresh too quickly results in them being listed but with no values (refresh again after 5-10 seconds they load and seems ok.

V2 the sensors almost never loaded. And any refresh would return it back to the same state (no list of sensors).

V3 I think it loaded the sensors up once, after I'd accidentally left the page open fro 5-10 minutes. But any refresh caused it to clear and just load the base graphics.

When it locks up it would also take out the connection to HA, which made staying with the update impossible.

What I don't get is I had a couple of esp8266 d1 mini's work ok, and others just fail. Even hit all of my esp32's, plus some other random ones like the sonoff rf bridges.

mad-tunes commented 4 months ago

Pretty sure I'm getting the same with the web server on an esp01_1m based fish feeder I've got. The same's still working OK on my esp32s3 assistant though

bkaufx commented 3 months ago

I rolled back just the web_server and web_server_base components to 2024.4.2 by adding the following to some of my configs and it seems to fix this issue. At least a work around for now.

external_components:
  - source:
      type: git
      url: https://github.com/esphome/esphome
      ref: 2024.4.2 
    components: [web_server, web_server_base]

bkaufx commented 3 months ago

Rolling back ESPAsyncWebServer-esphome to 3.1.0 fixes this issue for me. The only functional change for 3.2.0 was this PR so I have to assume it is the culprit. (https://github.com/esphome/ESPAsyncWebServer/pull/24/files)

spanner3003 commented 3 months ago

That worked rolled back web_server and web_server_base components to 2024.4.2 and now the all is back and working again in the web server. I.see the controls and they work and the log is back.

Klorins commented 3 months ago

I wonder if they fix this now in 2024.5.1 Anyone try it yet?

mad-tunes commented 3 months ago

I've just tried 2024.5.1. The hit-rate of working vs not might be a little better but it's still failing to load the devices controls more often than not Usually: Rather than:

KyleStilkey commented 3 months ago

2024.5.1 doesn't resolve this problem. I'd recommend using @bkaufx fix https://github.com/esphome/issues/issues/5793#issuecomment-2119729825 or use something like this https://github.com/khenderick/esphome-legacy-addons

bkaufx commented 3 months ago

OK I created a fork and rolled back just the specific change that causes the issue. So if you want to be totally up to date with 2024.5.x but just fix this issue you can add the following to your config instead of the above. At least if a few people try this we can confirm or disprove for sure whether the bump from ESPAsyncWebServer-esphome 3.1.0 to 3.2.0 indeed is causing this issue.

external_components:
  - source:
      type: git
      url: https://github.com/bkaufx/esphome
    components: [web_server_base]

mad-tunes commented 3 months ago

OK I created a fork and rolled back just the specific change that causes the issue. So if you want to be totally up to date with 2024.5.x but just fix this issue you can add the following to your config instead of the above. At least if a few people try this we can confirm or disprove for sure whether the bump from ESPAsyncWebServer-esphome 3.1.0 to 3.2.0 indeed is causing this issue.
external_components:
  - source:
      type: git
      url: https://github.com/bkaufx/esphome
    components: [web_server_base]

Using this with esphome 2024.5.1, the web server seems solid. Just hit refresh 25 times and it loaded as it should each time.

afarago commented 3 months ago

OK I created a fork and rolled back just the specific change that causes the issue. So if you want to be totally up to date with 2024.5.x but just fix this issue you can add the following to your config instead of the above. At least if a few people try this we can confirm or disprove for sure whether the bump from ESPAsyncWebServer-esphome 3.1.0 to 3.2.0 indeed is causing this issue.
external_components:
  - source:
      type: git
      url: https://github.com/bkaufx/esphome
    components: [web_server_base]

This workaround definitely is a lifesaver! Could it be that esphome/ESPAsyncWebServer introduced a mutex that seems to be supposedly guard the queue, yet eventsource HTTP does not end / runs ~infinitely by design?

vvrein commented 3 months ago

Can confirm that rolling back esphome/ESPAsyncWebServer-esphome to 3.1.0 solves the issue

MisterRadish commented 3 months ago

Rolling back to 3.1.0 ESPAsyncWebServer-esphome has solved the issue across all 12 of my ESP8266 nodes

ThomasFTL commented 3 months ago

It works. I already suspected that the ESPAsyncWebServer library was the culprit. But I don't know the ESPhome code well enough to make changes. Apparently only the version for the ESP8266 is affected by this bug. My ESP32 Cam runs the official current version. I now use the work arround for the devices that I use the web interface to control because I feel like starting HA on my smartphone every time and working my way through it.

KyleStilkey commented 3 months ago

Sadly still seems to be a problem with 5.2 that was just released, upgraded and still just a blank page with the same Java error.

Roving-Ronin commented 3 months ago

Just updated to ESPHome 2024.5.2 and it once again, like 2024.5.0 / .1 stuffs up my non ESP32 devices. With this error:

332068710-9d69373e-9855-4294-a7f8-7d0220d3976d

PS. Added this and the Athom v2 plug (ESP8285) web server works again, HOWEVER found that it needs to be disconnected from power to reset it and web to work (reset doesn't work). https://github.com/esphome/issues/issues/5793#issuecomment-2119729825

ThomasFTL commented 3 months ago

After the update 2024.5.2, ESPhome works well again with the ESP8266

afarago commented 3 months ago

After the update 2024.5.2, ESPhome works well again with the ESP8266

Esp8266 end 5.2 doesn't work for me.

MisterRadish commented 3 months ago

Mixed results for me using 2024.5.2

After cleaning build files I installed 5.2 on 2 of my ESP8266 devices.

The first device is a very simple setup – 2 GPIO switches and exposing 2 entities. It now has a ~90% success rate displaying the web portal so is not without error
The second device contains numerous platform integrations (http_request ,ic2, dht, gpio) and surfaces 19 entities. It only has a success rate of 10% when displaying the web portal which is what I experienced with 5.0

madd0x2000 commented 3 months ago

Have the same problem since a few versions back. Hope it's getting fixed soon.

ThomasFTL commented 3 months ago

ESP and 2024.5.2 often have misfires. When you access the page, you also have to manually reload the page in the browser. There still seem to be problems. Sometimes an empty frame is displayed and sometimes the content is also displayed

mad-tunes commented 3 months ago

I'm still having similar issues after updating to 2024.5.2 too

piotek commented 3 months ago

I'm still having similar issues after updating to 2024.5.2 too

dsduarte commented 3 months ago

same here... working with this workaround:

https://github.com/esphome/issues/issues/5793#issuecomment-2119729825

piotek commented 3 months ago

thank you - yes this works:

external_components:

source: type: git url: https://github.com/esphome/esphome ref: 2024.4.2 components: [web_server, web_server_base]

piotek commented 3 months ago

upssss - No it doesn't works .... 5 * F5 and i will have the same error ....

4rianton commented 3 months ago

Same issue

djrm05 commented 3 months ago

same issue....

bkaufx commented 3 months ago

The fix for this has been merged into ESPAsyncWebServer so it should flow down to ESPHome soon. You'll know because web_server_base will be updated to bump the version to 3.2.1.

https://github.com/esphome/ESPAsyncWebServer/pull/31

bkaufx commented 3 months ago

Fix is implemented in ESPHome and targeted for release with 2024.5.3 so I would expect it to be released soon.

https://github.com/esphome/esphome/milestone/368

bkaufx commented 3 months ago

OK just kidding 2024.5.3 does not have this fix in it.

ssieb commented 3 months ago

It needs people to test and comment if it fixes the problem.

bkaufx commented 3 months ago

OK if people just add web_server_base from that branch as an external component is that good enough or do they need the platformio.ini file that was also changed?

ssieb commented 3 months ago

I think it just needs the PR added as an external component.

vvrein commented 3 months ago

I have esphome installed in python venv as standalone app. So I've changed dependency in venv/lib64/python3.12/site-packages/esphome/components/web_server_base/__init__.py like so:

-        cg.add_library("esphome/ESPAsyncWebServer-esphome", "3.2.0")
+        cg.add_library("esphome/ESPAsyncWebServer-esphome", "3.2.2")

Seems to be working now. Thank you @bkaufx

piotek commented 3 months ago

Test with 2024.5.3

The error is immediate and still there. Here is a simple example code in which the website (the 2 parameters) are not displayed immediately. 20-30 * F5 key then maybe the page will be displayed correctly once. Example:

esphome:
  name: test-webfehler
  friendly_name: Test-Webfehler

esp8266:
  board: esp_wroom_02
  restore_from_flash: true

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "JPgXhLGD1GwhYCrNJtDcIxz1EcWGdoxPCh42kX11qO4="

ota:
  password: "64625290b129ccc1be61005aacb0d2b2"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Test-Webfehler Fallback Hotspot"
    password: "mLXQm4VDcesu"

web_server:
  port: 80
  log: false

captive_portal:

text:
  - platform: template
    id: ip_sensor1
    mode: text
    name: "1: IP-Adresse 1"
    initial_value: "192.168.1.10"
    restore_value: true
    optimistic: true
    min_length: 5 
    max_length: 15
  - platform: template  
    id: ip_sensor2
    mode: text
    name: "2: IP-Adresse 2 "
    initial_value: "192.168.1.20"
    restore_value: True
    optimistic: true
    min_length: 5 
    max_length: 15

ssieb commented 3 months ago

@piotek there is no fix in a release yet. You need to test the PR.

Add this to your yaml:

external_components:
  - source: github://pr#6797
    components: [ web_server_base ]

esphome / issues