logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda
Discover miniature XIAO boards »
Discover miniature XIAO boards » ESP32-S3 • nRF52840 • RP2040
ADVERTISEMENT
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

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

p.kaczmarek2 11076 142
ADVERTISEMENT
Report a violation of the law
Reply Cool? Ranking DIY | New topic
Notify about new articles
📢 Listen (AI):
  • #121 21281089
    p.kaczmarek2
    Moderator Smart Home  
    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.
  • ADVERTISEMENT
  • #122 21281207
    max4elektroda
    Level 24  
    While at it, I tried to get rid of the warnings about deprecated workflow elements.
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1406

    Changing the upload/download to v4 needs to change the upload a bit:

    The artifacts name need to be unique (even if it's only a folder containing different files during upload as in this case).

    This has the (nice?) side effect, that all artifacts are build per platform:

    View of build results on GitHub Actions with warnings about deprecated elements.
    If we need one single file again, we would probably need first to do the builds and later do the upload in one step for all files.

    It seems to work for a release, too (see my tests here https://github.com/Max4OBK/OpenBK7231T_App/releases) but is not heavily tested...

    Added after 17 [minutes]:

    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?

    I'm not sure, if my "fix" really is a fix, it was just an educated guess ;-)

    At least for e.g. 1.17.755 this is quite understandable, the firmware images were simply not build for W800 and XR809

    https://github.com/openshwprojects/OpenBK7231T_App/actions/runs/11435374204

    Screenshot of the GitHub Actions workflow for the OpenBK7231T_App project.

    Added after 7 [minutes]:
    max4elektroda wrote:
    I'm not sure, if my "fix" really is a fix

    ... but if you simply compare the workflow "pictures" before and after this commit, it looks better now:

    A workflow diagram showing the build process with tasks: prepare CI environment, build simulator, and semantic release.

    Now "semantic release" also is a "successor" to the simulator build, in the picture above, this build was a leaf
  • #123 21282255
    p.kaczmarek2
    Moderator Smart Home  
    I see a second version of fix evolved here:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1407
    With an extra merge step:
    Code: text Expand Select all Copy to clipboard
    
  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

    I think I will merge that one, but can you first double-check it?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #124 21282365
    max4elektroda
    Level 24  
    I saw that one and it fixes all warnings as far as I can see. I just try to run it in my repository, but there is something strange with gh atm:
    workflow is running since more than 30 minutes now, can't be cancelled ...
    Will report back later if it's working again.

    The actual state is, that even after I tried to cancel, it runs further???
    And this is strange, too: it claims "merge" was run, even though the steps before are not complete ?!?
    Window displaying the progress of a CI workflow on the GitHub platform.

    But I'm quite sure, there is something strange on GH. "Update": Just now, the workflow finished - after 46 minutes!

    Back to the other PR: My only "concern" about the new solution is, that I started to like the way artifacts were build with "my" approach (one zip per platform) and this enhanced version will build one zip for all as before (that's the merge step you mentioned).
  • #125 21282418
    DeDaMrAz
    Level 22  
    @max4elektroda

    When I looked into that V4 transition some time ago I had the exact same idea!! And I also thought it would be much better as we can maybe implement per device and per driver build and I even discussed with @p.kaczmarek2 about it 🙂

    To be hones I am not sure why I gave up on that idea :)

    On the GH issue, I run across it yesterday as well, where build will say it is still going but if I refresh the page it will say done 15 minutes before... no idea.
  • #126 21282445
    max4elektroda
    Level 24  
    Thanks again, it works as expected!
    "My request" would be a simple "keep merged files" - see my comment in GH, too.
    This way we keep the possibility to download all artifacts as before and have the "plus" of selective download.
  • ADVERTISEMENT
  • #127 21282460
    DeDaMrAz
    Level 22  
    I agree to that request, up to @p.kaczmarek2 to decide and implement though. Worth mentioning that artifacts are by default kept for 90 days "only". Basic idea was to preserve the publishing process but update the actions, maybe that is why I gave up on the idea, it would take too much time to implement per platform/driver publish.

    Again, thank you for the hint and inspiration!
  • #128 21282468
    max4elektroda
    Level 24  
    If I may express my next wish: Can you give me a hint, how the single builds could be "tweaked"?
    My goal/idea was keep the build runs per platform "smaller".
    Now every build downloads and updates e.g. all sdks, but if I'm not mistaken it needs only the "own" sdk. So there is a lot of overhead in terms of time (and memory).
    I would need some input, where I can start if I want to change this behavior. Not sure, if I can achieve anything, but I think it's worth trying ..
  • #129 21282491
    DeDaMrAz
    Level 22  
    What I have learned (never before touched GH building processes) based on other people's work is that we can speed it up and possibly make it smaller by maybe caching of system dependencies and python packages.

    Examples given for python:

    Code: text Expand Select all Copy to clipboard
    - 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


    and system:

    Code: text Expand Select all Copy to clipboard
    - name: Cache APT packages
  uses: actions/cache@v3
  with:
    path: /var/cache/apt
    key: ${{ runner.os }}-apt-cache
    restore-keys: |
      ${{ runner.os }}-apt-cache


    The rest of optimization can probably be found in the build logs but I never had time to look into that.
  • #130 21282618
    max4elektroda
    Level 24  
    Thanks, I think the basic "cause" is the structure of OBK: since it grew to support more and platforms, we had the need for additional SDKs and all are present in the APP directory and updated before a build starts. So I would think it's almost impossible to change this without a complete redesign and this is out of question.
    We might save resources (but increasing time) by doing all builds after each other, like a local docker build.
    This way we would still download all SDKs for this run, but we would also need all SDKs.
    But since then all builds would be done build by build, we would need much more time.

    So my conclusion, if I didn't miss something: Nice idea, but not reachable with a reasonable effort.
  • #132 21282650
    max4elektroda
    Level 24  
    max4elektroda wrote:
    but not reachable with a reasonable afford.
    Kind of funny wrong wording, seems I couldn't afford the effort ;-)
  • #133 21293409
    max4elektroda
    Level 24  
    @divadiow and @p.kaczmarek2: I would like to discuss another possible issue and solutions with DS1820 driver.

    When writing the driver the sensor readings from DS1820 were merely made for displaying the temperature on the main screen.
    There you will also see, when the shown temperature actually was read.
    I did point this out, because the last temperature read is "kept forever", even if connection to the sensor is lost or other problems arise.

    Since the latest changes, the temperature is also set as a channel value which probably will need a change in this behavior:
    If the temperature is sent via MQTT, the last seen temperature will also be "sent forever", which is not so good.

    So I wonder how to handle this to make it clearer: My first idea is we should "invalidate" the temperature after a defined time, e.g. after 5 minutes without a proper reading.

    What do you think about this "timeout"?
    Since I use neither HA nor MQTT I don't know, if/how this can be transferred to publishing the values.
    If searched a bit and would think we need to somehow send "UNDEF" in case the tenmerature is in an undefined state.

    How could this be realized? Is there maybe already an implementation for this?
    I know I can e.g. set a "channelType Temperature_div100", but I don't know, if this has impact on what is published on the channel and how I can set the channel to publish "UNDEF" or whatever is needed...
  • #134 21293576
    divadiow
    Level 38  
    max4elektroda wrote:
    What do you think about this "timeout"?

    Behaviourally, yes, I'd much rather know it had stopped working. I'm not big on MQTT/HA but do have an HA server running for testing. I wonder what happens when you unplug other sensors when the device is still communicating to HA. I'll try something.

    What would be the advantage of waiting any longer than 1, 2, 5 etc mins until the device set the sensor to null/failed/off?
  • #135 21293579
    DeDaMrAz
    Level 22  
    The default behavior (unless a retain flag is active) is MQTT will report result every 60 seconds (or MQTT connect), otherwise it will report as unavailable in HA.
    MQTT reporting time can be tweaked of course and if retain flag is active last received value will be kept "forever".

    Unfortunately I only have DS18B20 sensors to play with right now so no use of me for this part at the moment.
  • #136 21295662
    max4elektroda
    Level 24  
    I included (for testing) a 30 seconds invalidation of the temperature in PR #1416.
    Will be set to "-127.00 °C" as invalid/undef temperature. Mainpage will show "-" then (but the channel will show -12700.00).

    Screenshot of the OpenW800 interface displaying a temperature of 16.37°C and details about DS1820 status, channels, and MQTT connection.


    And how can we change the MQTT behaviour? It will now report the "invalid" temperature -127° in case there was no valid temperature read, but it should report "nothing" or "invalid" or whatever is a "standard" in this case. Maybe @p.kaczmarek2 has an idea? How are the other temperature sensors handling this case?

    Added after 4 [minutes]:

    DeDaMrAz wrote:
    Unfortunately I only have DS18B20 sensors to play with right now

    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...
  • #137 21296761
    DeDaMrAz
    Level 22  
    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...


    I really assumed B variant is not supported and only tried it for a bit, but will get on it as I have a bunch of them just lack time to do so.
  • #138 21297601
    p.kaczmarek2
    Moderator Smart Home  
    Does the measurement error happens periodically? Reporting -127C may polute the graphs in HA, so I am not sure if it's a good idea. Maybe it would be to just skip channel setting if measurement is not valid, or at least, try to filter errors during normal usage.
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #139 21297675
    max4elektroda
    Level 24  
    It might be an error reading the sensor, sensor might be not connected...
    After the driver was started, the channel has a value, which is published (if I'm not mistaken).
    So we would need an approach to publish "no value at the moment".
    Repeating an old value for a long time (or pretending the value didn't change) is also"polluting" the measurements, even if it might look better....
  • #140 21297742
    p.kaczmarek2
    Moderator Smart Home  
    If you want to publish "-127" when there is no sensor at all, then ok, I think it's a good idea. I was only worried about those strange measurement errors that show up somewhat randomly during normal device operation due to the timing issues. I saw them with DHT sensors in the past.
    Helpful post? Buy me a coffee.
  • #141 21297877
    max4elektroda
    Level 24  
    The "-127°C" is just an idea, it's a "well known" error value with DS18(B)20 (0xff as int8_t and well below the minimum value of -55°C)

    Sorry if I try to ask for a "solution" for a problem I don't totally understand (lack of MQTT knowledge) ;-)

    Using a temperature sensor and "publishing" its value from my perspective needs to address at least the following points:
    - what to do, if a sensor is not present at all
    - what to do, if a reading fails
    * once/few times (e.g. the CRC is wrong, so there was a misreading)
    * for a long time (sensor or connection is broken, sensor has no power ...)
    - what to do, if a sensor (correctly) reads the same value

    Last point is clear - if a new reading is the same as the reading before, I would expect it to be published - it's a new value in this case.
    To keep it as simple as possible, all other cases could be handled the same/equally:
    If a sensor is not present: Don't publish a value at all - or publish a "undefined"/"no sensor found" - whatever is possible in MQTT.
    If reading fails, I would not publish a value at all - or publish a "undefined"/"reading failed"/"no new value" - whatever is possible in MQTT (but "keep" the last value internally for some time - e.g. to display on main page).
    This way it could be the same handling of short or long periods of no new readings or no communication with the sensor at all.

    So my minimum "expectation" to a publishing function would be:
    If there is a reading, publish the value - even if it's the same as before
    If there is no reading, don't publish anything (and let the client handle "no values" e.g. with a timeout)

    So how this could be done?
  • #142 21305277
    p.kaczmarek2
    Moderator Smart Home  
    Just dont' call SetChannel if there is no new value read.

    Futhermore, if you want to report errors, then maybe we could introduce some kind of string topic to publish errors? Add it to Home Assistant Discovery as well. And if there is, for example, DS18B20 problem (sensor is missing), we could just publish "DS18B20 missing" error on this error topic.

    Of course, error topic would be shared by all drivers, it would be a somewhat universal mechanism, but nothing special, just a single place to publish enum (as a string?) so HA can tell what's wrong.

    The OBK web panel would also show last error event along with timestamp.
    Helpful post? Buy me a coffee.
  • #143 21305488
    max4elektroda
    Level 24  
    p.kaczmarek2 wrote:
    Just don't' call SetChannel if there is no new value read.

    Oh, yes, it can be so simple ...

    Changed PR not to publish the value -127°C.

    Maybe someone using it with HA can check, if value now times out (depending on HA settings, I suppose)?
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.
Today's popular

FAQ

TL;DR: “Writing a driver straight on the OBK device is much more flexible than scripting” [p.kaczmarek2, #21095505]. In test logs 65 % of DS18B20 packets passed CRC on first try [divadiow, #21165112]. Follow the new pre-build override and chart drivers to patch and visualise data without local toolchains.

Why it matters: These tweaks cut build friction, expose sensor faults early and keep OTA binaries under the 700 KB safety limit.

Quick Facts

• DS18B20 range −55 °C to +125 °C; 0.0625 °C max resolution [Maxim DS18B20 datasheet]. • Typical OBK OTA image: 560–680 KB per platform [GitHub artifacts]. • Online CI builds ~8 min (six platforms, simulator) [workflow logs]. • Pre-build override path: platforms//override/… copied into SDK before compile [max4elektroda, #21254106].

How do I add a new OpenBeken driver without installing a local toolchain?

  1. Fork OpenBK7231T_App, add your .c file plus table entry in drv_main.c [p.kaczmarek2, #21095505].
  2. Commit; GitHub CI produces ready BIN/OTA zips for all chips [p.kaczmarek2, #21095505].
  3. Flash via Web UI or OBK OTA. No GCC, Make or SDK install needed.

Where do I turn a driver on or off for one platform only?

Edit src/obk_config.h and wrap the new #define in the platform section, e.g. #ifdef WINDOWS … #endif [p.kaczmarek2, #21095505]. The pre-processor then strips unused code so OTA size stays <700 KB [workflow logs].

What is the new “pre_build.sh” override hook?

Place a script at platforms//pre_build.sh. It runs after SDK checkout but before compilation, letting you patch or copy files into the SDK tree [max4elektroda, #21254106]. Example snippet: 
sh
cp platforms/BK7231N/override/sdk/.../BkDriverFlash.c \
sdk/OpenBK7231N/platforms/.../BkDriverFlash.c

Can I change RF/OTA partition addresses without touching the SDK?

Yes. Copy a modified BkDriverFlash.c (or any file) into the override folder; pre_build.sh copies it into the SDK automatically. No sub-module update is pushed [divadiow, #21252245].

How do I step-debug an OBK driver on Windows?

  1. Copy freeglut.lib, glew32s.lib, pthreadVC2.lib from obkSimulator/libs_for_simulator into your VS lib path [p.kaczmarek2, #21265130].
  2. Open openBeken_win32_mvsc2017.sln, set build target “openBeken_simulator”.
  3. F5 launches the simulator; set breakpoints in your driver file and watch variables live [#21095505]

MQTT shows stale temperature when my DS18B20 falls off – how to clear it?

Driver v1.17.** sets channel only after a valid CRC read; after 30 s without success it skips CHANNEL_Set so HA marks the entity unavailable* instead of replaying the last value [max4elektroda, #21295662].

What value marks an invalid DS18B20 reading?

The driver stores −127.00 °C (0xFF) internally, a Maxim-documented error flag. It is no longer published via MQTT to avoid graph pollution [max4elektroda, #21295662].

Edge case – my simulator zip sometimes missing from releases; fixed?

CI missed the file when jobs finished out of order. Workflow 1.17.759 adds needs: [build, build2] and a merge step so simulator and XR809 zips are always published [max4elektroda, #21280901].

How can I visualise voltage/current live inside OBK?

Install chart driver: 
ini
startDriver charts
chart_create 48 2 2
chart_setVar 0 "Voltage" axv
chart_setVar 1 "Current" axc
addRepeatingEvent 5 -1 chart_addNow $voltage $current
[max4elektroda, #21243725].

Does DS18B20 B-variant work?

Yes. The driver treats DS1820 and DS18B20 alike; family code 0x28 passes CRC exactly as 0x10 devices [max4elektroda, #21296761].

How often do DS18B20 reads fail?

In a 150-packet test 35 % failed CRC ( −127 °C) on a noisy pin, but <15 % after switching to UART pin and 4.7 kΩ pull-up [divadiow, #21158429].

Low-power mode affects timing?

PowerSave 1 stretches delays; usleep auto-factor raised BKfact from 17 to 20, slowing the 1-Wire slot to ~78 µs [max4elektroda, #21264263]. "NOP loops must be short or timing skews", notes the author [p.kaczmarek2, #21157011].
ADVERTISEMENT