How to version control my own hardware and binary?

[ajfriesen]

I am building a small hardware product and would like to build Tasmota for that.

I need to compile a custom binary because the led is not part of the default binary.

Okay, I got that working with the override file with platform io locally with the Tasmota repo.

I am wondering, how I would start versioning that.

Like, do I fork Tasmota and add my own config and keep rebasing?
Upstreaming, but who will build the binary then and how?

I also would like to build the binary in a pipeline later on and push it as release or package.

I am a bit confused how this should be handled.

Anybody got an idea?

[barbudor]

There's not only 1 answer to that but I can explain what I'm doing that fits my own way, but other approaches could work too

0. I do have a fork of Tamsota although this is not mandatory if you don't consider making changes to the base code and contributing. You can work fine with a direct clone of the Tasmota repository on your computer.

1. To host and version my Tasmota configuration files, I have a private github repo where I host a few things related to home automation including backup of my node-red flows and tasmota folder which contains:

• my user_config_override.h which contains the options for my various binaries
• my platformio_tasmota_cenc.ini which defines my binaries

See Defining multiple custom firmware
This is private because the config includes credentials to my WIfis and MQTT broker.

In VSCode I'm using a workspace which includes both base folders so I can work with files from either Tasmota or from my private repo.

2. Now those files have to "appear" in tasmota folder so they can be taken into account for the compilation
   The solution may depend on your OS and personnal choice
   What works best for me is to use hardware links between the 2 folders so I can edit the files from either Tasmota folder or my private folder.

I can compile my binaries or standard Tasmota binaries as usual and I can manage versions of my personnal files on my private repo .
Note that I am not using PR on my private repo. I directly commit and push on the main branch.

I hope this is clear and can help.

[sfromis]

My setup is not to even have a fork or need to use Git, but separately maintaining my build config settings (what goes in user_config_override.h and around there). Doing a build is based on downloaded source (release or development), saving the whole build output including the settings I used, along with binaries, logs and other files. I may also save the specific source download used (timestamped in the file name), but without including the whole build chain, I have no strong plan for rebuilding very old source. My needs does however not including keeping very old archives of builds and source, but I could.

Of course, this structure is based on me not depending on modified Tasmota source code, needing to merge changes again and again. In practical terms, I've found it nice to do the builds in a Docker container, giving a well-defined "sandbox".

[ajfriesen]

I think this will be my way.

I do not plan to change the core code of Tasmota.
Just my own override.

Then I will keep this in git and can create a pipeline on GitHub actions and one locally with justfile.

Will play around with this idea.

[barbudor]

The only différence with what I'm doing is about versionning the config files which was part of your question. This is why I have that other repo

And I find it much straight forward to perform a 'git pull' than downloading the zip of sources from the git web

[HofeBY2]

@ajfriesen

Eine deutsche Anleitung zum selbst compilieren finden Sie unter

github.com/HofeBY

Das Versionsfile ist im Sourcecode unter

.\Tasmota\tasmota\include\tasmota_version.h

[barbudor]

Nicht comprendo