logo elektroda
logo elektroda
X
logo elektroda

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

p.kaczmarek2 7515 142
ADVERTISEMENT
  • 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 11949 posts with rating 9991, helped 572 times. Been with us since 2014 year.
  • ADVERTISEMENT
  • ADVERTISEMENT
  • #3 21150585
    p.kaczmarek2
    Moderator Smart Home
    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 34  
    eek. OK, thanks. will play
  • #5 21150608
    p.kaczmarek2
    Moderator Smart Home
    This also will have to be ported and compiled:
    https://github.com/PaulStoffregen/OneWire/blob/master/OneWire.cpp
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #7 21151405
    p.kaczmarek2
    Moderator Smart Home
    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.
  • #9 21151486
    p.kaczmarek2
    Moderator Smart Home
    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 34  
    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
    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.
  • #13 21154775
    max4elektroda
    Level 20  
    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
    
  • ADVERTISEMENT
  • #14 21154797
    p.kaczmarek2
    Moderator Smart Home
    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
    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.
  • #16 21154814
    p.kaczmarek2
    Moderator Smart Home
    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 20  
    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
    @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 34  
    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 20  
    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
    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 20  
    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
    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 20  
    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 34  
    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 20  
    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
    Thank you, merged.

    So now incorrect values will not show up on OBK pane?
    Helpful post? Buy me a coffee.
  • #28 21162961
    max4elektroda
    Level 20  
    p.kaczmarek2 wrote:
    So now incorrect values will not show up on OBK pane?

    At least that's the plan ;-)
  • #29 21163106
    divadiow
    Level 34  
    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 20  
    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

Topic summary

The discussion focuses on creating a custom driver for OpenBeken (OBK) devices without the need for a toolchain, utilizing online builds. Users share insights on troubleshooting compilation issues, including missing files and incorrect paths. Key points include the importance of proper file organization, the need for specific libraries like OneWire and DS18B20, and the challenges of ensuring accurate timing for sensor readings. Participants also discuss the differences between DS1820 and DS18B20 sensors, emphasizing the need for precise timing in the OneWire protocol. Solutions involve modifying driver code, implementing a pre-build script for SDK management, and optimizing build processes to reduce overhead. The conversation highlights collaborative efforts to improve driver functionality and streamline the development workflow.
Summary generated by the language model.
ADVERTISEMENT