Feature request: Front end for user centric parameters

[c64emulator]

I would suggest a front end for some user specific parameters. Values like WEATHER_LOCATION, On-Time/Off-Time (showing the LED from On-Time to Off-Time), brightness, .., and some system parameters like timezone, OTA-URL ... should not be hard coded.

[JanPetterMG]

Interesting idea, it isn't hard, you're absolutely right.

Hiding everything behind a "code-wall" is probably hindering a lot of people from getting started, not great.
On the other side, there's several hundred different ESP32/ESP8266 models on the market, most are compatible with this project (with some minor tweaks anyway). Although I really want to, I don't think it's realistic to create a nice web-GUI where everything from weather location to GPIO-pins all can be set. It isn't as hard as it might sound like, but I think that if someone is able to compile and upload, they're definitively able to edit a config file, so in the end, what are we going to achieve?

I'm here to discuss, not reject. I've been thinking about things like this, among other ideas, to make the project more "accessible" to end-users. Wi-Fi can be changed on-the-fly if needed (changing passwords etc.), but how often do someone "move" their device so far away so that the weather doesn't match anymore? Not to mention flash size requirements, I don't think we can fit it all on a 4MB chip anyway, sadly enough...

Trust me, I'm in the same boat, even "managing" a remote device for someone that doesn't even know what an ESP32 is...

When it comes to home automation stuff, like timers, brightness, etc., I've found multiple great "accessible" and "easy to use" solutions, so I'm not really worried about that part now anymore.

If you didn't know, there's TWO working OTA methods in this project already, in addition to wired upload (making it 3 in total). Why? ¯_(ツ)_/¯. Still I'm thinking a lot about how to getting people to update when new features and improvements are getting introduced, because none of the OTA methods are particularly user-friendly.

People might have other opinions, but so far I'm leaning towards saying "look at all the advantages of upgrading, just download a fresh copy and flash it with a fresh set of variables", whenever the need arises.
There's probably devices out there running 2 year old code, lacking all the goodies, how do we make an even better experience, so that people want to upgrade?

I'm eager to hear your all's opinions, what do you all wish to see in the future?

[c64emulator]

I never requested a web gui for system configuration. Setting the controller model and assigning pins is done one time during compilation and without dynamics. And this is not a task for end users.
My use case is different: In the meantime I have modded seven (7) LED-panels. Gifts for my children (already students) and some friends (getting 60)... This panels are mostly distributed all over Germany: one panel is in Darmstadt, one in Frankfurt/M., one in Berlin, one in Würzburg, one in Bad Kissingen, one in Karlsruhe. And one on the Canary Islands (different timezone!).
So, I have to compile everytime several variants just for setting the WEATHER_LOCATION or/and the timezone.
When my children are done with studying they will move for sure...
Besides the lacking on site customizing (this is not user friendly) managing the code on my side is a challenge.
OTA-Updates are not reasonable for all this variants, one generic file is necessary (using persistent configuration data already on the flash memory). OTA-Updates should be possible from a customizable side (e.g. from my cloudspace) by downloading just a bin/hex-file, no hard coded ip in my local network. I agree that OTA-updates need some extraspace on flashmemory of the ESP therefore it may not work an all ESP devices.

[c64emulator]

BTW: it seems that the "Last chance sale" has started. I just got a OBEGRÄNSED-panel at my local IKEA store for 44.99€ (family price: 49,99€ - 5€ bon on top for "scan&go")

[JanPetterMG]

I see where this is going... You're looking at things from a more business-alike aspect.

Personally I have a few "modded" devices where the open-source projects went this direction, ending up with 20+ download links on GitHub for different devices. It sometimes became confusing witch file to download or what board to choose when there's multiple similar, but no exact match due to different hardware revisions.

Uploading OTA via user-friendly Web-UI just to find myself struggling with boot issues and having to flash using UART-pins instead... Yeah, it's great when everything is maintained and there's a limited set of options, but it can also become really messy when different boards that look vastly different from each other, actually share the same firmware, and those who look identical with (almost) the same name, doesn't.

As previously mentioned, there's two OTA methods in the project already, one of them has the ability to provide an optional button in the UI if desired, to let the user upload firmware manually. I think only a tiny handful of lines is required in the back-end. While it's possible to just "slap" a button on to the front-end with 1 line, I think front-end will be the most demanding part.

Building 7 different firmware files is manageable, although not ideal. Why not submit an PR, for both features?
I've actually tested it in my "private" fork, implemented weather input parameters in the Web-UI along with different other parameters such as API-keys and optional query, but it quickly doubled the amount of code, for each of the 5 different weather services. With constants as default values on top of that, it wasn't really something I was willing to maintain...

---

After I saw this thread, I got an idea for a different approach. If people are able to download Visual Studio Code, a fresh copy of the project (via provided link) and literally copy/paste some pre-written config from the Web-UI, they should be able to update (or change variables) of existing devices with little to no prior knowledge.
No uncertainty here, and it is universally compatible with all 300+ boards on the market the end-user possibly might have chosen from.

This list is dynamically built, reflecting the "actual" build config. Each variable has a separate link so that it's possible to look up the documentation and even where/what it is used for in the source code. There's also additional config options available, like for example timer for the display, but I'm only showing what's actually matter (non-default values).

The list lives in the Web-UI. For now, the download button is separate, but I plan on having that too on the same page once I settle on the final design.

Yes, you can literally copy/paste, and no, the PlatformIO file is arranged differently, so that you don't have to provide library lists or any other variable for that sake. Extra software needed for compiling? Don't worry, PlatformIO is installing that part too, automatically. It's hands off, really!

EDIT:

Setting the controller model and assigning pins is done one time during compilation and without dynamics. And this is not a task for end users.

Soldering is definitively not for end-users, downloading a piece of software from the internet and compiling it, without a degree in programming, yeah, that's the easiest part. These days, even AI can write code for you. 😉

[JanPetterMG]

I wouldn't recommend it to most users, but for convenience in remote areas or as a pure backup method, sure.
How about something like this?