HTML interface not loading correctly - Settings/Aliases not loaded to UI #807
Comments
|
Hard for me to be of much help here without a way to reproduce. Can you share the output of |
|
Output from Serial logs would potentially be helpful as well. |
/about gives: /settings on Edge browser gives a blank page. On Chrome I get the following:
On Edge and Chrome all settings appear blank (even though the hub is working correctly):
|
|
With regards to the Chorme Dev tools, is this what you was asking for:
|
|
I'm guessing the call to Hard to say what's going on here, but my best guess is there's something funky going on with your chip's flash memory. Are you able to collect serial logs? |
|
I have the same issue. |
|
Only the same debugging pointer I mentioned -- try checking serial logs. Hard for me to be of much help when I can't reproduce. :( |
|
I had the same problem closing the browser (firefox) and reload the page fixed it. |
|
I erased flash and did a fresh install of 1.11.1 on nodemcu v2. Serial console connected (see below). Serial console output: `Saving 1 aliases Setup complete (version 1.11.1) |
|
Same issue as Marcin1965, downgrading to 1.10.9 works fine. |
|
Thanks for the reports -- definitely sounds like an issue. I'm not getting it, though. The @marcin1965 -- it looks like your ESP reboots in the middle of those logs. Was that something you did, or did it reboot on its own? To everyone having this issue, the following would help a bunch:
|
1.) It takes 2-3s to load every time(so it's slow, but it's loading). I did notice that the backup of settings is not working(it tries to download but almost always fails). I'll add some serial logs later if @marcin1965 doesn't do it before me I did see this in the developer console when loading from the UI: It says the XHR fails to load: I did copy the CURL from the developer console and tried to replicate it and it as well fails(never finishes) with Curl: curl 'http://192.168.1.230/settings' My guess would be that something is wrong with the Ajax call or that it expects it to be a lot quicker that it is |
|
This call should be quick (sub-second). It's just serving the contents of a file on flash. It is reliably fast on my system (I do pretty extensive testing before cutting releases): My best guess here is something is either causing your ESP to crash on this call or something in the new Arduino SDK is causing network instability. Can you try the following?
|
ping 192.168.1.230 |
|
Okay, that's helpful. I'd expect the same behavior as Serial logs will hopefully help here. It seems likely there's a crash or something similar. Can you share the output of |
/aliases.bin works fine, no disconnects when running the ping command and nothing in the serial log. serial log when running /settings is: Output of /about: {"firmware":"milight-hub","version":"1.11.1","ip_address":"192.168.1.230","reset_reason":"External System","variant":"esp12","free_heap":20016,"arduino_version":"3.1.2","free_stack":2320,"flash_used":9538,"flash_total":957314,"flash_pct_free":99,"queue_stats":{"length":0,"dropped_packets":0}} |
I did a restart after providing all settings. So, it was an intentional restart.
no issues with calling /settings Unhandled websocket event: 10
It happens that there is a packet lost for both calling homepage and /settings |
|
One more comment - the board can remember settings, and it works. Domoticz can connect via mqtt and control the lights. However, I can't use web GUI because it is missing the device ID - I can see calls in mqtt broker but with 0x0 device id (e.g. if I press ON/OFF). Web GUI can't display all the settings (they are empty), but mqtt connection works ok. But calls are not effective because the device ID is missing. If this is helpful, we can connect via Teams or some other software. I can demonstrate the issue. I tried a different nodemcu board, and it has the same issue. |
Hmmm this is all pretty confusing. Can you try a route that modifies something on flash? Maybe something like:
Right, I'm guessing what's going on is the call to What board are you using? If you have a direct Amazon (or similar) link I can get one to test with. I've tested with d1_minis and nodemcuv3s. |
|
I'm using nodemcu v2: I've bought today nodemcu v3 and can test it around Tue/Wed once it comes to me. |
|
``> > > Okay, that's helpful. I'd expect the same behavior as
I'm using Witty board (https://www.amazon.com/ESP8266-Serial-Development-ESP-12F-nodemcu/dp/B0CJM7DDJZ/ref=sr_1_1?crid=9VWSM9TT9IIN&keywords=witty+esp8266&qid=1699712437&sprefix=witty+esp826%2Caps%2C157&sr=8-1) Using that curl worked fine but it cleared all my other settings it seems because it stopped working until I re-added the settings. I have a feeling it could be something with my and Marcin1965 settings? So here are my settings from the bin
|
Hmm... IIRC nodemcu v3 is almost the same hardware as v2 with a different (bigger) footprint. Let me know how it works, though.
Interesting, thanks for sharing. All of this points at some kinda wacky problems with flash. If editing any setting is clearing the whole thing, I suspect there's some kind of problem modifying flash. Can you try adding an alias with something like this? You should be able to see the added alias with this: If you haven't yet, can you try wiping flash with something like this and then re-flashing? Could you also share the command (or steps) you're using to install the firmware? |
|
While trying to add an alias, it says: "kuchnia" is the name of my alias, so the setting is there but can't be seen via GUI Commands I'm using to install the firmware: esptool.py --port /dev/cu.usbserial-0001 --baud 115200 erase_flash esptool.py --port /dev/cu.usbserial-0001 --baud 115200 write_flash -fm=dio -fs=4MB 0x00000 ./esp8266_milight_hub_nodemcuv2-1.11.1.bin |
|
One more odd observation:
This is rather not a problem with Flash - the device is working ok with Domoticz via mqtt. |
|
Yeah, I think I understand roughly what's going on (although I have no clue what's causing it). There's something about saving the settings that is causing some kind of flash corruption. But it's not happening for me! This is why it's so confusing. I have tried with 5 different ESP boards at this point with no issue. Have installed with platformio and with the same esptool commands you're using. It's possible that you and @SelverC have different issues. Perhaps we should produce a set of commands that definitely produces some issue for you. It sounds like you're able to save aliases, but let's just confirm (choose an alias that doesn't exist): verify that it shows up here: change a setting key: verify that it stuck: if all of this is working, can you take a screenshot of your web browser's dev tools? |
|
The first three works with no problem. curl -s 192.168.1.15/settings | jq '.packet_repeats' |
|
Can you paste the output of |
|
|
|
1.) {"success":true,"id":2}% 2.) curl 192.168.1.230/aliases {"aliases":[{"alias":"abc","id":2,"device_id":1,"group_id":1,"device_type":"rgb_cct"},{"alias":"test","id":1,"device_id":1,"group_id":0,"device_type":"rgb_cct"}],"page":1,"count":2,"num_pages":1}% 3.) curl -X PUT -H 'Content-Type: application/json' -d '{"packet_repeats":49}' 192.168.1.230/settings 4.) curl -s 192.168.1.230/settings | jq '.packet_repeats' I have the same results as @marcin1965 And here is my @sidoh ^[[A^[[B{"admin_username":"","admin_password":"","ce_pin":4,"csn_pin":15,"reset_pin":0,"led_pin":-2,"radio_interface_type":"nRF24","packet_repeats":49,"http_repeat_factor":3,"auto_restart_period":1440,"mqtt_server":"192.168.1.42:1883","mqtt_username":"user","mqtt_password":"password","mqtt_topic_pattern":"milight/:device_id/:device_type/:group_id","mqtt_update_topic_pattern":"milight/updates/:device_id/:device_type/:group_id","mqtt_state_topic_pattern":"milight/state/:device_id/:device_type/:group_id","mqtt_client_status_topic":"","simple_mqtt_client_status":false,"discovery_port":48899,"listen_repeats":0,"state_flush_interval":10,"mqtt_state_rate_limit":500,"mqtt_debounce_delay":500,"mqtt_retain":true,"packet_repeat_throttle_sensitivity":10,"packet_repeat_throttle_threshold":500,"packet_repeat_minimum":50,"enable_automatic_mode_switching":false,"led_mode_wifi_config":"Fast toggle","led_mode_wifi_failed":"On","led_mode_operatin% |
|
Hi @sidoh, Have you had any time to figure out something? Just ping if you need anything more. |
|
FYI I reported the issue for NodeMCU v2. I have two pieces and both of them have this issue. Now I bought NodeMCU v3 and it is working fine with version 1.11.1 |
|
Hey guys, sorry for the slow response here. This looks like the same issue -- something is causing your settings file to get truncated when it's updated. I just went through every spare ESP8266 I own (about 20 split across d1 minis, nodemcu v2/v3s) without seeing this issue while trying to replicate using the exact same steps. I'm at a bit of a loss here. There's clearly an issue, but I'm kind of left needing to assume there's some kind of hardware compatibility problem that is likely below the application layer. The biggest change from 1.10 to 1.11 is a bunch of library/SDK upgrades. In particular, I upgraded the version of the arduino SDK from one released 5+ years ago. Perhaps there's some kind of weird incompatibility with older flash chips? Do you guys see any meaningful differences in the output of |
|
For the board that has issues with settings (NodeMCU v2) the only difference is: |
Just got the witty board. Tested out changing settings and everything is working fine. Sort of at a loss here. If anyone has any ideas on how I might be able to replicate this, I'm all ears |
|
@sidoh I can send you my NodeMCU v2 that has the issue. I already replaced it with NodeMCU v3, which is working fine. |
|
I did buy a new nodemcuv3 but it didn't help. And one more change that I did is to re-wire it(my cables were not correct but it worked anyway? maybe that caused the crash as well). Not sure exactly what helped me but I would start fresh don't backup settings and make sure all the wires are correct Update: after a reboot the issue returned so still no solution for me :-( |
|
I've not gone over all messages here but based on some those that i did, my findings might be interesting to some. The issue i had was the light state not updating properly on home assistant.
When turning lights on/off the state updates were only updated in this part:
The topic named states didn't change. So for completeness, that's this part:
This confused me as my settings were just the default ones and they clearly said:
I didn't change anything in the settings but just - to be sure - pressed submit again. For me, this fixed the issue i had. @sidoh you might have a bug here. I'm guessing submitting the values in the settings page puts those values in some config file which you - at some other point - probably load in the code and use for actual MQTT topic stuff. My guess is that whatever variables you use, they probably empty if you haven't submitted the settings yet. If this assumption is correct then i'm still quite curious where those default values in the settings page come from. Clearly there's an edge case where you do see them in the field but they aren't used in the code else i wouldn't even have this bug to begin with. I'm still wondering why i now have |
|
Ive got the same problem on a mix of D1 mini old (6+years) and new (6months) and a NodeMCU v1 (6+ years) |
|
I just had this problem again. So incredible weird. |
|
Just adding that my nodemcu v2 is also displaying this behaviour (I likely never noticed earlier since I usually use through mqtt). I've reflashed multiple times, however settings/aliases sometimes do not load. Also, backup/restore functionality is completely broken. I'm on version 1.11.2 |
In the latest versions 1.11.0, the web interface does not display the Alias or the settings in the dialogue boxes. Restarting the device and refreshing the page multiple times the settings eventually appear
The text was updated successfully, but these errors were encountered: