-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expose WLED_RELEASE_NAME via API and Device info page #3497
Comments
All of this work can be avoided by just providing WLED_RELEASE_NAME via the API. |
|
Regardless of whether this would be helpful, this is also important debugging information just like the build number that is shown on the update and device info pages in the web UI. In fact, I'd like to see the release name on those pages in the UI as well. And I've edited the OP to add this. |
As far as I can tell there are official releases with:
There are plenty more build environments some of which include variants with PSRAM support, disabled core functionalities (IR, OTA), enabled additional usermods. None of them included in official releases. With this information there is no real need for additional information in JSON API as "arch" and "ver" can sufficiently distinguish each of the above (where ESP01 will not allow OTA in any case). And "product" and "brand" are clearly defined in JSON API specification and can be used (by forks or otherwise) to distinguish from official releases as described above. Note: I am trying to justify inclusion of this (and other additional) field(s) in JSON API and judge the impact it may have on performance and/or operation of WLED. ESP8266 is at the limits regarding the size of JSON. It can no longer support 16 segments due to increased JSON content and adding additional fields will limit it further. That's the reason for reluctance. |
unsubscribe.On Nov 2, 2023 9:14 AM, Blaž Kristan ***@***.***> wrote:
you are missing the point. re-read my post. besides, there can be as many different "releases" as there are compile-time options or (more likely) build environments. None of that is happening officially (in the near future). The three release versions for ESP8266 are there just because of 3 different flash sizes (and the 1M version is stripped of OTA capabilities since flash size will not allow it).the only two "official" "optional" releases are Ethernet and Audioreactive (which is technically a usermod but was requested numerous times), all other "releases" feature the same functionality and build options (if there weren't that many GPIOs reserved for Ethernet I would argue to include Ethernet option in every ESP32 build)I may be thinking in a wrong direction, but WLED is not a commercial software it is a DIY project still. So are some forks.
As far as I can tell there are official releases with:
2 build options for ESP8266 (with and without OTA)3 build options for ESP32 (plain, with Ethernet, with Audioreactive usermod)1 build option for ESP32-S31 build option for ESP32-S21 build option for ESP32-C3
There are plenty more build environments some of which include variants with PSRAM support, disabled core functionalities (IR, OTA), enabled additional usermods. None of them included in official releases.
With this information there is no real need for additional information in JSON API as "arch" and "ver" can sufficiently distinguish each of the above (where ESP01 will not allow OTA in any case). And "product" and "brand" are clearly defined in JSON API specification and can be used (by forks or otherwise) to distinguish from official releases as described above.
Note: I am trying to justify inclusion of this (and other additional) field(s) in JSON API and judge the impact it may have on performance and/or operation of WLED. ESP8266 is at the limits regarding the size of JSON. It can no longer support 16 segments due to increased JSON content and adding additional fields will limit it further. That's the reason for reluctance.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>
|
Thanks @blazoncek. I'm thinking about WLED as the centre of a community, rather than as a personal DIY project or a commercial product. I did get these points, but one of the main lessons I've learned in software is to never assume that things won't change. So I'm worried that, while today you can OTA upgrade any of the ESP8266 official builds with the "ESP8266" build, that won't always be the case, just as today you already can't identify which ESP32 build to use for OTA from just the "arch" value, since different builds have different features. There's also no guarantee that there won't be other future official releases that are non-interchangeable. So if there's a solution that helps the community today handle the new builds released with v0.14.0 as well prepare for the future, then I think it's worth pursuing. Furthermore, "explicit is better than implicit", so there's no point in trying to guess which build can be used, if it's possible for the device to tell you exactly. I think it's this guessing that bugs me most. On adding to the JSON API, I agree that this is a big issue: probably the only one that really matters. I get that you don't really want to add anything to the So I'm wondering about the following potential solutions. I'm not sure whether any of them are feasible or permissible, but I thought I'd write them anyway.
What do you think? |
OK. Thinking about this more, I think that (1) is actually the better solution, i.e. that the "product" field should be what's used to differentiate between the different official builds, and that field is already in the JSON API. Otherwise, what's the point of the field? |
With the release of v0.14.2 (https://github.com/Aircoookie/WLED/releases/tag/v0.14.2), this issue needs re-raising. There's now another official build, which is the 160MHz ESP8266 one, and this one is very different for OTA and can result in a failed OTA update. I think this makes it harder to justify not being able to determine exactly which build was used. @blazoncek |
Please make a PR with relevant changes if you think this is so important. |
@blazoncek Are you saying that all of my proposed solutions are acceptable and that all it requires is a PR to move this forwards? Or are you just being rude? |
My intention is never to be rude, though it sometimes appears so. |
I've made a PR for using the product name field, now #3750 has been merged. Seems like the simplest solution and most likely to be acceptable. Separate PR will be required for any changes to the Web UI. |
Based on aa970d6, I think I'm just going to add a field in the info for |
Available since 674481f |
Thank you ❤️ |
I'm looking at adding updating the FW for ESP32-C3, -S2 and -S3 via Home Assistant: frenck/python-wled#1140
It seems like the easiest way to do this would be to get the value of the
WLED_RELEASE_NAME
from the API. Could this be added? e.g. as an optional field in/json/info
?edit I'd also like to see this on the device info page and the update page in the Web UI.
The text was updated successfully, but these errors were encountered: