This seems to be in drv_bl_shared.c . I can easily fix this.
What about this - can we merge your charts changes and Makefile changes first, let's ignore OBK_DISABLE_ALL_DRIVERS and charts on W800/etc for now, and later I will fix OBK_DISABLE_ALL_DRIVERS myself?
I think it's a missing "../src/driver/drv_bl_shared.c", where this is defined.
So I think the correction would be to check for "#if ENABLE_DRIVER_BL09..."?
There seems to be no "upper" define, so we need to check for "ENABLE_DRIVER_BL0937" or "ENABLE_DRIVER_BL0942"??
Added after 2 [minutes]:
You won
p.kaczmarek2 wrote:
can we merge your charts changes and Makefile changes first, let's ignore OBK_DISABLE_ALL_DRIVERS and charts on W800/etc for now, and later I will fix OBK_DISABLE_ALL_DRIVERS myself?
Good idea, can you include only the first commit of PR 1360 ?
As long as OBK_DISABLE_ALL_DRIVERS is enabled, this will mean e.g. a W800 build will include the driver if it's "defined" in obk_config.h, but you won't be able to start it ...
If all was merged, that should be enough so that we could enable charts in obk_config now.
I just tried to download simulator, but it's not found. Hopefully I didn't break anything there?
Added after 6 [minutes]:
Ah, yes, the merges are "only" in the sdks git...
So the submodules should be updated now..
Oh well, it seems you are right that simulator link is dead, but was it ever working? Now when I check it I can clearly see it was not working before in the public releases list? So that may be a separate issue to fix?
I'm not sure, but for release 1.730 I can download the simulator zip file.
And 731 is the one introducing the new "platforms" folder.
Does simulator need to "exclude" some files?!?
I'm not sure, but for release 1.730 I can download the simulator zip file.
And 731 is the one introducing the new "platforms" folder.
Does simulator need to "exclude" some files?!?
I don't think so, but you are indeed right. Maybe it's just a coincidence?
There is something strange at play because I can see that artifacts zip of 1.17.731 still contains obkSimulator_1.17.731.zip, so why would obkSimulator_1.17.731.zip not appear on public releases? Strange.
No, I didn't change anything. Maybe the version number somehow affects the release, wrong wildcards and sometimes zip is not seen correctly? Filename does not match?
Is there a reason for two "*" in path wildcard? But I don't see, why this should be a problem.
And does "can not be read" mean " not found" or maybe " no access" (ownership...)?
Added after 1 [hours] 3 [minutes]:
If I didn't miss something, the sdk updates are still missing to complete the latest changes?
Probably two wildcards means that it's a recursive wildcard, so it matches all directories, but I am not sure. I am not the original creator of this releases code snippet.
It would be very strange if it were an ownership issue, because why then it would first work, then fail, and then again work?
Thank, great. Just trying with a charts build for W800 and LN882H
Added after 56 [minutes]:
ok for LN882H, forgot the discussion about W800 and "ENABLE_DRIVER_BL0937" - next try fixing the for OBK_DISABLE_ALL_DRIVERS
Added after 32 [minutes]:
Found quite some points where the presence of BL09XX was instead "overwritten" by only looking for "OBK_DISABLE_ALL_DRIVERS".
Hopefully I'm finished soon ...
ATM I'm just using "#ifdef ENABLE_DRIVER_BL0937" instead ...
Added after 22 [minutes]:
... hoping for 10th commit now ...
Added after 29 [minutes]:
Yes, finally I did it: W800 is showing charts and I removed "#define OBK_DISABLE_ALL_DRIVERS 1".
So PR#1368 might be a starting point to fix the "misuse" of "OBK_DISABLE_ALL_DRIVERS" instead of checking for energy drivers.
It's not tested with other devices and only tested with BL0937 on one LN882H (and it will definitively fail if only BL0942 is used, for I'm only testing for BL0937).
But it's a start ...
Added after 23 [minutes]:
LN882H with running BL0937 printing the values to charts
Some pin roles requires like two channel fields so I hope this change respects that
Yes, that should work exactly as before:
Therefore the sorted driver selection is still using the original values which are set by the enum in C code. The number of channels is linked to the original list.
BTW: There is one entry I was wondering about: BL0937SEL_n is actually showing 1 channel, while BL0937SEL is configured with 0 channels.
And we could even fix and shorten the text on the page:
Only for button roles another field will be provided to enter channel to toggle when doing double click. It shows up when you change role to button and save.
The last part ("It shows up when you change role to button and save.") is not true any more, number of needed channels now is changing together with the selected role:
Charts should be possible now for every platform with defining it in obk_config (with the known issues on W800 with DISABLE_ALL_DRIVERS defined.
Ring buffer is in testing.
So if you maybe could take a look at PR1368 for some ideas to fix the DISABLE_ALL_DRIVERS issue that would be great.
I can later dedicate some time to testing various combinations (e.g. check if it really compiles on Beken with BL0937 disabled, etc) but that's not a priority.
No, I didn't set them, but these defines are set in obk_config.h for various platforms using energy metering.
The only change to obk_config.h left is commenting out "#define OBK_DISABLE_ALL_DRIVERS 1" for W800.
The change worked as expected for W800:
Drivers are usable now, DS1820 and charts are working.
The change didn't break BL0937, at least for my LN882H smart plug.
Added after 9 [hours] 15 [minutes]:
When waiting for the checks to run on an "online build" I remembered a point seen on local docker builds and maybe there is someone who can decide whether my idea is stupid, impossible or maybe can be implemented:
Every single build will allways download/install the sdks for all platforms and then clear all sdks during a make.
My idea/question is: can a build for a specific platform only install the single sdk needed for this platforms?
There is an option to streamline the build process with what you suggested and also to possibly cache some of the files to speed up the build process as well. But it will entail a lot of changes so that is on a todo list for now. There are also some build actions that are being deprecated soon so I am working on that first and will look into the other stuff soon or "soon" as I am in severe time deficit.
So that the submodule doesn't need updating, could the values for the ota/rf/net start and length be moved into OpenBK7231T_App so a quick easy patch PR in the browser is an option to get a build going with different values?
beken378/func/user_driver/BkDriverFlash.c:46:9: note: #pragma message: DEBUG: The value of START_ADR_OF_BK_PARTITION_OTA: 0x12A000
#pragma message "DEBUG: The value of START_ADR_OF_BK_PARTITION_OTA: " XSTR(START_ADR_OF_BK_PARTITION_OTA)
For the second wish, you need to give input to the build scripts and "forward" it to the chain, or change the build.sh to "import" a file with the values you want.
OpenBK7231N/platforms/bk7231n/bk7231n_os/build.sh
is called from
OpenBK7231N/build_app.sh
which is called by
OpenBK7231N/bXXX.sh (b_full.sh, b_rebuild.sh ...)
I stopped here ...
Added after 2 [hours] 18 [minutes]:
... or you can put a file "key.txt" in /platforms/BK7231N/key.txt and alter build.sh to read it (if that's what you wanted).
No problem.
I must admit I maybe didn't totally understand the question, never having to do changes there.
If you could explain it a bit more, I can find a more intuitive solution.
The main point will probably be the same:
Put the information/values to a place in app repository and change the code in SDK to get the information from this source.
For the first part e.g. I didn't know, if you meant what I tried to code:
In ota.h is the define line with START_ADR_OF_BK_PARTITION_OTA
and I understand you may need to change the value, which needs to be changed in the SDK file BkDriverFlash.c, too?
So I made BkDriverFlash.c to import the header file ota.h and then used the definition from there instead of the value here.
So if you change ota.h at anytime, BkDriverFlash.c will use the changed value w/o any change inside the SDK.
For the key it's a bit more tricky, for the scripts in question are called daisy chained, and you would need to change all scripts if you e.g. want to extend the arguments (though in this case you might also add another function to the BUILD_MODE argument).
I tried another way: if you put a key in the file key.txt in the platforms folder of your device, the build script checks if it's present ( "-e" means if a file exists) and in this case read the content to a variable if it matches the format of a key as I understood it (4 times 8 hex [0- f] and then 5 numbers).
If key is "valid", it's used, if not, it defaults to the value in the script now.
Enjoy your trip!
Added after 10 [minutes]:
Maybe you have an example in a PR to the SDK were I can see the changes you needed?
✨ 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.
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]
