logo elektroda
logo elektroda
X
logo elektroda

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

p.kaczmarek2 11784 142
ADVERTISEMENT
📢 Listen (AI):
  • Screenshot of the obk_config.h file from the OpenBK7231T_App project on GitHub, showing preprocessor definitions.
    Here I will show you how you can create a custom OpenBeken driver. Custom OpenBeken driver can implement almost any logic you want and runs directly on OBK device. You don't need to setup toolchain for that, builds can be done online. Writing a custom OBK driver does not require much programming knowledge, it can be done with the really basic, basic skillset. Writing OBK driver directly is also much more flexible than scripting and gives you a better control over device. Futhermore, I can always help with that, so let's check out how it can be done.

    This short guide was created for users asking how to add custom features to OpenBeken. I hope it will give you a basic overview of the procedure.

    1. Preparing workflow
    Ok, so first go to our repository on Github:
    https://github.com/openshwprojects/OpenBK7231T_App
    OpenBK7231T_App repository page on GitHub.
    Make a fork and open a pull request like you would usually do. It's easiest to do it with Github gui. If you are not sure how, check the Git documentation and tutorials.
    Screenshot showing the Github Desktop interface with the OpenBK7231T_App repository open.
    This will allow you to get online builds in PRs:
    https://github.com/openshwprojects/OpenBK7231T_App/pulls
    Once your PR is accepted, you will be able to get binaries for all platforms as described in:
    OpenBeken online building system - compiling firmware for all platforms (BK7231, BL602, W800, etc)

    2. Preprocessor define for a driver
    All drivers should have a #define in obk_config.h:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/obk_config.h
    This allows us to turn them on and off for each platform.
    Let's create a define for our driver. Let's say that I will be developing it on Windows Simulator for now. So, in the #ifdef WINDOWS section, let's add our own new define:
    Screenshot of the obk_config.h file from the OpenBeken repository on GitHub.
    Our diff so far:
    Screenshot of a code editor showing a change in the obk_config.h file


    3. Main drivers table entry
    Now let's modify drv_main.c:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_main.c
    We need to add an entry to drivers array. Whole entry should be in preprocessor block. We also need to fill the documentation entries.
    Screenshot of a code editor showing modifications in the `drv_main.c` file, where an entry for the new driver `SampleNTPSwitch` has been added.
    A driver has:
    - name
    - init function
    - every second update function
    - quick tick update function
    - http index display function
    - and some other less often used functions, like shutdown function or channel change callback.
    So next we can create those function in separate new file and add their declarations to drv_local.h

    4. New driver file
    So let's create a drv_sample_ntpSwitch.c stub:
    Code: C / C++
    Log in, to see the code

    We can also add some display to know whether our driver really works:
    Code: C / C++
    Log in, to see the code

    Let's build and flash firmware for our chosen platform and try starting the driver:
    
    startDriver SampleNTPSwitch
    

    You should get "OK" reply:
    Command tool panel with startDriver SampleNTPSwitch command and OK message
    You should also get text on main panel:
    A webpage displaying My driver is running! at the top with several buttons at the bottom.

    5. What can be done in drivers?
    Basically everything can be done in drivers, but some more specific operations may require code injection outside your driver file. Still, for the start, let's do something simple. Like the user request we had recently:
    Quote:

    Switch the NTP server IP based on your current network IP

    So, we will do checking every second. Simple string comparison is not time-consuming so it's acceptable:
    Code: C / C++
    Log in, to see the code

    This will set the NTP server IP depending on your current IP. Don't worry about multiple calls to CFG_SetNTPServer. The flash config will be saved only if there is a change in the settings.
    The similiar behaviour was requested by user here:
    https://www.elektroda.com/rtvforum/topic4054813.html


    6. How to debug drivers (on Windows)?
    OpenBeken can run on Windows, along with device simulator.
    So if you run our MSVC projects, you can put breakpoints in drivers:
    Screenshot of Visual Studio with OpenBeken driver source code
    This way you can:
    - see variable values
    - see current call stack
    - pause or resume execution, also manually step in/out the calls
    This can substantially reduce your testing and development time.

    7. How to make drivers scriptable?
    The best way is to use console commands. Console commands can be invoked via autoexec.bat, HTTP interface or even by MQTT. Creating a new command is very simple:
    Code: C / C++
    Log in, to see the code

    This way you cam get a console/script command with a full arguments testing.
    Screenshot of a command entry tool with an error
    Command Tool interface displaying Bad argument error message.
    Screenshot of command tool WinTest_3145CAFF showing the result of the SQRT 16 command.
    Of course, channel value can be also used as an argument.
    Screenshot showing the WinTest command tool with a sample command.
    Command tool interface for WinTest_3145CAFF

    8. How to access channels and measurements?
    Any driver can have full access to OBK API, so you can easily read and write channels, read measurements, etc:
    Code: C / C++
    Log in, to see the code

    The following code will log the channel 1 value and voltage (from BL0942/BL0937/etc sensor).

    This way you can also, for example, measure how long voltage is above given value:
    Code: C / C++
    Log in, to see the code

    If you want, you can change the hardcoded 230 value to something set via console command, just look at the console command sample and save the value to the static global variable.
    Then you can set channels and even publish data via MQTT:
    Code: C / C++
    Log in, to see the code


    9. How to make custom Web page interface?
    Per-driver main HTTP page callback can be used also to get user input. You can easily create HTML forms that way. For this example, I will create a simple button that will just toggle the channel 5:
    Code: C / C++
    Log in, to see the code

    Clicking the button toggles channel 5 value:
    Screenshot of the OpenBeken user interface with a sample driver.
    Custom driver SampleNTPSwitch running on WinTest_3145CAFF

    And that's it! That's how you can create a custom driver in OBK. Remember to download our code to check the full API that is available for your development. All details related to arguments of MQTT/channel/etc calls are in our repository.

    Cool? Ranking DIY
    Helpful post? Buy me a coffee.
    About Author
    p.kaczmarek2
    Moderator Smart Home
    Offline 
    p.kaczmarek2 wrote 14434 posts with rating 12399, helped 650 times. Been with us since 2014 year.
  • ADVERTISEMENT
  • ADVERTISEMENT
  • #3 21150585
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    1. See how drv_ir.cpp includes IRremote:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_ir.cpp
    If not, put OneWire dir into driver dir just to see what happens.
    2. This won't compile in C mode, rename drv_ds18x20c to drv_ds18x20.cpp, and use "extern C" if needed like in drv_ir.cpp
    3. You are still missing OneWire implementation, etc (source file)
    Helpful post? Buy me a coffee.
  • #4 21150596
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    eek. OK, thanks. will play
  • #5 21150608
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    This also will have to be ported and compiled:
    https://github.com/PaulStoffregen/OneWire/blob/master/OneWire.cpp
    Helpful post? Buy me a coffee.
  • #7 21151405
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    That's cool, wanna port it, @divadiow?
    Here are some things to change:
    Code: C / C++
    Log in, to see the code

    And here:
    Code: C / C++
    Log in, to see the code

    Replace with HAL IO functions:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/hal/hal_pins.h
    Also take a look at DHT code:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/src/driver/drv_dht_internal.c
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #8 21151432
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    I do I do. I need to get my head round it. Also, I'm distracted by BK7238 today

    Added after 15 [minutes]:

    insmod wrote:
    DS18B20 library for esp-idf without separate onewire library
    https://github.com/feelfreelinux/ds18b20/blob/master/ds18b20.c

    so am I going with this or the separate libraries I started with?
  • #9 21151486
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    To be honest, I think you can put everything in one file for now. Or just put converted library into ds18b20_internal.c , make header ds18b20_internal.h and include it from drv_ds18b20.c
    Helpful post? Buy me a coffee.
  • #10 21151510
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    hmm. im just making a GPT hash of it right now. feel free to do it or I'll poke around when not tired
  • #11 21154492
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    I have ported @insmod 's recommendation to OBK, but I haven't plugged the "disable interrupts" code yet.
    It is not linked anywhere, but it compiles:
    https://github.com/openshwprojects/OpenBK7231...mmit/8bec03a85cb9e22414be93caff254d3e6a30891c
    Of course, it means nothing, it's just barely the simplest step, but at least, code is here.
    Helpful post? Buy me a coffee.
  • #12 21154572
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    Cool. Nice work. Thanks! 👍
  • #13 21154775
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Since I was working on this some month ago (and didn't get it to work) I also played with this.

    So I am quite a big distance behind this full approach, but also a tiny bit ahead:

    I have a (very very simple) code working (after I finally found out, where my code didn't work):
    It was "usleep()" which didn't work as expected.
    I ended up in adopting the "usleep2" from DHT code for BK7231N, W800 an LN882H.

    https://github.com/MaxineMuster/OpenBK7231T_App/tree/DS1820


    With my "usleepds" I managed to get readings from the three devices I own (BK7231N, W800 an LN882H).
    O.k., I had to do some ugly stuff to get a driver working with W800 (with "#define OBK_DISABLE_ALL_DRIVERS"), too ;-)

    This is how it looks like (define pin in config page and then start driver:

    
    Info:MAIN:Time 234, idle 195090/s, free 64024, MQTT 0(14), bWifi 1, secondsWithNoPing 1, socks 3/38 
    Info:MAIN:Time 235, idle 386760/s, free 75720, MQTT 0(14), bWifi 1, secondsWithNoPing 1, socks 2/38 
    Info:CFG:DS1820 - asked for conversion - Pin 11
    Info:MAIN:Time 236, idle 196018/s, free 75720, MQTT 0(14), bWifi 1, secondsWithNoPing 1, socks 2/38 
    Info:MQTT:mqtt_host empty, not starting mqtt
    Info:CFG:DS1820 - Pin=11 temp=+24.31 
    Info:MAIN:Time 237, idle 192953/s, free 75504, MQTT 0(15), bWifi 1, secondsWithNoPing 1, socks 3/38 
    Info:MAIN:Time 238, idle 191097/s, free 64024, MQTT 0(15), bWifi 1, secondsWithNoPing 1, socks 3/38 
    Info:MAIN:Time 239, idle 207035/s, free 75720, MQTT 0(15), bWifi 1, secondsWithNoPing 1, socks 2/38 
    Info:MAIN:Time 240, idle 194557/s, free 75720, MQTT 0(15), bWifi 1, secondsWithNoPing 1, socks 2/38 
    Info:MAIN:Time 234, idle 195090/s, free 64024, MQTT 0(14), bWifi 1, secondsWithNoPing 1, socks 3/38 
    Info:MAIN:Time 235, idle 386760/s, free 75720, MQTT 0(14), bWifi 1, secondsWithNoPing 1, socks 2/38 
    Info:CFG:DS1820 - asked for conversion - Pin 11
    Info:MAIN:Time 236, idle 196018/s, free 75720, MQTT 0(14), bWifi 1, secondsWithNoPing 1, socks 2/38 
    Info:MQTT:mqtt_host empty, not starting mqtt
    Info:CFG:DS1820 - Pin=11 temp=+24.31 
    Info:MAIN:Time 237, idle 192953/s, free 75504, MQTT 0(15), bWifi 1, secondsWithNoPing 1, socks 3/38 
    Info:MAIN:Time 238, idle 191097/s, free 64024, MQTT 0(15), bWifi 1, secondsWithNoPing 1, socks 3/38 
    Info:MAIN:Time 239, idle 207035/s, free 75720, MQTT 0(15), bWifi 1, secondsWithNoPing 1, socks 2/38 
    Info:MAIN:Time 240, idle 194557/s, free 75720, MQTT 0(15), bWifi 1, secondsWithNoPing 1, socks 2/38
    
  • #14 21154797
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    Great job, can you open a PR? @DeDaMrAz has some sensors to test it

    btw: Is DS1820 the same as DS18B20?

    @ElektrodaBot is DS1820 the same as DS18B20? What are the protocol differences?
    Helpful post? Buy me a coffee.
  • #15 21154798
    ElektrodaBot
    AI OpenAI ChatGPT4
    Posts: 8742
    Help: 351
    Rate: 922
    p.kaczmarek2 wrote:
    is DS1820 the same as DS18B20? What are the protocol differences?
    Direct Answer to the User's Question
    The DS1820 and DS18B20 are not the same, although they share many similarities. Both are digital temperature sensors produced by Dallas Semiconductor (now part of Maxim Integrated) and use the 1-Wire protocol for communication. However, there are significant differences in their features and capabilities.

    Detailed Step-by-Step Problem Analysis

    Basic Similarities
    1. Communication Protocol: Both sensors use the 1-Wire protocol, allowing multiple devices to be connected to a single data line.
    2. Power Supply: Both can operate in a voltage range of 3.0V to 5.5V and can work in parasite power mode.
    3. Temperature Range: Both measure temperatures from -55°C to +125°C.
    4. Unique ROM Code: Each sensor has a unique 64-bit ROM code for individual addressing on the 1-Wire bus.

    Key Differences

    1. Resolution:
    - DS1820: Fixed 9-bit resolution, providing temperature readings in 0.5°C increments.
    - DS18B20: Programmable resolution from 9 to 12 bits, allowing for finer temperature measurements (0.5°C to 0.0625°C increments).

    2. Accuracy:
    - DS1820: ±2°C over the range of -55°C to +125°C.
    - DS18B20: ±0.5°C from -10°C to +85°C, and ±2°C outside this range.

    3. Command Set:
    - DS1820: Uses a simpler command set.
    - DS18B20: Has an extended command set, including commands for alarm functions, copying scratchpad data, and recalling EEPROM data.

    4. Scratchpad Structure:
    - DS1820: 9-byte scratchpad.
    - DS18B20: 9-byte scratchpad with different byte allocations and additional configuration options.

    5. Configuration Register:
    - DS1820: No configuration register.
    - DS18B20: Includes a configuration register for setting resolution and alarm thresholds.

    6. Family Code:
    - DS1820: Family code is 0x10.
    - DS18B20: Family code is 0x28.

    7. CRC Calculation:
    - DS1820: Uses an 8-bit CRC.
    - DS18B20: Uses an 8-bit CRC for the scratchpad and a 16-bit CRC for the entire memory.

    Supporting Details and Explanations

    Protocol Differences
    1. Initialization Sequence: Both sensors use the same initialization sequence (reset pulse followed by presence pulse).
    2. ROM Commands: Both use similar ROM commands (Read ROM, Match ROM, Skip ROM, Search ROM).
    3. Function Commands:
    - DS1820: Simpler set (Convert T, Read Scratchpad, Write Scratchpad).
    - DS18B20: Extended set (Convert T, Write Scratchpad, Read Scratchpad, Copy Scratchpad, Recall E2, Read Power Supply).

    Practical Implications
    - DS18B20: Suitable for applications requiring higher resolution and accuracy, such as industrial control systems and scientific research.
    - DS1820: Suitable for basic temperature monitoring applications where a fixed resolution is sufficient.

    Caveats and Additional Considerations
    - Compatibility: Ensure that your system's firmware and hardware support the specific sensor you choose, especially considering the unique commands and configurations each may require.
    - Interchangeability: The DS18B20's additional features and higher resolution may require specific software and hardware configurations that are not compatible with the DS1820.

    Conclusion
    While the DS1820 and DS18B20 share the same basic functionality and communication protocol, the DS18B20 offers more advanced features, better resolution, and a more extensive command set. When implementing these sensors in a project, consider these differences, especially if you need the higher resolution or additional programmable features offered by the DS18B20.
    You can call me in any topic by writing @ElektrodaBot. Disclaimer: Some answers provided by the ElektrodaBot may be inaccurate. Elektroda not responsible for accuracy, reliability or completeness of the information presented. All ElektrodaBot responses should be verified by the user. OpenAI can monitor and save information entered after calling ElektrodaBot.
  • ADVERTISEMENT
  • #16 21154814
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    Ah ok, so it's different, but since @max4elektroda has proper timings already, maybe I could just move his nops to my ported code...
    Helpful post? Buy me a coffee.
  • #17 21154902
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    I'll do the PR later, just didn't want to much confusion about different code for similar purposes...

    Regarding DS1820 to DS18B20: I just took the shorter name, but I don't think there are many "non B" sensors around today; I only have DS18B20 sensors.
    I'm also not sure, whether I have originals or fake ones, probably the latter...

    Let me state some "todos" and information about the code, just not to forget them...

    We should turn timing variables to defines or hard-code them

    Do some more tests of "usleepds()" on other devices.
    This is easy with my code, I added a "quick and dirty" section to print some information about usleep duration if sensor isn't found. In fact it's just displaying how long in ms a "my" usleep of 50.000 and 100.000 took ( which should obviously return 50/100 ms).
    This allows to adjust the timing.

    I started with LN882H (the only device I owned to that time) but changed to an own usleep implementation since W800 didn't know usleep (at least w/o further includes).

    I was very surprised to see, that e.g. my test showed quite a different timing for W800 than the W600 code in DHT.

    So in general it might need some further testing on other devices if my code works there, too.
  • #18 21155027
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    @DeDaMrAz have a scope and can help, but don't forget that on those ESP32-like platforms timings are not always precise:
    https://github.com/openshwprojects/OpenBK7231T_App/issues/497
    Helpful post? Buy me a coffee.
  • #19 21155776
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    I guess I'm no help with the driver code, but I do have a TYTE-D1 with DS18B20 for when testing is required.
  • #20 21156929
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    I opened a PR (https://github.com/openshwprojects/OpenBK7231T_App/pull/1289) with a code working for me. Beken should work even from the artifacts, for W800 and LN882H additions to makefiles are needed.

    usleep is done like in DHT with different number of "nop" lines.

    I tried to get one step further and to "automate" the usleep calculation on the device with the following general idea:

    Regardless of the device they start with a given number of "nop lines".
    I can test how long the actual "usleepds" sleeps and then derive a correct factor.
    This way there would be no need to do some tests in advance but the device will generate the correct values.

    Here are the code fragments:
    
    static int usleepfact=3;
    void usleepds(int r) //delay function do 10*r nops, because rtos_delay_milliseconds is too much
    {
       for (volatile int i = 0; i < r*usleepfact; i++) {
          __asm__("nop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop\nnop");
       }
    }
    [...]
    // code, if detection of device fails
    [...]
                tempsleep=100000;
                actTick=portTICK_RATE_MS*xTaskGetTickCount();
                usleepds(tempsleep);
                duration = (int)(portTICK_RATE_MS*xTaskGetTickCount()-actTick);
    
                addLogAdv(LOG_ERROR, LOG_FEATURE_CFG, "DS1820 - usleepds(%i) took %i ms ",tempsleep,duration);
       
                if (duration < 95 || duration > 105){
                   // calc a new factor for usleepds                     
                   int temp=  (( 1000 * usleepfact / duration ) + 5 )/10;
                   addLogAdv(LOG_ERROR, LOG_FEATURE_CFG, "usleepds duration divergates - changed  usleepfact from %i to %i ",usleepfact,temp);
                   usleepfact = temp;
                   
                }
    
    


    My Problem: this works fine with W800 and BK7231N, but fails with LN882H:
    Though it states successfully changing the factor (so usleepds(100000) will take 100ms whith the caluculated factor), but the temperatures read from DS1820 are wrong.
    So I wonder if I had a general mistake in my approach?
    Any ideas?

    Thanks!
  • #21 21157011
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    nops are so fast that for loop introduces extra overheat and skews the calculation.

    I will just merge current version.

    However, first I will strip this, we need to think about a better approach in the future, but it's not a top priority:
    Screenshot of a code snippet on GitHub showing a change in a preprocessor condition in the http_fns.c file.

    Added after 15 [minutes]:

    Ok merged:
    https://github.com/openshwprojects/OpenBK7231...mmit/c95eea43736902193dc877fc53a7617cc2f10853
    I skipped the #ifdef and WiFi time change
    Helpful post? Buy me a coffee.
  • #22 21157067
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    Thanks, and sorry I didn't revert the WiFi timings part....
    My W800 will fail first authentication to WiFi more than half of the starts. If you try to test several images in a row, the 60 seconds tend to last longer every time ;-).

    Yes, the W800 part is a dirty hack, since W800 uses "#define OBK_DISABLE_ALL_DRIVERS" and I wanted to test the driver here, too.

    There also is an (commented out) artifact from the "alternate" usleepds() with the automatic approach... (Line 104-140 in the .c file)
  • #23 21157079
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    No problem, if you want to apply fixes, open another PR.

    Just as I said - using many loops for nops sleep is not a good idea when you need really precise timings. The less loops you use, the more precision you get
    Helpful post? Buy me a coffee.
  • #24 21158363
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    First fixes in https://github.com/openshwprojects/OpenBK7231T_App/pull/1290
    Main error: I somehow missed the "," after the driver line :-(.

    Then I addressed the missing leading zero in the fractional part of the temperature in log.
    Last is reducing the nop lines to 5 for BEKEN - maybe @divadiow can check, if this version runs better on his device?
  • #25 21158429
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    will do. im just making a little 3.5mm jack thing so I can test on any platform

    Cable with DS1820 sensor and 3.5 mm jack on a blue mat.

    https://www.elektroda.com/rtvforum/topic4062365.html#21158223

    Added after 34 [minutes]:

    >>21158363

    im afraid it's still jumping about. ~86 degrees is a new fave to jump to

    Code: Text
    Log in, to see the code


    Display of the OpenBK7231N device web interface showing operational parameters, including temperature, voltage, power, and WiFi status.

    Added after 5 [minutes]:

    ive cleared all assignments and only set DS18B20 so no BL0937 driver starts. jumps to 53 sometimes.

    Code: Text
    Log in, to see the code
  • #26 21162859
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    I hope, PR #1295 can help.

    I made another change to timing (using "usleep()" for BEKEN now) and added CRC handling, so bad readings should be ignored.
    I hope it works, for otherwise (if there are CRC errors found), you will get no reading at all.
    Since this will need 9 successfully read bytes (8 Data and the CRC) it's even more challenging than "only" read two bytes correctly.
  • #27 21162923
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14434
    Help: 650
    Rate: 12399
    Thank you, merged.

    So now incorrect values will not show up on OBK pane?
    Helpful post? Buy me a coffee.
  • #28 21162961
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    p.kaczmarek2 wrote:
    So now incorrect values will not show up on OBK pane?

    At least that's the plan ;-)
  • #29 21163106
    divadiow
    Level 38  
    Posts: 4870
    Help: 424
    Rate: 863
    User interface of OpenBK7231N_CB3S_TYTE-D1 displaying temperature information and configuration options.


    Code: Text
    Log in, to see the code
  • #30 21163116
    max4elektroda
    Level 24  
    Posts: 745
    Help: 47
    Rate: 183
    That's not too good.
    Could you please try the output of usleepds with sensor disconnected?
    Maybe my factor won't work on your device...
    Sorry
📢 Listen (AI):

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.

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