But one thing still confuses me - if the problem was caused by "build2" finishing too late, then why sometimes also other assets were not present? "build2" does only Simulator (Windows) build...
Helpful post? Buy me a coffee.
Czy wolisz polską wersję strony elektroda?
Nie, dziękuję Przekieruj mnie tam
p.kaczmarek2 wrote:But one thing still confuses me - if the problem was caused by "build2" finishing too late, then why sometimes also other assets were not present?
max4elektroda wrote:I'm not sure, if my "fix" really is a fix
merge:
runs-on: ubuntu-20.04
needs: [refs, build, build2]
steps:
- name: Merge Artifacts
uses: actions/upload-artifact/merge@v4
with:
name: ${{ env.APP_NAME }}_${{ needs.refs.outputs.version }}
delete-merged: true
- name: Cache Python packages
uses: actions/cache@v3
with:
path: ~/.cache/pip
key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }}
restore-keys: |
${{ runner.os }}-pip-
- name: Install Python dependencies
run: pip3 install -r requirements.txt- name: Cache APT packages
uses: actions/cache@v3
with:
path: /var/cache/apt
key: ${{ runner.os }}-apt-cache
restore-keys: |
${{ runner.os }}-apt-cachemax4elektroda wrote:So my conclusion, if I didn't miss something: Nice idea, but not reachable with a reasonable afford.
max4elektroda wrote:What do you think about this "timeout"?
DeDaMrAz wrote:Unfortunately I only have DS18B20 sensors to play with right now
max4elektroda wrote:If you refer to my posting about DS1820: This is just laziness in my writing- I don't have any DS1820, only DS18B20, too but simply just "ignore" the "B" in my posts...
p.kaczmarek2 wrote:Just don't' call SetChannel if there is no new value read.
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]
obk_config.h, drv_main.c, and driver declarations in drv_local.h. Without all three, the driver will not register cleanly. [#21095505]powersave 0, one user counted 54 CRC matches vs 29 mismatches; with powersave 1, the same setup had 0 matches vs 95 mismatches. [#21165621]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]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]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]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]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 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]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]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]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]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]-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].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]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]