I’m running WLED 0.13.0-b4 on an AZ-Delivery NodeMCU (ESP8266), and also on a LoLin NodeMCU V3 (ESP-12E). I’m controlling them via the Wled app (V1.0.3 20th July 2019) running on Android 11 (Samsung Galaxy A32 5G).

As far as I can tell, neither the ‘Backup Presets’ nor the ‘Backup Configuration’ buttons do anything, and both the ‘Choose file’ buttons produce the Android message “No apps can perform this action”.

I can also run the same version of the Wled app on Android 6, which gives essentially the same results, except that the ‘Choose file’ buttons produce a small dialog box titled “Choose an action”, but offers no actions from which to choose!

I have unlocked Wireless OTA, and in fact have successfully upgraded these devices from 0.13.0-b2 using the ‘Manual OTA Update’ function (where the ‘Choose file’ button works as expected).

The ‘Choose file’ buttons for ‘Custom CSS’ and ‘Custom holidays’ on the User Interface page also produce the “No apps can perform this action” message.

Is there a bug, or am I doing something wrong?

This is a shortcoming of your Android devices.
Install app that can handle JSON files or use a desktop computer to backup configuration.

I agree with @blazoncek … I had no issues using the desktop UI (which I prefer anyways to do big setups)
I have successfully stored the presets and config files (via [IP]\edit )
Also - to my surprise - updated to the newest WLED OTA without losing any work on that particular board (so I didn’t need the backups after all)

  1. A JSON is basically a text file, and for backup/restore we are therefore copying a text file from one device to another. The Android device has no need to interpret the contents of the file, and therefore there should be no need to install additonal software to handle JSON files.

  2. Using a browser, it is possible to navigate to [IP-address]/edit, and then download both cfg.json and presets.json to the Android device, as described under Presets in the wiki. Equally, it is possible to use the ‘Choose file’ button to select a previously downloaded cfg/presets file and restore it to the wled device. If this can be done from the browser, there is surely no reason why the equivalent operations can not be performed from the Andoid app?

  3. woehaa - thank you for your comments, which are somewhat less than helpful. There are several reasons why I do not wish to use my desktop machine for this purpose. You may prefer that approach, but I do not. In addition, I am well aware that the wled software can be updated without losing the settings - it is something I have done many times previously. You may feel that backups are not needed as a result, but I have several reasons why I prefer to keep backup copies of my setup.

My original bug report still stands.

Ran into the same problem with the file select for OTA update in 0.12.0 and have chosen to remove accept='.bin' there to make it work from within the app again.

It is 100% a device/API shortcoming and happens if we restrict the uploadable file types to just .json/.css/.bin with the accept attribute.
A similar problem is that some devices show a keyboard that does not allow you to type a - in a numeric input.
The problem is that if we implement workarounds (no type restriction for uploads, text fields for negative numbers) it makes it less usable for everyone. When e.g. updating from windows, it was very convenient to have every file that is not e.g. .bin hidden.

@RomneyYW where would you want to store backup of your presets on the phone?
I am unaware of any smartphone that will allow you to save arbitrary files since you do not have access to its file system. Hence non-functioning Backup buttons. An app that could handle JSON files could be selected as destination though.
iPhone will still allow you to save backup if you long-press the backup button. It will save it to Files app.

As far as restoring goes it is the same problem really. Can you tell your browser on your smartphone where CSS files are? You do not have access to file system. Still, if you happen to have an app that can handle “any files” (as Files, DS File, Dropbox on iPhone) you may be able to use that app to provide source for your browser app so restore can be performed.

And, this is not a bug in WLED. :slight_smile:

I remember the OTA update problem with v0.12.0 very well - I experienced the difficulty for myself. When reporting the current issue, I wondered whether it was indeed similar to the earlier OTA issue. It seems that it probably is!

I do not think it is appropriate to use accept= to restrict the uploadable file types. This is forcing Android to treat them as special files, when in fact they are just data objects which should simply be copied from one device to another. The Android device does not need to understand the content of the file, just copy the whole file as required.

This is an Android app running on an Android device. I don’t understand how implementing a “workaround” to make the Android app function correctly makes it less usable for everyone. How does Windows affect the Android app, and who exactly is “everyone”?

If I use my browser to visit [IP address]/edit, I can use the ESP Editor to download cfg.json and presets.json. I am initially offered the [Main Storage]/Dowload folder as the destination, but I can select my SD card as an alternative destination, copying the files to [SD Card]/Download instead. I can see no reason why the Android app should not be able to offer the same choice of destinations, which are perfectly adequate for this operation.

When I come to choose a file to upload, I am given a choice of several apps, including “Files”. I can use this option to choose a file from almost anywhere on the current device, as well as Google Drive, Microsoft OneDrive, or I can select one of the other applications installed on the device, which gives me access to all the other devices on my network. Again, I believe that the same facility should be available to the Android app.

I am surprised by your assertion that I do not have access to the file system. I have more than adequate access to the files on my Android devices. As I have already said above, these files are simply data objects to be copied from one device to another. As far as the Android device is concerned, they should not be treated as CSS, JSON or any other file type, and they should not be placed “where CSS files on my Smartphone are”. The WLED files have nothing to do with Android OS and so I don’t want to put them anywhere within the internal workings of the Android file structure. I can see no good reason why you would want to do so.

While I understand that you do not accept that this is a bug in WLED, when an ordinary user clicks on a button in the reasonable expectation that it will back up the presets, and it doesn’t work, then that LOOKS like a bug to that user…

FYI With modern device it is possible to backup presets and configuration using browser on such device.

This is not forcing anyone to do anything, android UI devs are humans too and they made a poor decision in this case. Same as with some Samsung devices that don’t show a - on the numeric keyboard, so it’s impossible to enter negative values. Android should handle accept= correctly and just offer plain up-/download. Unfortunately this fell victim to the new “a filesystem is too complicated for users, we need to hide it from them in all ways possible” paradigm.

It’s not. It’s just a website basically with the ESP being the server, and that website has no way (at least I don’t know of one) to detect whether it has been opened in the Android app, in the iOS app, on Chrome for android and on a Windows PC. If it can run a recent browser, WLED is compatible with it.

“Use a browser” is indeed the best workaround. I hope we will find a solution to the problem soon, perhaps the app can somehow let the page javascript know that the android app is used, which would then dynamically remove the accept attribute.


Thank you for your comments which have clarified my understanding of wled, although they inevitably lead me to a new question.

I am running the WLED app V1.0.3, downloaded from the Google Play Store on a Samsung Galaxy Tablet (Android 9) and also on a Samsung Galaxy A32 phone (Android 11). On both devices, using the app to backup or restore presets (or configuration) fails in the way I have already described.

However, if I use a browser (Chrome, Samsung Internet) to access my WLED device by IP address from the same two devices, the backup and restore functions work correctly for both presets and configuration.

I am somewhat at a loss to understand why the functions work successfully through the browser but fail to work correctly via the app. Perhaps you could explain why the Android app behaves differently to the browser?

Many thanks, Romney

One is full-fledged browser the other is just system (web) API provided to an application.
The second may lack features of full-fledged browser.