logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

How to create a custom driver for OpenBeken with online builds (no toolchain required)

p.kaczmarek2 11784 142
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #91 21252245
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    max4elektroda wrote:
    Maybe you have an example in a PR to the SDK were I can see the changes you needed?

    yep, sure.

    It's basically about making it easier to change coeff key and/or the partition addresses for the odd non-Tuya devices - eg Uascent Matter devices based on the same Beken modules Tuya uses. I think maybe only I've really played with this and I *can* do it in the SDK submodules, it would just be easier for all if the values were in the main app somewhere and then looked to by the submodule at build time.

    eg this PR changed the RF partition address https://github.com/openshwprojects/OpenBK7231...5d39bd0ceb7ca37d0b704827b372e802b27e656478330

    so this Homekit Matter device could work - https://www.elektroda.com/rtvforum/topic4074263.html


    here are some key and partition changes https://github.com/divadiow/OpenBK7231N/commit/ce8def14c48f8f4eaafbeb7da80d93ef9d2040c8

    in an attempt to get this Uascent Matter device working https://www.elektroda.com/rtvforum/topic4032988-30.html#21138630
  • ADVERTISEMENT
  • #92 21252246
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    Maybe it would be possible to create a "patch" mechanism?
    Insert a file copy between SDK pull and App build.
    So, if Github builds a file, idk, MySdkFile.c from SDK, then in script, we check if this file already exists in platform/override folder, and if so, we copy it over. Or to be more precise - we copy blindly content of platforms/override to platforms or something, after pulling SDKs.
    Then, if you want to modify MySDKFile.c without changing SDKs, you just put the required directory tree in the platforms/overrides folder and online builds do the stuff for you.

    Added after 2 [minutes]:

    In case of @divadiow , he would create file:
    Code: text Expand Select all Copy to clipboard
    
overrides/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c

    in the App repository,
    and then, on build, build script would first pull OpenBK7231N, and then copy "overrides/OpenBK7231N" to OpenBK7231N, so BkDriverFlash.c from divadiow would overwrite old BKDriverFlash.c

    I can explain more, but I hope you get the idea? @max4elektroda
    Helpful post? Buy me a coffee.
  • #93 21252686
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    I really like this discussion, we'll find a good solution :-)!

    >>21252246
    p.kaczmarek2 wrote:
    on build, build script would first pull OpenBK7231N, and then copy "overrides/OpenBK7231N" to OpenBK7231N,

    Good point, I would suggest to go one step further:
    If a script with a defined name is present in a given location ("override.sh", "pre_build.sh" or whatever name makes sense), this will be called before actual start of build process.
    The script can do "simple" task, e.g. just copy a changed file to a location inside sdk, patch a file inside sdk, set some links...
    But it's much more flexible, it could do more complex things, e.g. update sdk (or some libraries) or else do whatever you wish to be done in advance, without need to alter any file outside the app repository.

    Added after 3 [minutes]:

    Will try a PR to show the idea soon
  • ADVERTISEMENT
  • #94 21252807
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    Exciting. Thank you both for entertaining the idea

    Added after 3 [minutes]:

    max4elektroda wrote:
    Enjoy your trip!

    Thank you. I'll still be glued to Elektroda. I have two OBK devices for LED strips with me. I have a vape and two epaper shop shelf edge labels to tear apart while on holiday 🤓
  • #95 21252988
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Just finished PR#1381.

    Changed "Makefile" to execute script files "platforms/<platform>/pre_build.sh" if present.
    Just to show the idea, I made a simple script for all platforms, to echo the path and to show the possibilities, just "touch" a file iside every sdk.
    The scripts also could change/replace/... files inside sdk, and all done from "outside" the sdk!

    Sample output from git build details e.g. for BK7231T:
    Code: text Expand Select all Copy to clipboard
    Run make APP_VERSION=1381_merge_dc279645099b APP_NAME=OpenBK7231T OpenBK7231T
prebuild found for OpenBK7231T
PEBUILD-Test! Executed from platforms/BK7231T!
make APP_NAME=OpenBK7231T TARGET_PLATFORM=bk7231t SDK_PATH=sdk/OpenBK7231T APPS_BUILD_PATH=../bk7231t_os build-BK7231
make[1]: Entering directory '/home/runner/work/OpenBK7231T_App/OpenBK7231T_App'
.....


    Local test when building with docker - searching for the files before build start, after some time and when build is done:
    Code: text Expand Select all Copy to clipboard
    
max@max:~/LN882H/fork/move_ota_rf_net_start/OpenBK7231T_App$ find sdk -name prebuild_was_here
max@max:~/LN882H/fork/move_ota_rf_net_start/OpenBK7231T_App$ find sdk -name prebuild_was_here
max@max:~/LN882H/fork/move_ota_rf_net_start/OpenBK7231T_App$ find sdk -name prebuild_was_here
sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/prebuild_was_here
sdk/OpenBK7231T/platforms/bk7231t/bk7231t_os/prebuild_was_here
max@max:~/LN882H/fork/move_ota_rf_net_start/OpenBK7231T_App$ find sdk -name prebuild_was_here
sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/prebuild_was_here
sdk/OpenW800/src/prebuild_was_here
sdk/OpenBL602/prebuild_was_here
sdk/OpenLN882H/prebuild_was_here
sdk/OpenXR809/src/prebuild_was_here
sdk/OpenW600/src/prebuild_was_here
sdk/OpenBK7231T/platforms/bk7231t/bk7231t_os/prebuild_was_here
max@max:~/LN882H/fork/move_ota_rf_net_start/OpenBK7231T_App$ 
  • #96 21254106
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    To fulfill the requested "copying files to sdk before a build", this could be a script:
    Code: text Expand Select all Copy to clipboard
    
DIRNAME=$(dirname $0);
echo "PREBUILD script! Executed from $DIRNAME!"
# allow whitspace in file or path, so take only newline as seperator
OFS=$IFS
IFS='
'
for X in $(find platforms/BK7231N/override/ -type f);do
   # script is executed from main app directory, so take found file and path as source
   S=${X};
   # destination is path stripped from path to override
   # so inside "override" we have the full path to the file
   # starting with "sdk/OpenBK7231N/..."
   D=${X#platforms/BK7231N/override/};
   # if file is present, we replace it, otherwise file is added ...
   [ -e $D ] && echo "PREBUILD: replacing file\n\t$D\n\twith file\n\t$S" || echo "PREBUILD: adding file\n\t$S\n\tas\n\t$D"
   cp $S $D;
done
# restore IFS to whatever it was before ...
IFS=$OFS


    Test with providing the (changed) file
    Code: text Expand Select all Copy to clipboard
    platforms/BK7231N/override/sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c

    and a new file
    Code: text Expand Select all Copy to clipboard
    platforms/BK7231N/override/sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/this is a new file.c


    this is the result as expected:

    Code: text Expand Select all Copy to clipboard
    
max@max:~/LN882H/fork/move_ota_rf_net_start/OpenBK7231T_App/docker$ docker run -it --env  TARGET_SDKS="OpenBK7231N" -v "$(pwd)/..":/OpenBK7231T_App  openbk_build  | grep -A 3 PREBUILD
PREBUILD script! Executed from platforms/BK7231N!
PREBUILD: adding file
   platforms/BK7231N/override/sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/this is a new file.c
   as
   sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/this is a new file.c
PREBUILD: replacing file
   sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c
   with file
   platforms/BK7231N/override/sdk/OpenBK7231N/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c
max@max:~/LN882H/fork/move_ota_rf_net_start/OpenBK7231T_App/docker$ 
  • #97 21262267
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    that's cool. what are the next steps? I'm not sure what I can help with...
  • #98 21262269
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    I think this is ready to merge?
    Helpful post? Buy me a coffee.
  • #99 21262293
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    p.kaczmarek2 wrote:
    I think this is ready to merge?

    Let me adjust the scripts which only demonstrate the possibility and generate an empty file.
    We could leave them empty for the moment or I could put the "copy code to SDK if present" there.
    It's a developer feature anyway.
  • ADVERTISEMENT
  • #100 21262318
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    Maybe add comments to each file? And, just maybe, create a short tutorial for forum that we can link later to from Readme?
    Helpful post? Buy me a coffee.
  • #101 21262328
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    I think doing a short "tuturial" will be a good idea.
    And I will just leave "empty" script files there, with some commented out sample code if you agree?

    I will give a short notice when I'm done.
  • #102 21262329
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    Ok we can try that.
    Helpful post? Buy me a coffee.
  • #103 21264207
    steelincable
    Level 5  
    Posts: 11
    Help: 1
    Rate: 2
    Can someone point me in the right direction for more info on #6 in the guide - How to debug drivers (on Windows)? I have the project cloned, opened in Visual Studio 2022, and branch set with my code updates. How do I run it so I can debug it, step into it and set breakpoints? I'm new to coding drivers, so bear with me!
  • #104 21264210
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    Are you able to compile the project? I mean, for Windows?
    Helpful post? Buy me a coffee.
  • #105 21264263
    steelincable
    Level 5  
    Posts: 11
    Help: 1
    Rate: 2
    Receiving the error below in vs2022 when attempting to build the solution with defaults. A quick google pointed me in this direction, does this look like the right approach to setting up the IDE? https://stackoverflow.com/questions/41695251/c-microsoft-cpp-default-props-was-not-found

    1>------ Build started: Project: openBeken_win32_mvsc2017, Configuration: Debug|Win32 ------
    1>C:\Users\steelincable\Source\Repos\OpenBK7231T_App\openBeken_win32_mvsc2017.vcxproj(18,3): error MSB4019: The imported project "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.Cpp.Default.props" was not found. Confirm that the expression in the Import declaration "C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\\Microsoft.Cpp.Default.props" is correct, and that the file exists on disk.
    ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
    Build failed.

    Added after 8 [hours] 5 [minutes]:

    OK, I was missing some components in vs and have them added now. Looks like I need to grab some OpenGL bits.

    Screenshot of errors in Visual Studio 2022 during project compilation.
  • #106 21265030
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    max4elektroda wrote:
    I will just leave "empty" script files there, with some commented out sample code if you agree?

    I will give a short notice when I'm done.

    Made my changes to [url=https://github.com/openshwprojects/OpenBK7231T_App/pull/1381PR#1381[/url]
  • #107 21265130
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    Very good @max4elektroda , I merged your changes.

    @steelincable the required libraries are here:
    https://github.com/openshwprojects/obkSimulator
    Just copy and paste..
    See:
    https://github.com/openshwprojects/obkSimulator/tree/main/simulator
    libs_for_simulator directory
    Helpful post? Buy me a coffee.
  • #108 21265240
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Thanks @p.kaczmarek2!
    I also tried to make some kind of simple "tutorial" showing possible use cases here
    Comments, corrections and extensions welcomed!
  • #109 21265358
    steelincable
    Level 5  
    Posts: 11
    Help: 1
    Rate: 2
    Thanks, I got a bit further! Looks like I'm missing glut32.lib. I'm not seeing that anywhere in the simulator files.

    A screenshot displaying a list of errors and warnings in a development environment. The main error is LNK1104 cannot open file 'glut32.lib'.
  • #110 21265391
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    Where exactly is glut32.lib included for you? As far as I remember, there is no glut32.lib dependency, we're using freeglut.lib:
    Screenshot of source code in Microsoft Visual Studio, highlighting a line of code using freeglut.lib.
    Screenshot showing a Windows folder with files including a folder named x64 and a file freeglut.lib.
    Show me what requires glut32.lib and I'll recheck.
    Alternatively, just get glut32.lib from web and it should be okay as well.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #111 21274794
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    max4elektroda wrote:
    Did you find the issue or was it solved by magic? Release 733 is whith simulator zip again...

    The issue still persists.
    This has simulator file:
    https://github.com/openshwprojects/OpenBK7231T_App/releases/tag/1.17.755
    And here it's missing:
    https://github.com/openshwprojects/OpenBK7231T_App/releases/tag/1.17.756
    Also sometimes XR809 build is missing as well? What's wrong?
    The number of released assets varies per release. https://github.com/openshwprojects/OpenBK7231T_App/releases

    It seems like we have a problem to solve, @divadiow, @max4elektroda ...
    Helpful post? Buy me a coffee.
  • #112 21274912
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    can the logging be more verbose for the next few runs?
  • #113 21274940
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    For now, I've only checked related commit, and it seems that 756 simulator zip is in the artifacts package, so the problem must be on the futher stages, maybe in the code that copies it for release?

    Screenshot of GitHub and file explorer window with an open ZIP archive.
    Helpful post? Buy me a coffee.
  • #114 21275284
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    p.kaczmarek2 wrote:
    so the problem must be on the futher stages, maybe in the code that copies it for release?

    That would be my suspected cause, too. But I don't really understand, how this works ...
  • #115 21275584
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    I think it's set in this file:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/.releaserc.yaml
    but I can't imagine why it would randomly skip files, I assumed this file is run once all the previous build steps are ran? Or maybe we have a race condition?
    Helpful post? Buy me a coffee.
  • #116 21278908
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    I tried to understand the logic, but I'm not sure if I did, but this is what I think happens:

    The files used in .releaserc.yaml were put to the folders by OpenBK7231T_App/.github/workflows/workflow.yaml if I got it right.
    Usually the files are copied to output/${{ needs.refs.outputs.version }}/... and then packed as artifacts (by actions/upload-artifact@v3).

    In case of release, the artifacts built before were copied again to output/${{ needs.refs.outputs.version }}/... (by actions/download-artifact@v3) and then finally OpenBK7231T_App/.releaserc.yaml will use the files there to publish the assets.

    What I don't know is, how the actions are called and how/if you know, the one before is completed.
    And, if the workflows are, how to say, atomic?
    Or can there be another workflow running for the same release and somehow interfere?

    Sorry if I raise more questions than providing answers...
  • Helpful post
    #117 21280901
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Taking another look to the logs in

    https://github.com/openshwprojects/OpenBK7231T_App/actions/runs/11548563030/job/32140322154

    Under "Run Semantic Release" you will see:

    Code: text Expand Select all Copy to clipboard
    54 [6:33:44 AM] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/github"
55 [6:33:45 AM] [semantic-release] [@semantic-release/github] › ✘  The asset output/**/obkSimulator* cannot be read, and will be ignored.


    So maybe its just a simple case of windows binary building plus all the tests is takeing too much time?

    What caught my eye was

    A snippet of workflow.yaml configuration file with the section needs: [ refs, build ] highlighted.

    Maybe it's just as simple as add "build2" (doing the simulator build and tests) here, too?

    I opened PR #1405, but I'm not sure, if/how I can test it (it builds fine, but I'm not doing a release in the PR ...)
  • #118 21280922
    p.kaczmarek2
    Moderator Smart Home  
    Posts: 14434
    Help: 650
    Rate: 12399
    Nice find, docs seems to confirm:
    Quote:

    A workflow run is made up of one or more jobs, which run in parallel by default

    I will give it a go.
    Helpful post? Buy me a coffee.
  • #120 21281002
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    well done chaps
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
Report a violation of the law

Topic summary

✨ The discussion focuses on creating custom drivers for OpenBeken (OBK) devices without requiring a local toolchain by utilizing online builds. Key challenges include integrating external libraries such as OneWire and DS18B20 sensor drivers, adapting timing functions (usleep) for precise 1-Wire protocol communication, and handling platform-specific differences across Beken-based devices (BK7231T, BK7231N, W800, LN882H, BL602). Contributors share code improvements, including porting OneWire implementations, refining delay loops with nop instructions, and introducing CRC checks to filter erroneous sensor readings. The DS1820 and DS18B20 temperature sensors are discussed in detail, highlighting their protocol similarities and differences, and issues with timing accuracy and sensor pin selection are addressed. The conversation also covers build system enhancements: restructuring Makefiles into platform-specific folders, enabling charts drivers, resolving conflicts with OBK_DISABLE_ALL_DRIVERS, and proposing a flexible pre-build script mechanism to override SDK files during online builds. This approach facilitates easier customization and patching without modifying SDK submodules directly. The group tests various hardware setups, sensor wiring, and power-saving modes, emphasizing the importance of accurate timing and CRC validation for reliable sensor data. Finally, improvements to the build and release process are discussed, including caching SDKs, selective SDK installation per platform, and troubleshooting simulator packaging in release artifacts.
Generated by the language model.
Today's popular

FAQ

TL;DR: With 3 core code edits and "builds can be done online", OpenBeken users can create, compile, flash, and test a custom driver without installing a local toolchain. This FAQ helps developers add drivers, debug them in Windows, and avoid common DS18B20 and CI build pitfalls in OpenBeken workflows. [#21095505]

Why it matters: This thread turns scattered forum troubleshooting into a repeatable path for writing, building, debugging, and maintaining custom OpenBeken drivers across multiple platforms.

Topic Recommended path Main limitation
New custom driver Fork repo, open PR, use online builds Must register driver in config and tables
Windows debugging Use Visual Studio 2022 + obkSimulator Missing VS components and simulator libs break builds
DS18B20 on Beken Use updated timing code, CRC checks, correct pin and pull-up PowerSave and bad timing can corrupt reads
SDK customization Use platforms/<platform>/pre_build.sh Still needs careful file overrides

Key insight: Online builds solve compilation, not integration. In OpenBeken, the hard part is usually correct registration, platform-specific timing, or SDK/build-system behavior, not writing the first C file. [#21252988]

Quick Facts

  • The basic custom-driver flow uses 3 required integration points: obk_config.h, drv_main.c, and driver declarations in drv_local.h. Without all three, the driver will not register cleanly. [#21095505]
  • The sample DS18B20 reliability test showed a strong PowerSave effect: with powersave 0, one user counted 54 CRC matches vs 29 mismatches; with powersave 1, the same setup had 0 matches vs 95 mismatches. [#21165621]
  • A practical DS18B20 hardware setup that repeatedly worked used a 4.7 kΩ pull-up and P10 on BK7231-based hardware, while P26/PWM5/ADC1 produced unstable readings in one test series. [#21163350]
  • Logic-analyzer work showed why naive delay loops failed: one test firmware produced a reset pulse of 248 µs instead of 480 µs, plus 9 µs and 12 µs delays where 6 µs and 9 µs were expected. [#21189891]
  • A release-pipeline fix restored missing assets by making semantic release wait for both build jobs; after that, release 1.17.759 again showed 22 assets. [#21280999]

How do I create a custom OpenBeken driver with online builds on GitHub without installing a local toolchain?

You create a fork, open a pull request, add your driver to the app repository, and use PR artifacts for online builds. The minimal flow is: 1. Fork OpenBK7231T_App on GitHub. 2. Add your driver code and registration changes. 3. Open a PR so GitHub Actions builds firmware online. The guide states, "builds can be done online," so no local toolchain is required for that path. After merge, binaries for supported platforms become available through the online build system. [#21095505]

What needs to be added in obk_config.h, drv_main.c, and drv_local.h to register a new OpenBeken driver correctly?

You must add a preprocessor define, a driver-table entry, and function declarations. In obk_config.h, add a new #define in the target platform section, such as WINDOWS, so the driver can be enabled per platform. In drv_main.c, add the driver to the main drivers array inside a matching preprocessor block, including its name and callbacks. In drv_local.h, declare the init, second-tick, quick-tick, HTTP, and optional stop functions. The sample driver exposed Init, OnEverySecond, QuickTick, AppendInformationToHTTPIndexPage, and StopDriver. [#21095505]

How can I debug an OpenBeken driver on Windows with Visual Studio 2022 and the obkSimulator project?

Use the Windows simulator build, then debug it like a normal Visual Studio app. Open the OpenBeken Windows project in Visual Studio 2022, compile the simulator target, run it, and place breakpoints in your driver functions. The guide says Windows debugging lets you see variable values, inspect the call stack, and step in or out of calls. Later replies confirmed Visual Studio 2022 works once the required components and simulator libraries are installed. This is the fastest way to debug driver logic before flashing real hardware. [#21095505]

Why does my OpenBeken Windows simulator build fail with missing files like Microsoft.Cpp.Default.props, OpenGL libraries, or glut32.lib/freeglut.lib?

These failures usually mean Visual Studio components or simulator libraries are missing, not that your driver code is wrong. One user hit Microsoft.Cpp.Default.props because required VS components were not installed. Another hit missing graphics libraries and was told to copy the simulator support files from the separate obkSimulator repository, specifically the libs_for_simulator directory. The maintainer also clarified that the project should use freeglut.lib, not glut32.lib, so a stale local setting can cause the wrong dependency error. [#21265130]

What is OBK_DISABLE_ALL_DRIVERS in OpenBeken, and how does it affect custom drivers, BL0937 support, and charts on W800 or LN882H?

OBK_DISABLE_ALL_DRIVERS is a build-time switch that disables driver support on some platforms, and it can block custom drivers or charts even when code compiles. On W800, it prevented charts and DS1820 from being usable until related code paths were fixed and the define was reconsidered. A contributor eventually reported W800 running both DS1820 and charts after removing that limitation and correcting checks that wrongly keyed off OBK_DISABLE_ALL_DRIVERS instead of energy-driver defines like BL0937. LN882H also benefited from the same cleanup. [#21244589]

How do pre_build.sh scripts work in OpenBeken platform folders, and when should I use them instead of modifying SDK submodules directly?

A pre_build.sh script runs before the platform build and lets you patch or replace SDK files from the app repository. The new mechanism executes platforms/<platform>/pre_build.sh if present, so you can copy override files, patch SDK sources, or prepare special builds without editing SDK submodules directly. This is best when you need a quick browser-based PR or per-platform override, such as custom partition addresses or encryption-key handling. It keeps the change in OpenBK7231T_App and avoids repeated SDK-submodule edits. [#21252988]

DS1820 vs DS18B20: what are the protocol and feature differences, and which one is actually supported by the OpenBeken DS1820 driver?

They are similar 1-Wire temperature sensors, but they are not the same part. The thread notes DS1820 and DS18B20 differ in resolution, family code, and command details, even though both use 1-Wire. In practice, the OpenBeken driver named DS1820 was developed and tested mostly with DS18B20 sensors; several participants explicitly said they only had DS18B20 hardware. Later discussion also treated the missing “B” as naming shorthand, not a strict exclusion. So the current driver name is historical, but real-world testing focused on DS18B20. [#21154798]

Why does the OpenBeken DS1820/DS18B20 driver show CRC errors, reset failures, or random temperatures like 53°C, 86°C, or -3817°C on BK7231 devices?

The direct cause is bad 1-Wire timing, often combined with unstable pins or power-saving effects. Users reported jumps to 53°C, 86°C, and even -3817.93°C, plus Reset failed and all-ff scratchpad reads. The main diagnosis was that delay timing on BK7231-class devices was inaccurate, so reads happened too late or reset pulses were out of spec. One maintainer summarized it plainly: "The less loops you use, the more precision you get." CRC checks later stopped many bad values from appearing, but they did not fix the underlying timing problem. [#21158429]

Which pull-up resistor and pin choices work best for DS18B20 on BK7231, BL602, W800, and LN882H, and how much do timing differences matter?

A 4.7 kΩ pull-up and a simple GPIO such as P10 worked better than overloaded pins in the thread tests. One BK7231 user saw unstable reads on P26/ADC1/IRDA/PWM5, then improved behavior on P10/RX1. Another user said 5.1 kΩ should not be a major problem, but later switched to 4.7 kΩ anyway. On other platforms, BL602, W800, and LN882H all needed platform-specific timing behavior, and W800 was described as especially solid once timing matched. Timing mattered more than brand authenticity of the sensor. [#21163350]

How does PowerSave affect DS18B20 reliability in OpenBeken, and why can the same sensor work with powersave 0 but fail with powersave 1?

PowerSave changes timing enough to make marginal 1-Wire code fail. In the clearest test, the same BK7231 setup with startDriver DS1820 18 produced 54 CRC matches and 29 mismatches at powersave 0, but 0 matches and 95 mismatches at powersave 1. Later timing changes improved this substantially, and a newer test with revised code showed valid DS18B20 readings even under PowerSave 1. The lesson is simple: if DS18B20 is unreliable, test with powersave 0 first, then verify whether newer timing code fixes low-power mode. [#21165621]

What is the best way to tune or redesign usleep timing for 1-Wire sensors in OpenBeken instead of relying on nop loops and BKfact values?

Use separate short, medium, and long delay paths plus critical sections, not one generic nop loop. Early work tried BKfact tuning and auto-scaling, but logic-analyzer tests showed that approach could not satisfy both short and long 1-Wire timings. One contributor measured a reset pulse at 248 µs when it should have been 480 µs, proving the loop design was fundamentally wrong. The later redesign split delays by time range and borrowed critical-section ideas, which made PowerSave and multiple platforms behave much better. [#21189891]

How can I get DS18B20 readings into OpenBeken scripts and MQTT instead of getting 0 when using setChannel and publish commands?

You must let the driver update a channel, then publish that channel after a valid reading exists. A user tried setChannel 7 DS1820 and publish sensor_temper $CH7 but got 0, which triggered follow-up work so the driver could expose temperature as a channel value. Later discussion shows the fix direction was to set the channel only when a fresh valid reading exists, not on failure. That prevents stale or zero data from being republished forever and makes scripting and MQTT reflect actual sensor state. [#21305277]

What should OpenBeken publish to MQTT or Home Assistant when a DS18B20 reading fails or the sensor is disconnected: keep the last value, send -127°C, or publish an error state?

The best current direction is: do not keep publishing stale values, and do not force -127°C unless you want an explicit error marker. The thread rejected endless reuse of the last good temperature because it hides faults. It also questioned publishing -127°C, since that can pollute Home Assistant graphs. The preferred proposal was to skip SetChannel when no new value exists and eventually add a shared error topic for states like sensor missing. That gives HA and MQTT clients a real failure signal without falsifying temperature history. [#21305277]

Why do some OpenBeken release assets like obkSimulator zip or XR809 builds randomly disappear from GitHub releases even when they exist in artifacts?

The root cause was a GitHub Actions workflow dependency problem. Semantic release sometimes started before all build jobs had finished, so assets existed in artifacts but were not ready when .releaserc tried to publish them. The telltale log line was that obkSimulator* "cannot be read, and will be ignored." A fix made semantic release depend on both build jobs, and release 1.17.759 returned to 22 assets. Missing XR809 assets in some releases were separate cases where that platform simply failed to build. [#21280908]

What's the purpose of moving platform Makefiles into the OpenBK7231T_App platforms folder, and how does that improve online builds for W600, W800, LN882H, and XR809?

It moves platform-specific build logic into the main app repository so online-build changes no longer require direct SDK edits. The contributor proposed placing per-platform Makefiles under platforms/<platform>/Makefile and making SDK Makefiles include them. That lets developers adjust app-side build behavior for W600, W800, LN882H, and XR809 through normal PRs in OpenBK7231T_App. The immediate benefit was simpler online-build maintenance and easier future feature enablement, such as charts, without constantly modifying each SDK submodule first. [#21242608]
Generated by the language model.
ADVERTISEMENT