logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

OpenBeken online building system - compiling firmware for all platforms (BK7231, BL602, W800, etc)

p.kaczmarek2 17562 18

TL;DR

  • OpenBeken’s GitHub online build system compiles firmware binaries for all supported platforms, including BK7231, BL602, and W800.
  • It runs automatic builds for every commit and pull request, then exposes artifacts on the build details Summary page.
  • The repository’s releases tab and commit list provide downloadable binaries, and a first pull request build must be accepted by an administrator.
  • Custom forks can toggle features in obk_config.h, such as the HT16K33 driver, and get all platforms rebuilt without installing a compiler.
Generated by the language model.
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • GitHub logo in black and white.
    OpenBeken, available at Github, features an automatic online build system for all currently supported platforms. This means that you don't even have to setup compiler on your machine in order to compile new binaries. Automatic builds are executed per every commit, including the commits in the Pull Requests. Here I will show you how you can utilize it to compile your own version of OpenBeken or maybe even to develop your own fork.

    Main OpenBeken Releases
    Main releases are available for everybody at the releases tab. Open our repository:
    https://github.com/openshwprojects/OpenBK7231T_App
    Go to releases:
    Screenshot of the OpenBK7231T_App repository on GitHub showing the list of directories and version information.
    In releases, you can find a table of all build binaries for supported platforms:
    https://github.com/openshwprojects/OpenBK7231T_App/releases
    See screenshot below:
    Table of OpenBeken assets for various platforms and usage types.

    Per-commit builds
    Per-commit builds are available for every commit. Some of them are not available in a form of releases, and some of them may have been a release at some point but may have been removed by a developer.
    First you need to see the list of commits, here:
    https://github.com/openshwprojects/OpenBK7231T_App/commits/main/
    Then, notice the green mark, click it:
    Screenshot of a GitHub commit list for the OpenBK7231T_App project.
    Then, on the screen below, click any "Details" link:
    Screenshot of build results in Github Actions showing 9 successful checks.
    Now you should be on build details page:
    GitHub app screen showing build information for OpenBeken.
    Click "Summary":
    Screenshot of the GitHub Actions build process with the Summary section highlighted.
    Scroll down to the bottom of the page:
    OpenBeken build screen on GitHub.
    This "artifacts" file contains all build binaries, download it:
    List of binary files in OpenBK7231T_App_1.17.450.zip archive displayed in an archiving program.
    As you can see, all binaries are here.

    Per-Pull Request builds
    Automatic builds are also available for each Pull request:
    https://github.com/openshwprojects/OpenBK7231T_App/pulls
    This way you can test experimental features before they are merged.
    Please remember that if you open your first pull request, your build first must be accepted by administrator.
    The method of accessing build files is very similiar, just click on "Details" anywhere in PR:
    Screenshot of a GitHub Pull Request interface for the OpenBeken project.
    Then follow the guide from previous paragraph.


    Customizing your own build
    The automated build system can be easily used to customize your own OBK build. For example, let's say you want to enable some feature in obk_config.h:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/obk_config.h
    For example, if you want to enable HT16K33 driver:
    Screenshot of an online code editor showing the obk_config.h configuration file with the OpenBeken repository opened on GitHub.
    You can just change the #define of the feature you want to include and then use online build system (either setup on your own fork, or just create a PR to just get binaries) and you will get everything compiled for all platforms without even setting up one compiler on your PC.

    Summary
    Online Github builds are crucial for development of OBK. They allow us to quickly test compilation for all supported platforms and develop even without having a compiler on our own PC. That being said, testing on physical devices is also very important, but we'll cover it another time. I hope this tutorial can help you build your own OBK fork, especially if you want to just make some little changes and adjustments.

    Cool? Ranking DIY
    Helpful post? Buy me a coffee.
    About Author
    p.kaczmarek2
    Moderator Smart Home  
    Offline 
    p.kaczmarek2 wrote 14438 posts with rating 12403, helped 650 times. Been with us since 2014 year.
  • ADVERTISEMENT
  • #2 20947227
    omniron
    Level 11  
    Posts: 114
    Help: 1
    Rate: 6
    Wow, that's an impressive tool!
    Like gitpod and tasmocompiler etc?

    Can this be used for a direct linked setup?
    Direct as in one tuya device logs into the soft AP WiFi of another and controls it without going through a router/AP?

    Amazing what you are establihing here, you are everywhere, do you ever sleep at all??
  • #3 20947321
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14438
    Help: 650
    Rate: 12403
    Thank you, I think it could be used in similiar manner, but it's still something dedicated a bit more for developers, while users can still use it as well.

    Direct setup is an interesting idea, but what would be a goal here? Creating a system working without a router? It could be done, but we would need to add an option to set a password for AP mode.
    Helpful post? Buy me a coffee.
  • #4 20948178
    omniron
    Level 11  
    Posts: 114
    Help: 1
    Rate: 6
    Yes, exactly, the goal is for instance to be able to power on the plug of the modem/router/APs when returning home (or waking up).
    After having it all turned off when leaving home or going to sleep.
    Tasmota has option WifiConfig 2 for their soft-AP.
    That allows to turn on/off the relay remotely when the main WiFi is out.
    Would be great if OpenBeken allows to set a similar mode up and but use the same credentials as the main WiFi, or something else with encryption as you said.
    Tasmota has no encryption in that mode unfortunatley.
    In that mode OpenBeken then checks each minute or two if the main WiFi is back and reboots itself or switches back to that.
    Many had requested that for Tasmota, since 2018.
    Thanks!
  • ADVERTISEMENT
  • #5 20979807
    divadiow
    Level 38  
    Posts: 4871
    Help: 424
    Rate: 864
    do *we* build our own bins on our own forks or is that something you have to do for each PR?
  • #6 20979829
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14438
    Help: 650
    Rate: 12403
    I think that in order to run a build on my repo, I need to confirm it first there:
    Screenshot from GitHub showing an open pull request requesting approval and build execution.
    However, I think you can as easily just enable building fully on your side, without my intervention.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #7 20979833
    divadiow
    Level 38  
    Posts: 4871
    Help: 424
    Rate: 864
    righto. How do you keep my PR out of the main releases? I'll have a go at setting up my own build system

    Added after 2 [minutes]:

    also. im sure you dont want to be approving PRs left right and centre for other people's experiments
  • #8 21014587
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14438
    Help: 650
    Rate: 12403
    divadiow wrote:
    righto. How do you keep my PR out of the main releases? I'll have a go at setting up my own build system

    It will not be released on the main tree unless I specifically merge it.

    divadiow wrote:

    also. im sure you dont want to be approving PRs left right and centre for other people's experiments

    To be honest, what worst could happen? I don't think that someone could run a really malicious code in the PR. Futhermore, I have a "code changes" view so I can see what I will be running. It is very easy for me to detect suspicious changes or additions in the pull requests.
    Helpful post? Buy me a coffee.
  • #9 21014598
    divadiow
    Level 38  
    Posts: 4871
    Help: 424
    Rate: 864
    Yes. I understand more now since original questions. A voyage of discovery :)
  • #10 21014605
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14438
    Help: 650
    Rate: 12403
    The only thing to watch for which I didn't mention in the first post is that the build binaries seem to expire after some relatively longer amount of time.

    So, if you have a PR to get binaries for a certain driver, you may need to "refresh" it after a month or three..
    Helpful post? Buy me a coffee.
  • #11 21014618
    divadiow
    Level 38  
    Posts: 4871
    Help: 424
    Rate: 864
    p.kaczmarek2 wrote:
    So, if you have a PR to get binaries for a certain driver, you may need to "refresh" it after a month or three..


    fair enough. I did imagine wanting an updated release that included "ENABLE_DRIVER_TMGN" for GN6932 perhaps at some point when more OBK changes generally had been made.
  • #12 21014634
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14438
    Help: 650
    Rate: 12403
    Do you know how to merge upstream (main repository) changes into the PR?

    It can be done via Github GUI.

    That way you can sync your branch to the main branch of the repository.
    Helpful post? Buy me a coffee.
  • #13 21021495
    divadiow
    Level 38  
    Posts: 4871
    Help: 424
    Rate: 864
    ah. I don't think I do. I have wondered about changes made to LN-specific bits, like enabling drivers, that require a linked change in main project. Is this to what you're referring?
  • #14 21021685
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14438
    Help: 650
    Rate: 12403
    I am referring to a situation that happens when you make a fork (with a PR or not) and some new changes are added to the main and you want to merge those changes into your fork.

    This can be done easily in Github GUI.
    In Github GUI, switch to your fork, in my case ln-ps:
    Screenshot of GitHub Desktop UI showing no changes in branch ln_ps.
    Then you can select "update from main":
    Screenshot of a dropdown menu in GitHub Desktop interface with the Update from main option highlighted.
    Then, you may need to solve conflicts (if any):
    Github interface showing modified files in a repository and a conflict resolution dialog box.
    Then, once resolved:
    Github dialog box showing no conflicts before merging.
    And finally, once commited and pushed, you get:
    Screenshot showing the merge information of branch 'main' into 'ln_ps' on Github.
    Helpful post? Buy me a coffee.
  • #15 21191133
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    p.kaczmarek2 wrote:
    However, I think you can as easily just enable building fully on your side, without my intervention.

    Hello!

    I've made a PR just to test a very small change, requiring your approval, as it's my first one, but it would have been better if I could have made the online build on my branch without disturbing you... Do you know how to enable building in one's branch? It could be good to add that to the tutorial...

    Maybe @divadiow can also help...
  • #16 21191191
    divadiow
    Level 38  
    Posts: 4871
    Help: 424
    Rate: 864
    not sure I am certain of enough to be a great help.

    morgan_flint wrote:
    building in one's branch


    does this mean you want to kick off a build and download the zip of binaries off the back of your own PRs?

    If the change is small and in the main repo I tend to just go the file where I want to make the change, switch to the main branch so the edit pencil allows editing, commit changes and open a PR with that change. eg for cmd_main.c

    Screenshot showing the cmd_main.c file in the OpenBK7231T_App repository on GitHub.

    when you commit your changes it makes a new branch with a generic "patch-#" name

    GitHub comparison screen between main and patch-6 branches in the OpenBK7231T_App repository.
    https://github.com/openshwprojects/OpenBK7231...mpare/main...divadiow:OpenBK7231T_App:patch-6

    you can then open a PR which will start a build

    If needing to edit a submodule I fork main and sub then clone to PC. modify .gitmodules to be sure paths and remote addresses and branch details are correct. then I forget what I need to do to push those changes upstream from my submodule into the upstream main repo and ask chatgpt :)

    If I make a mess I delete the lot and start from scratch
  • #17 21191240
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14438
    Help: 650
    Rate: 12403
    Sure, I can enable it, but why do you need to remove a slash?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #18 21192263
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 59
    >>21191240
    The reason is that I had the errors I explained here.

    As there's already a slash in the address in OBK config (e.g. http://192.168.1.249:7231/ if using a local server set up as per these instructions ), the slash I'm removing in my commit originated a double slash in the address of startup.js (e.g. http://192.168.1.249:7231//startup.js).

    This double slash doesn't seem to cause problems when using the default URL (https://openbekeniot.github.io/webapp/) or the local one stated before (no additional path between port and startup.js) but, if I use Home Assistant local server instead, with (URL = http://192.168.1.249:8123/local/), then I get an access error in the webapp when it's trying to access http://192.168.1.249:8123/local//startup.js (note the // before startup.js).

    After your approval, I could download and OTA the binaries with my mod. The webapp works OK with default URL and also with the simpler local one. But with HA's local server, the former error disappeared, but I'm getting new ones (🤦‍♂️). I'll post them in the post referred to before, to avoid going off-topic here but, please, take a look at them there. It's not an important problem, as I have alternatives, but it's more a matter of knowing what is happening

    EDIT: Problem solved with the help of ChatGPT!! I posted the solution in the other thread.
  • #19 21347437
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14438
    Help: 650
    Rate: 12403
    I'm working on something interesting, guys. It's related to our online builds. Who can guess what's happening there?
    Screenshot of a .NET project folder showing various DLL and ZIP files.
    Helpful post? Buy me a coffee.
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ OpenBeken provides an automatic online build system hosted on GitHub that compiles firmware binaries for multiple supported platforms such as BK7231, BL602, and W800 without requiring local compiler setup. Builds are triggered automatically on every commit and pull request, enabling developers to compile custom firmware or maintain forks easily. Users can access official releases with precompiled binaries from the repository's releases tab. The system supports enabling build workflows on personal branches or forks, allowing independent compilation without intervention from the main repository maintainer. Merging upstream changes into forks can be done via GitHub GUI to keep branches synchronized. The build binaries have a limited validity period, requiring periodic refreshes. Discussion also covered potential features like direct device-to-device control via soft AP mode without a router, similar to Tasmota’s WifiConfig 2, including encrypted credentials and automatic fallback to main WiFi. Minor issues such as URL double slashes in webapp startup scripts were addressed through pull requests. Overall, OpenBeken’s online build system streamlines firmware development and testing for various IoT chipsets, facilitating collaborative development and custom feature integration.
Generated by the language model.
Today's popular

FAQ

TL;DR: OpenBeken gives you 3 build paths—releases, per-commit, and PR builds—and, as the author says, "without even setting up one compiler" you can compile firmware for supported platforms like BK7231, BL602, and W800. This FAQ is for developers and advanced users who want custom test binaries from GitHub Actions fast. [#20946719]

Why it matters: You can test OpenBeken changes across multiple supported chips from GitHub alone, then iterate on forks, PRs, and config flags without maintaining a local toolchain.

Option Local compiler needed What the thread confirms Best use in this thread
OpenBeken online builds No Builds run for releases, each commit, and each PR Fast custom firmware and cross-platform testing
Gitpod Not stated Mentioned only as a comparison Conceptual reference only
Tasmocompiler Not stated Mentioned only as a comparison Conceptual reference only

Key insight: The safest low-friction workflow is to edit your branch or fork, let GitHub build it, and use PR builds only for testing. Your code does not enter main releases until it is explicitly merged. [#21014587]

Quick Facts

  • OpenBeken exposes 3 downloadable build sources in the thread: GitHub Releases, per-commit builds, and per-Pull Request builds. [#20946719]
  • Build artifacts are not permanent. The author says binaries can expire after about 1 to 3 months, so long-lived test PRs may need a refresh. [#21014605]
  • A fallback AP-mode idea in the thread checks for the main Wi-Fi every 1 to 2 minutes before rebooting or switching back. [#20948178]
  • The URL bug example is concrete: http://192.168.1.249:8123/local/ plus an extra slash produced //startup.js, which caused access errors on a Home Assistant local server path. [#21192263]

How do I use the OpenBeken online build system to compile firmware for BK7231, BL602, W800, and other supported platforms without installing a compiler locally?

Use the GitHub-hosted build pipeline instead of a local toolchain. Open the OpenBeken repository, choose either a release, a specific commit, or a PR build, then download the produced binaries. The author states the system builds for all currently supported platforms and runs automatically for every commit and Pull Request, so you can make changes and let GitHub compile them for you without installing a compiler on your PC. [#20946719]

Where can I find the main OpenBeken release binaries on GitHub, and how do I tell which file matches my platform?

You can find the main binaries in the repository’s Releases tab on GitHub. The thread says each release includes a table of build binaries for supported platforms, so you identify the correct file by matching the platform name shown in that release list to your target chip or board family. That gives you the official packaged binaries rather than temporary test artifacts. [#20946719]

What are per-commit builds in OpenBeken, and how do I download the artifacts for a specific GitHub commit?

Per-commit builds are automatic binaries generated for each GitHub commit, even when no formal release exists. Use this 3-step flow: 1. Open the commit list on the main branch. 2. Click the green status mark, then Details. 3. Open Summary, scroll to the bottom, and download the artifacts file containing the binaries. This path is useful when a developer removed an old release or when you need one exact revision. [#20946719]

How does a per-Pull Request build work in the OpenBeken repository, and where are the compiled binaries stored after the build finishes?

A per-Pull Request build runs automatically for each PR and lets you test experimental changes before merge. After the build finishes, the compiled binaries are stored as downloadable artifacts in the GitHub build details page; the thread says you reach them by clicking Details, then Summary, then scrolling to the artifacts section. That gives you test firmware without publishing anything as a main release. [#20946719]

Why does my first OpenBeken Pull Request need administrator approval before GitHub Actions will build it?

Your first PR needs administrator approval because the repository owner must explicitly allow the workflow to run. The thread says first-time PR builds must be accepted by an administrator, and later confirms the maintainer sees an approval prompt before a build runs on the main repository. That gate reduces risk before executing code changes inside the project’s GitHub Actions environment. [#20979829]

What is a GitHub Actions artifact in the context of OpenBeken online builds, and why do the build binaries seem to expire after some time?

"GitHub Actions artifact" is a build-output package that stores compiled binaries produced by an automated workflow, with temporary retention rather than permanent release status. In this thread, the artifact is the downloadable file at the bottom of the GitHub build summary page. The author later notes these binaries can expire after roughly 1 to 3 months, so an old PR may need a rebuild to regenerate current downloads. [#21014605]

How can I customize my own OpenBeken build by editing obk_config.h, for example to enable the HT16K33 driver or ENABLE_DRIVER_TMGN for GN6932?

Edit src/obk_config.h, change the relevant #define, and let the online build system compile the result. The thread gives HT16K33 as the direct example and later mentions wanting a build with ENABLE_DRIVER_TMGN for GN6932. This workflow works well for feature flags and small driver enables because GitHub can build all supported targets after one config change. [#20946719]

What's the difference between building OpenBeken on my own fork and opening a PR against the main repository just to get test binaries?

Building on your own fork avoids maintainer intervention, while a PR against the main repository may require approval before the first build runs. The maintainer explicitly says you can enable building fully on your side, without their intervention. A PR-only workflow is still useful for quick test binaries, but a fork gives you more freedom for repeated experiments and avoids asking for approvals. [#20979829]

How do I keep an experimental OpenBeken PR out of the main releases while still using the automatic online build system?

Keep the work in a PR or fork and do not merge it into the main tree. The maintainer answers this directly: a PR will not be released on the main tree unless they specifically merge it. That means you can use the automatic build system for experimental binaries, validation, and driver tests while keeping unstable code out of official releases. [#21014587]

What is meant by merging upstream changes into an OpenBeken fork, and how do I do 'Update from main' in the GitHub GUI?

Merging upstream changes means pulling new commits from the main OpenBeken repository into your forked branch. Use this 3-step flow: 1. Switch to your fork in GitHub. 2. Click Update from main. 3. Resolve conflicts, then commit and push. The thread shows this GUI path and explains it is the way to sync your fork when the main project changes after you opened a PR or started a custom branch. [#21021685]

Why would OpenBeken generate a double slash in a webapp path like //startup.js, and how can I fix URL issues when using Home Assistant local server paths such as /local/?

The double slash appears when the configured base URL already ends with / and the firmware or webapp adds another /startup.js. The thread gives a concrete failing example: http://192.168.1.249:8123/local/ became http://192.168.1.249:8123/local//startup.js, which caused access errors. The user fixed the first issue by removing the extra slash in their commit, then rebuilt and flashed the modified binaries by OTA. [#21192263]

Which approach is better for quick firmware experiments: OpenBeken online builds, Gitpod, or Tasmocompiler?

In this thread, OpenBeken online builds are the better documented choice for quick firmware experiments. Gitpod and Tasmocompiler are mentioned only as comparisons, but OpenBeken’s workflow is described in detail: releases, per-commit builds, PR builds, and config-driven custom binaries without a local compiler. That makes OpenBeken the only option here with a complete, repeatable path from code change to downloadable firmware. [#20947227]

How could a direct device-to-device OpenBeken setup work without a router, using one Tuya device in soft AP mode to control another?

It could work by having one device expose a soft AP and another connect directly to it, instead of both using a router. The thread frames the goal clearly: turn on a modem or router plug when returning home or waking up, even if the main Wi-Fi is off. The maintainer says such a router-free system could be done, but it would need extra AP-mode features first. [#20947321]

What security or usability changes would be needed for OpenBeken AP mode to support a Tasmota WifiConfig 2 style fallback with password protection and automatic return to the main Wi-Fi?

It would need at least password support for AP mode and logic to return automatically to the main network. The maintainer says AP mode would need an option to set a password, and the follow-up describes the desired behavior: fallback control through soft AP, then checking for the main Wi-Fi every 1 to 2 minutes and rebooting or switching back when it returns. The thread also notes Tasmota’s comparable mode lacked encryption. [#20948178]

When my OpenBeken PR build artifacts have expired after a month or two, what is the best way to refresh the branch and generate updated binaries again?

Refresh the branch by syncing it with the latest main repository changes, then trigger a new build. The author warns artifacts may expire after about 1 to 3 months, and later explains the GitHub GUI method: update your fork from main, resolve conflicts if needed, commit, and push. That recreates fresh artifacts and also pulls in newer OpenBeken changes before you download updated binaries. [#21021685]
Generated by the language model.
ADVERTISEMENT