Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
Addition to the build scripts, that makes it fairly easy to solidify external Berry code into the firmware image.
Provided Berry files must contain only 1 module or 1 class. Otherwise this will lead to undefined behaviour.
Typical use case should be to host specialised code for certain device in a GH repo, but any open or private http server will be fine.
Usage:
Add entry custom_berry_solidify to a build environment with one or many Berry files - one per line.
Example:
These files must be written in compatible way to be solidified, which is non trivial and out of the scope of this explanation.
Besides other things the name of the module or class must be declared with a special meta comment, which is already used in Tasmotas embedded Berry code:
#@ solidify:class_name
or
#@ solidify:module_name
It is recommended to run a clean after compilation, as the source code in the lib folder will temporarily be modified - but not much. This is meant mainly in the context of development to avoid unwanted GIT actions.
Currently Windows does not support solidification.
@arendst @s-hadinger
We can leave this PR open until we are sure how to handle the Windows problem. I can turn it off for Windows to avoid user confusion.
Checklist:
[x] The pull request is done against the latest development branch
[x] Only relevant files were touched
[x] Only one feature/fix was added per PR and the code change compiles without warnings
[x] The code change is tested and works with Tasmota core ESP8266 V.2.7.6
[x] The code change is tested and works with Tasmota core ESP32 V.3.0.0
s-hadinger
commented
1 month ago
Description:
Addition to the build scripts, that makes it fairly easy to solidify external Berry code into the firmware image. Provided Berry files must contain only 1 module or 1 class. Otherwise this will lead to undefined behaviour.
Typical use case should be to host specialised code for certain device in a GH repo, but any open or private http server will be fine.
Usage: Add entry
custom_berry_solidifyto a build environment with one or many Berry files - one per line. Example:Then just build as usual.
These files must be written in compatible way to be solidified, which is non trivial and out of the scope of this explanation.
Besides other things the name of the module or class must be declared with a special meta comment, which is already used in Tasmotas embedded Berry code:
#@ solidify:class_nameor#@ solidify:module_nameIt is recommended to run a
cleanafter compilation, as the source code in the lib folder will temporarily be modified - but not much. This is meant mainly in the context of development to avoid unwanted GIT actions.Currently Windows does not support solidification. @arendst @s-hadinger We can leave this PR open until we are sure how to handle the Windows problem. I can turn it off for Windows to avoid user confusion.
Checklist:
NOTE: The code change must pass CI tests. Your PR cannot be merged unless tests pass