[4.0.0-Beta1] "Save Changes" always disabled - SPI pins fail to get hidden class, fail validity checks
#360
Comments
|
This indicates one or more fields had invalid data in them. Do any of the fields on the device setup screen have a red x in them? A screenshot of the device screen would help a lot. |
|
None of the fields is invalid. Using the built-in debugger of Edge, it appears that the function that checks validity is unhappy with the following elements:
(1) NOTE: These elements should NOT be considered in the validity check, as the output type is WS2811, which is single-pin (not SPI). Moreover, the APA102 is not even provided as an output option. Thus, I think this is likely a real bug.... NOTE: This is a 100% clean install. The d1 Mini came straight from the ESPixelstick v3 package ... I'm not updating the ones on my house (yet), although I am very interested in doing so (due to SD support / xLights / FPP). boot log
Really large screenshot...
|
|
ElementList parameter in debugger
Only the elements at index 2, 3, and 4 are both invalid and fail to have the 'hidden` class. CORRECTION: Index 5 also should not be validated, but appears to be included here for some reason? |
|
Looking at the underlying elements, it appears that the large screenshot
Perhaps, because ESP8266 is not allowed to select APA102 as an output mode, the code is failing to apply the |
|
Those elements are for the SD card pins and only applicable to ESP32 builds, that's why they're hidden. Not sure why edge is tripping up on them though. I just tried in Edge 94.0.992.31 and Chrome 90.0.4606.61 and am not experiencing it. What OS and version of Edge are you on? |
forkineye
added
Frontend
|
I am experiencing the same restult (cannot save any Device Setup changes). Does not work for me in Edge or Chrome. ESPixelStick v3 Widows 10.0.19043 Build 19043 I have to remove the Wemos from the Pixelstick to program it via USB, then disconnect it from the PC and put it back into the Pixelstick socket (not sure if that has anything to do with it). |
Edge is not tripping up on them.
As you can see in the picture, only the |
|
I'm going to update the bug title to reflect that the SPI input fields fail to get the
|
henrygab
changed the title
hidden class, fail validity checks
|
The thing is though, those have default values even though they're hidden which is what's confusing me. What happens if you run |
|
They all have the value Perhaps the problem is that many of those elements do not have the If they did, then I am guessing that they would get the |
I can't at the moment. Fixing it is easy, but I'm more curious as to why it's happening for some and not others, even on the same browser versions. It seems to be something related to how the DOM is being built, possibly extension related. I'll work on the fix. |
|
@henrygab @marksat666 |
|
@henrygab I just noticed the following in your boot log above: That shouldn't be happen either if using the release archive w/ the flasher. Did you edit config.json by hand before flashing? |
|
@forkineye - No manual edits. I will fully erase the flash and repro again. However, I'm having similar issues on an ESP32 module, where the SD pins have the value zero (shown by enabling advanced options under Admin), and reproduces even when all add-ins are fully disabled (they're disabled anyways for my pixel controllers). Hopefully, this is just a browser compatibility issue. Here's browser info -- it's just standard (Chromium-based) Edge on Windows 10:
|
|
Confirmed ... this occurs on a freshly-erased module at boot: |
|
@henrygab Can you post the contents of |
|
Sorry, didn't mean to ignore it ... I missed that build link earlier. Will try very shortly. fs/config.json
{
"cfgver": 1,
"device": {
"id": "ESPixelStick"
},
"network": {
"ssid": "ci",
"passphrase": "*",
"hostname": "TESTER",
"ip": "192.168.1.10",
"netmask": "255.255.255.0",
"gateway": "192.168.1.1",
"dhcp": true,
"sta_timeout": 15,
"ap_fallback": false,
"ap_timeout": 120,
"ap_reboot": true
}
}The cfgver key message is only on the first boot after flashing. It does not occur when rebooting later. Have you tried fully erasing the board (using esptool.py), then uploading via the included ESPSFlashTool.jar? The output I quoted was from that serial monitor, from immediately following a flash. Is it possible that LittleFS's ... unique ... behaviors could be involved? IIRC, file handles have to be closed before changes made are seen by other calls to the file system ... and maybe even require that the file be re-opened to see those changes? |
|
Using the binary from https://github.com/forkineye/ESPixelStick/actions/runs/1276196142: The ability to save changes is still disabled. However, each of However, the This is from a fully-erased state. No prior configuration in flash. (I presume that the EEPROM is not used.) |
What did I mean about LittleFS "unique" behaviors
See littlefs-project/littlefs#352 (comment). This is my recollection, but should give hints of what to be concerned about.
I'm just throwing this out there, as I was surprised by littleFS behavior in the past, which resulted in some really hard-to-find causes of corruption. My learnings:
|
|
A few comments about how little FS is used.
ESP32 fields are NOT present in the ESP8266 build. They have unique fields.Files are opened and closed immediately. If the files are missing at boot time, they are created and closed one at a time.At boot the littleFS files are read and immediately closed.When the UI needs the config, it is asked for one file at a time. The file is opened, data read into a buffer and closed. Then the buffer is sent to the UI.When the UI is done the files are set to the ESP one at a time. Each file is written to the FS from a buffer and closed before the next file is sent. After a file is received a flag is set indicating that a new config is present. One subsystem at a time opens its file reads into a buffer and closes the file. Then process the buffer.More than one open file in the littleFS does not happen.
On Monday, September 27, 2021, 01:38:35 AM EDT, Henry Gabryjelski ***@***.***> wrote:
What did I mean about LittleFS "unique" behaviors
See littlefs-project/littlefs#352 (comment).
This is my recollection, but should give hints of what to be concerned about.
- littleFS uses copy-on-(bounded)-write
- each file handle is a snapshot of the file as of the time it was opened, plus those changes that were made using that same file handle
- when two file handles are opened to the same file, writing to the first file handle should NOT alter the data as seen from the other file handle
- when the first file handle is closed (or manually sync'd), then the data will appear in all future opens of that file ... but still won't update what is seen via the second (still open) file handle
I'm just throwing this out there, as I was surprised by littleFS behavior in the past, which resulted in some really hard-to-find causes of corruption.
My learnings:
- serialize all access to littleFS APIs
- put all files into a subdirectory that only you will read / write / modify
- ensure you never have more than one file handle per file
- ensure you cause file sync whenever you need the state to persist
—
You are receiving this because you were assigned.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
|
|
@henrygab ESPixelStick/dist/firmware/firmware.json Line 11 in 26d6f6a EDIT: This is in regards as to why config.json isn't being uploaded correctly. |
|
@henrygab {
"cmd": {
"get": "device"
}
}and a response similar to the following: {
"get": {
"device": {
"cfgver": "1",
"id": "ESPixelStickv3",
"blanktime": "5",
"miso_pin": "19",
"mosi_pin": "23",
"clock_pin": "18",
"cs_pin": "15"
},
"network": {
"ssid": "myssid",
"passphrase": "mypassphrase",
"hostname": "esps-f4b650",
"ip": "192.168.1.10",
"netmask": "255.255.255.0",
"gateway": "192.168.1.1",
"dhcp": true,
"sta_timeout": 15,
"ap_fallback": false,
"ap_timeout": 120,
"ap_reboot": true
}
}
}
|
No difference for me for that version, also just tried CI-1278932930 - still cannot save the Device Setup |
|
I just found an issue where the flash tool and firmware were out of sync for creating the configuration file and that erasure of the previous filesystem may not always occur. Not sure if it's causing this issue yet, but possible. I'll have a fix pushed soon. |
|
@marksat666 Care to try this build? |
CI-1279404057 also did not work in Edge, Chrome, Safari 13.1.2, Silk 92.2.11.4514.159.19 (figured I would give those others a try - maybe it's not a browser issue?) I also grabbed a spare Wemos D1 mini that I had from last year (I have been testing with the Wemos/ESPixelStick that I got in April) - same results. |
|
@marksat666 Can you post the contents of both the flash upload and serial log windows from the flash tool? |
|
Here are logs - let me know if you want me to try something else. |
|
@marksat666 @henrygab I'm jumping on the xLights zoom as well if you all are around. |
|
Unfortunately, neither of those worked (tested Edge and Chrome) |
|
Was able to replicate the issue finally. Can you verify if you were or were not setting a hostname via the flash tool? It seems to be related to that of all things. If you were setting one, try without. |
|
I was having this same behavior. I can confirm that not setting a hostname resolved the issue for me. I am now able to save changes on the device setup page, and I now see input options, which I did not before. |
Thanks! I just posted a fix for it here - https://github.com/forkineye/ESPixelStick/actions/runs/1280577528 |
|
Sweet. That version works for me with a hostname set. Now, to get some lights hooked up... |
Yes, I was setting a host name in the flash tool itself. Omitting that during the flash works! I can now save the settings. Now the bad (using CI-1280577528) - FPP Connect in XLights no longer sees the ESPixelStick when I set Primary Input to be FPP Remote (it works with E1.31 input from XLights directly and from FPP) |
|
@marksat666 That's probably related to this - #364. I'll fix that today, can track it there. I'll leave this issue open for others until the next beta release |
forkineye
added
Fixed
and removed
Bug
Frontend
Sorry for delay in testing and response. Yes, I was setting a hostname via the flash tool. I am glad to again be amazed at how complex systems interact. 😏 Well done discovering the underlying cause(s). I wanted to confirm that v4.0-beta2 resolves the issue originally reported here. |
|
This appears to still be an issue in 4.0.0-Beta5, at least for me, running on as ESP32-CAM. I was thinking it was a hidden field causing validation issues, when I came across the hostname solution. Tried it out and it solved my issue. |
--------- Instructions - Delete this ---------
Please provide answers directly below each section.
--------- Instructions - Delete to here ---------
ESPixelStick Firmware Version
4.0.0-Beta1 (7083637)
Hardware Version
ESPixelStick v3
Binary release or compiled yourself?
Binary release
Operating System
N/A
Access Point
Ubiquiti Nanostation M2 Loco
Describe the bug
Steps to repro:
Device SetuptabPrimary InputtoDDP(leave secondary input disabled)Output 1toWS2811Save ChangesExpected results:
The
Save Changesbutton should be enabled, and thus clicking on it should save the changes.Actual results:
The button is disabled (HTML attribute). Nothing happens when clicking on it (obviously). The configuration is not saved. Changing to other tab and back loses all changes.
Other bits and pieces
Manually removing the "disabled" attribute in Edge's DevTools (F12) allows saving the configuration.
Reviewing the page in Edge's DevTools (F12) shows the following properties that may be of interest for the save button:
The text was updated successfully, but these errors were encountered: