Skip to content

Reserve "FOSS" product name for official builds - #3925

Closed
jamesmyatt wants to merge 1 commit into
wled:0_15from
jamesmyatt:identify_official_builds
Closed

Reserve "FOSS" product name for official builds#3925
jamesmyatt wants to merge 1 commit into
wled:0_15from
jamesmyatt:identify_official_builds

Conversation

@jamesmyatt

Copy link
Copy Markdown

If the "FOSS" product name is reserved for official builds, then it becomes much easier to identify devices that have official builds from the Aircoookie repository.

  • WLED_BRAND_NAME = "WLED" --> Implies it uses the Aircoookie version of the source code. Forks should use a different value.
  • WLED_PRODUCT_NAME = "FOSS" --> Implies it's an official build. Unofficial ones should use a different one. The default for custom builds is now "DIY".

@blazoncek

Copy link
Copy Markdown
Contributor

IMO that's as good as nothing. It does not change anything on forked repositories as anyone is discouraged to modify platformio.ini and use platformio_override.ini instead. So the outcome will be the same regardless of which branch is used in such repositories when using default environment builds.

And if a user/vendor chooses platformio_override.ini there are still no guarantees that he/she doesn't copy entire PIO environment.

@jamesmyatt

Copy link
Copy Markdown
Author

As you've said before, you can't control the behaviour of people who make forks, especially with an open hobby project like WLED, so there are no guarantees ever. But you can make the default behaviour follow what you would like, give them the hooks to do do the same and have consequences if they don't. Here, the consequences are that third-parties like Home Assistant might try to OTA your device with the official version of the firmware.

As an initial step, this PR changes the default behaviour to be that the product name is different depending on whether you use a build config from the platformio.ini or from the platformio_override.ini, which is not nothing.

It also asks people nicely to change WLED_BRAND_NAME (in const.h) if they make any changes to the source code. Which is also not nothing.

Comment thread platformio.ini
# Note that WLED_BRAND_NAME='"WLED"' identifies the source code as coming from the Aircoookie repository. Forks should use a different value.
# Official builds from this repository have WLED_PRODUCT_NAME='"FOSS"'. Unofficial builds can have other values.
# Note that third-party components may use these values in order to OTA update your device's firmware using these builds,
# overwriting any custom firmware that you have loaded.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's almost certainly a better place to put this text. Where is that?

@jamesmyatt

jamesmyatt commented Apr 23, 2024

Copy link
Copy Markdown
Author

For context, I want to make some updates to the python-wled library that Home Assistant uses for WLED integration, which suffers from three key problems relating to OTA updates:

  1. It only looks at the official Aircoookie github repo. My solution is to use the "brand" to identify which github repo to use. For example, I think MoonModules uses "WLEDMM".
  2. It can't identify custom builds. My solution is to use the "product" to identify the official builds. For example, official builds use "FOSS" and custom ones use something else. <-- this PR
  3. It has to guess which build to use from the arch and other parameters from the info. My solution would be to store the release name directly, but that's a separate topic.

@jamesmyatt

Copy link
Copy Markdown
Author

Ah. That's not how MoonModules works at all! I was misled by looking at the wrong source code file.

json.cpp suggests that they use "brand" = "WLEDMM" or similar, but they actually use "WLED" and have the "product" set to "MoonModules" instead.

So problem 1 has to be solved with a combination of "brand" and "product" together, rather than just "brand".

@jamesmyatt jamesmyatt closed this Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants