[WLED-IP]/edit fails in AP mode

[Bebick]

Hey guys, i tryed to save and restore my presets based on the instructions of https://github.com/Aircoookie/WLED/wiki/Presets but the site of [WLED-IP]/edit (in my example 4.3.2.1/edit) doesn's show me anything. What am I doing wrong?

I use a WEMOS D1 mini pro with WLED Software 0.11.1. The "Lock wireless (OTA) software update" Button is deactivated.

[Bebick]

[Aircoookie]

Hi! I never ran into that problem before... Do you have a working filesystem (no Error 10 in the main UI)? You can also try a different browser or accessing the /edit page not via the accesspoint but when connected to WiFi.

[twlare]

@Bebick /edit opens a file editor, but does not select a file. Do you see the files listed on the left side? You should see "/cfg.json" and "/presets.json". If you click on "/presets.json" do you see the file in the edit window? A new installation with no presets configured will show "{"0":{}}" on line 1.

[Bebick]

Sorry for the late response. The filesystem works, i don't have any Errors in the main UI. I tryed Mozilla Firefox, Internet Explorer and Microsoft Edge - always the same problem.

@twlare i don't see anything. only the dark gray line. "/cfg.json" and "/presets.json" shows me data.

[twlare]

@Bebick I just downloaded the latest source code and compiled it and now I have the same problem. It worked last week, but now the edit screen is blank. I will investigate further...

[twlare]

@Bebick I started with a brand new WEMOS D1 Mini, downloaded the latest source code, compiled it, and copied it to the D1 Mini. I connected to the D1 Mini via the WLED AP at 4.3.2.1. I received no filesystem errors and got the same result as you - /edit shows a screen with only a black bar at the top. I configured the D1 Mini for Wi-Fi access to my network, restarted, and connected to it via 192.168.1.99. Now the /edit screen shows the proper two files on the left - "/cfg.json" and "/presets.json". I think you should change the status of this issue to "bug".

BTW, I have an earlier version of code running my house lights and /edit works correctly when accessing the ESP8266 via the WLED AP. I seems that this problem is fairly new.

[Bebick]

#

[Aircoookie]

Thank you for finding out this only happens in AP mode!

This has allowed me to find the issue. The edit page (not written by me) depends on the library ace.js which it tries to load from https://cdnjs.cloudflare.com/ajax/libs/ace/1.2.6/ace.js. Of course this is not possible without internet access (which there is not in AP mode). I don't know why it even worked before, maybe the library was cached by the browser. Ace is responsible for the editor and syntax highlighting. I would believe there are two potential solutions to this. The first would be to include ace into the files servable by the ESP. This would make all binaries 80kB bigger though, quite a significant amount. The second would be to add a fall-back to a simple textarea if the library can't be loaded.

[twlare]

Maybe make the inclusion of the library a compile time option for those who wish to run in AP mode.

Or allow it to retrieved from the built-in filesystem. For example: start with fresh WLED, set up Wi-Fi credentials, download ace.js into littleFS, remove Wi-Fi credentials. When WLED serves up /edit page, it tries to load ace.js from littleFS. If that fails, load from Internet (or vice versa). The download of ace.js could be a manual procedure. This is somewhat complicated, but how many people who run in standalone AP mode are editing the presets.json file (except me)?

[Aircoookie]

A compile time option indeed doesn't sound bad!

Retrieving it from FS should already work (although I haven't tested it). The built-in DNS server in AP mode re-routes the request to 4.3.2.1/ace.js where it of course 404's. If the file is present in FS, it should be served :)

[twlare]

I confirmed two workarounds for using the file editor in AP mode:

1. Visit https://cdnjs.cloudflare.com/ajax/libs/ace/1.2.6/ace.js in the Chrome browser. Visit WLED AP at 4.3.2.1/edit - the file editor works correctly. The Chrome browser has cached the ace.js file.
2. Download https://cdnjs.cloudflare.com/ajax/libs/ace/1.2.6/ace.js to your computer. Using workaround 1, connect to WLED AP at 4.3.2.1/edit and upload ace.js to WLED filesystem. Clear the Chrome browser cache and reboot WLED - the file editor works correctly.

[ryansabin]

I was able to resolve this issue with the following changes.

1. Download ace.js from https://cdnjs.cloudflare.com/ajax/libs/ace/1.2.6/ace.js and place in wled00/data/ace.js
2. Modify wled00/tools/cdata.json add the following right under the favicon block { file: "ace.js", name: "ace", method: "binary", },
3. Modify wled00/wled_server.cpp add the following right under the favicon function server.on("/ace.js", HTTP_GET, [](AsyncWebServerRequest *request){ request->send_P(200, "text/html", ace, 354518); });
4. You must run the command "npm run build" as explained on the wiki page https://github.com/Aircoookie/WLED/wiki/Add-own-functionality in the "Changing Web UI" section. This will add ace.js to the wled00/html_other.h file. You can verify this worked by checking if ace.js is at the bottom of this file.
5. Build and upload your code

[embedded-creations]

I'm evaluating lorol's fork of ESPAsyncWebServer which is getting updates as opposed to the stale me-no-dev repo. One of the features is a standalone SPIFFSEditor option:

https://github.com/lorol/ESPAsyncWebServer/commit/406f21c5ddd39a112c5bb90bf95580c39733bde7

Note: the SPIFFSEditor example works differently on the fork. I can only get it to work by serving Ace from the filesystem, and I think to revert to using Ace retrieved from a separate server seems to require editing edit.html, compressing, etc.

After reviewing the commits it seems like the main SPIFFSEditor example has been updated to the latest features.

The SmartSwitch example has some extra features like sharing authentication between pages and a portal for adding your wifi credentials. I got the editor in the SmartSwitch example to work by:

• flashing SmartSwitch example
• ESP8266 LittleFS Data Upload
• Find the network it serves, and add wifi credentials via the portal
• Login to the root page, password "switch"
• Now /edit works

[blazoncek]

What could be done when preparing binaries for flashing is adding a copy of ace.js to a file system. And while we'd do this we could move all html,css and js files to FS to reduce flash memory use. Of course this could then mean that a user could (accidentally) delete those files.

[embedded-creations]

Of course this could then mean that a user could (accidentally) delete those files.

The .exclude.files list feature could be added back so the files could be hidden by default and hopefully are much less likely to be deleted.

https://github.com/Aircoookie/ESPAsyncWebServer/commit/5c274248566a34f9684d85c275e320a5f461d152

[embedded-creations]

There's a couple SPIFFSEditor issues already, rather than make a new one I'll just add to this one, though there's more being discussed than just the AP mode.

I've made some improvements on top of @lorol's fork of ESPAsyncWebServer, the biggest being support for browsing multiple filesystems using SPIFFSEditor. I also improved the SPIFFSEditor "list" request so that it doesn't cause a watchdog reboot if listing a long directory takes too long, and it will also work if the directory listing is so long it won't fit into the response buffer.

The AsyncChunkedStreamResponse I made for "list", and the AsyncStreamRepeaterResponse I added but haven't used yet in an example could be useful for WLED in general. AsyncChunkedStreamResponse lets you use chunked responses as easy as printing to a Stream. AsyncStreamRepeaterResponse lets you print something that may or may not be larger than the response buffer, without needing to break it into chunks. You could have a AsyncStreamRepeaterResponse callback that's basically just serializeJson(doc, printPtr) where doc is huge, and it will call serializeJson() repeatedly, using the section of the printed JSON that's relevant for the current chunk, and throw the rest out. This would make the callback coding very simple, but would waste CPU cycles serializing the sections that aren't necessary for the current chunk. I'm happy to elaborate more and add an example, maybe in a different issue.

https://github.com/embedded-creations/ESPAsyncWebServer/tree/chunkedstream

To compile and run the ESP_AsyncFileBrowser in my fork:

• comment out EDFS in SpiFFSEditor.cpp: //#define EDFS
• add your wifi credentials in ESP_AsyncFileBrowser.ino
• uncomment #define USE_LittleFS
• optionally uncomment USE_SD and define your SD pins
• on first connect use "admin:admin" user/pass

[embedded-creations]

Just in case it helps, here's my complete notes from months ago when I was evaluating @lorol's fork:

- Issues
    - Creating a LittleFS filename without a suffix or trailing slash makes it think it's a directory though it acts like a file, at least briefly (editor opens)
        - See 3 JUL 2020 commit:
        - "For a compatibility, a folder alone cannot be purposely created. A file will be created instead.
        - Note, a confuse may occur: /mystuff could be a folder or a file, both will look same way on SPIFFSEditor web file tree."
    - No highlighting which file is open in editor
        - Actually shown next to the save button
    - No error when trying to delete non-empty folder, but doesn't work
    - Deleting last file from folder deletes folder (expected with LittleFS?)
    - Can't resize sidebar to fit long filenames
        - make hover show full name?
    - Crashing if files (or filesystem?) containing Ace.js, etc isn't loaded
        - Doesn't crash, just loads a boring incomplete page if `EDFS` isn't defined, and Edit is still in filesystem.  Crashes if EDFS defined
    - Can't open uncommon files
        - e.g. `/.exclude.files` or `favicon.ico`
        - Workaround to type filename, press "create", file opens up
    - SD Issues
        - Creating empty folder returns "error 500", but does create the folder
- Changes from master
    - "A (very ugly) workaround at server-side SPIFFSEditor.cpp (and edit.htm source) for old iOS 9 Safari browsers to save current file through ACE editor w/o file upload allowed natively by the browser. Side effect: the line endings are always Win style after saving due to application/x-www-form-urlencoded enforcement of FormData JS"
        - Is that side effect just for iOS 9?
        - Is this what the "Alt." button does next to save?
    - Ace was updated
        - There's frequent Ace and other js.gz files committed, but at least one diff showed identical binaries after compare
    - memory optimizations
    - allow to "download" with more file types by right-click on file tree
    - edit.htm can be binary-embedded in a firmware or a in gzipped file on fs (saves 4k of program storage, RAM usage is identical)
        - To embed: Comment `#define EDFS` in SPIFFSEditor.cpp and run do_emb.bat
        - On fs: Enable `#define EDFS` in SPIFFSEditor.cpp and run do_ed_fs.bat
    - Added ext-searchbox (Ctrl+F) search/replace functionality and -workers (live syntax checkers) to the ace editor - a standalone hack.
    - SmartSwitch changes that probably didn't make it into main example
        - fixed index.html to be minifyable
        - common authentication for all pages
- Other FS fixes that maybe should be merged in?
    - https://github.com/me-no-dev/ESPAsyncWebServer/issues/984

[twintersx]

Just following up on this issue: has there been any recent development in a functional /edit page within AP mode? It seems @ryansabin method works, but ace.json completely fills up the flash. For my use case, I do not want my home WIFI credentials stored in a product someone else has purchased from me. An Internet-less /edit page would be a phenomenal improvement in the consumer product arena of WLED.

[blazoncek]

No. It is a component of AsyncWebServer that is fetched from CDN as it is quite large and would consume too much flash memory and make binary file that much larger.