Web server showing no controls for Tuya devices #5793
Comments
|
Logs: |
|
got the same issue here |
|
Ye, me too. Some are bekken and others esp8266. Neither work. |
|
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 (2) I'm seeing the following error 100% of the time: This is my entire config: |
|
I am not seeing the proper controls in HA for Tuya devices either. ESP32 device both the web and HA seem to be fine.
|
|
I'm experiencing the same behaviour. tuya smart led strip bk7231t chip esphome dev channel. |
|
The same with DIY module on ESP8266. |
|
Getting the similar issues with range of esp8266 d1 mini's, esp32's (d1's) and rf bridges. Using the default of: web_server: 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). |
|
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. |
|
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. |
|
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. |
|
Pretty sure I'm getting the same with the web server on an esp01_1m based fish feeder I've got. |
|
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. |
|
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) |
|
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. |
|
I wonder if they fix this now in 2024.5.1 Anyone try it yet? |
|
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 |
|
2024.5.1 doesn't resolve this problem. I'd recommend using @bkaufx fix #5793 (comment) or use something like this https://github.com/khenderick/esphome-legacy-addons |
|
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. |
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. |
This workaround definitely is a lifesaver! |
|
Can confirm that rolling back |
|
Rolling back to 3.1.0 ESPAsyncWebServer-esphome has solved the issue across all 12 of my ESP8266 nodes |
|
It works. |
|
Mixed results for me using 2024.5.2 After cleaning build files I installed 5.2 on 2 of my ESP8266 devices.
|
|
Have the same problem since a few versions back. Hope it's getting fixed soon. |
|
ESP and 2024.5.2 often have misfires. |
|
I'm still having similar issues after updating to 2024.5.2 too |
|
I'm still having similar issues after updating to 2024.5.2 too |
|
same here... |
|
thank you - yes this works: external_components:
|
|
upssss - No it doesn't works .... |
|
Same issue |
|
same issue.... |
|
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. |
|
Fix is implemented in ESPHome and targeted for release with 2024.5.3 so I would expect it to be released soon. |
|
OK just kidding 2024.5.3 does not have this fix in it. |
|
It needs people to test and comment if it fixes the problem. |
|
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? |
|
I think it just needs the PR added as an external component. |
|
I have esphome installed in python venv as standalone app. So I've changed dependency in - 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 |
|
Test with 2024.5.3 The error is immediate and still there. 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 |
|
@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 ] |
|
ahhhhhhh |
@ssieb I tested the PR...nope. Still borks devices like Ratgdo. If I force a rollback to 2024.4.2 (via the docker image method) everything works. Further, just downgrading the web components to 2024.4.2 as in the earlier suggestion does not work for Ratgdo either. I suspect there's more that's changed (and now potentially broken?) starting with the 2024.5 series that just the web components piece...but I neither have the expertise in ESPHome nor the time commitment to take it much further. Out of curiosity: is there a way, using only the YAML configuration file, to enforce that a specific version of ESPHome be installed, not just a particular component? It would go a long way to helping my own user community out. Thanks! Edit: Having tried this on nearly a dozen Ratgdo devices at this point...I can say it can/does work on some, but not in all instances. Despite trying several reflashes, etc. It's quite odd. In all cases, a reversion to 2024.4.2 addresses the stability issues across all Ratgdo devices, including the web interface. |
|
@hjdhjd this issue is not about stability. Check out the other issues or file a new one. |
ssieb
changed the title
Will do. Given the webUI doesn't in fact come up in all cases, I'm not sure this can be called fixed...but I will open up a new issue, nonetheless. |
|
FWIW I have Ratgdo's (two) that are working. But you said some do, some do not. Just in case, if no one objects, can you note the issue you open here so people can follow there? (I just looked at did not see it). |
|
2024.5.4 addresses all the issues for Ratgdo in my environments. Thanks @ssieb and others! |
and others
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
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
The text was updated successfully, but these errors were encountered: