logo elektroda
logo elektroda
X
logo elektroda

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

p.kaczmarek2 7452 142
ADVERTISEMENT
  • #61 21242823
    p.kaczmarek2
    Moderator Smart Home
    This seems to be in drv_bl_shared.c . I can easily fix this.

    What about this - can we merge your charts changes and Makefile changes first, let's ignore OBK_DISABLE_ALL_DRIVERS and charts on W800/etc for now, and later I will fix OBK_DISABLE_ALL_DRIVERS myself?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #62 21242835
    max4elektroda
    Level 20  
    I think it's a missing "../src/driver/drv_bl_shared.c", where this is defined.
    So I think the correction would be to check for "#if ENABLE_DRIVER_BL09..."?
    There seems to be no "upper" define, so we need to check for "ENABLE_DRIVER_BL0937" or "ENABLE_DRIVER_BL0942"??

    Added after 2 [minutes]:

    You won ;-)

    p.kaczmarek2 wrote:
    can we merge your charts changes and Makefile changes first, let's ignore OBK_DISABLE_ALL_DRIVERS and charts on W800/etc for now, and later I will fix OBK_DISABLE_ALL_DRIVERS myself?


    Good idea, can you include only the first commit of PR 1360 ?

    Added after 6 [minutes]:

    The new PR https://github.com/openshwprojects/OpenBK7231T_App/pull/1363 will add the file to the Makefiles.

    As long as OBK_DISABLE_ALL_DRIVERS is enabled, this will mean e.g. a W800 build will include the driver if it's "defined" in obk_config.h, but you won't be able to start it ...

    Added after 9 [minutes]:

    To have all in one place - the SDK-PRs are

    https://github.com/openshwprojects/OpenW800/pull/10

    https://github.com/openshwprojects/OpenLN882H/pull/18

    https://github.com/openshwprojects/OpenXR809/pull/7

    https://github.com/openshwprojects/OpenW600/pull/11
  • #63 21242873
    p.kaczmarek2
    Moderator Smart Home
    Probably I need to introduce ENABLE_DRIVER_BL0937 and similiar, and then something like ENABLE_DRIVER_BL_XX for shared code....

    I've merged all listed PRs, so now it's time for recursive modules update?
    Helpful post? Buy me a coffee.
  • #64 21242926
    max4elektroda
    Level 20  
    If all was merged, that should be enough so that we could enable charts in obk_config now.
    I just tried to download simulator, but it's not found. Hopefully I didn't break anything there?

    Added after 6 [minutes]:

    Ah, yes, the merges are "only" in the sdks git...
    So the submodules should be updated now..
  • #65 21242945
    p.kaczmarek2
    Moderator Smart Home
    Oh well, it seems you are right that simulator link is dead, but was it ever working? Now when I check it I can clearly see it was not working before in the public releases list? So that may be a separate issue to fix?
    Helpful post? Buy me a coffee.
  • #66 21242966
    max4elektroda
    Level 20  
    I'm not sure, but for release 1.730 I can download the simulator zip file.
    And 731 is the one introducing the new "platforms" folder.
    Does simulator need to "exclude" some files?!?

    Added after 11 [minutes]:

    I think it would be good to add

    https://github.com/openshwprojects/OpenBK7231...mits/493772b5cc058ff4c4584ddfc506455e7bbf7d93

    That's the one moving charts canvas below "state" div and so avoid "flickering" ...
  • #67 21243021
    p.kaczmarek2
    Moderator Smart Home
    max4elektroda wrote:
    I'm not sure, but for release 1.730 I can download the simulator zip file.
    And 731 is the one introducing the new "platforms" folder.
    Does simulator need to "exclude" some files?!?

    I don't think so, but you are indeed right. Maybe it's just a coincidence?
    There is something strange at play because I can see that artifacts zip of 1.17.731 still contains obkSimulator_1.17.731.zip, so why would obkSimulator_1.17.731.zip not appear on public releases? Strange.


    max4elektroda wrote:

    I think it would be good to add

    https://github.com/openshwprojects/OpenBK7231...mits/493772b5cc058ff4c4584ddfc506455e7bbf7d93

    That's the one moving charts canvas below "state" div and so avoid "flickering" ...

    I accepted it but it puts obk_config.h enables in public so you need to disable those defines first...
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #69 21243181
    p.kaczmarek2
    Moderator Smart Home
    Now what's wrong with simulator?
    
    
    [6:23:38 PM] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/git"
    [6:23:39 PM] [semantic-release] › ✔  Created tag 1.17.732
    [6:23:39 PM] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/github"
    [6:23:40 PM] [semantic-release] [@semantic-release/github] › ✘  The asset output/**/obkSimulator* cannot be read, and will be ignored.
    [6:23:41 PM] [semantic-release] [@semantic-release/github] › ℹ  Published file https://github.com/openshwprojects/OpenBK7231T_App/releases/download/untagged-5d706f8097c98cd37f03/OpenLN882H_1.17.732_OTA.bin
    [6:23:42 PM] [semantic-release] [@semantic-release/github] › ℹ  Published file https://github.com/openshwprojects/OpenBK7231T_App/releases/download/untagged-5d706f8097c98cd37f03/OpenW600_1.17.732_gz.img
    [6:23:43 PM] [semantic-release] [@semantic-release/github] › ℹ  Published file https://github.com/openshwprojects/OpenBK7231T_App/releases/download/untagged-
    

    https://github.com/openshwprojects/OpenBK7231T_App/actions/runs/11086028096/job/30803181019
    It's in zip, so why can't it be read:
    Screenshot of an archive program window showing the obkSimulator file.
    Helpful post? Buy me a coffee.
  • #70 21243201
    max4elektroda
    Level 20  
    Did you find the issue or was it solved by magic? Release 733 is whith simulator zip again...
  • #71 21243217
    p.kaczmarek2
    Moderator Smart Home
    No, I didn't change anything. Maybe the version number somehow affects the release, wrong wildcards and sometimes zip is not seen correctly? Filename does not match?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #72 21243238
    max4elektroda
    Level 20  
    Is there a reason for two "*" in path wildcard? But I don't see, why this should be a problem.
    And does "can not be read" mean " not found" or maybe " no access" (ownership...)?

    Added after 1 [hours] 3 [minutes]:

    If I didn't miss something, the sdk updates are still missing to complete the latest changes?
  • #73 21243660
    p.kaczmarek2
    Moderator Smart Home
    Probably two wildcards means that it's a recursive wildcard, so it matches all directories, but I am not sure. I am not the original creator of this releases code snippet.

    It would be very strange if it were an ownership issue, because why then it would first work, then fail, and then again work?

    I didn't do SDK updates, but I can do them for you now if you want:
    https://github.com/openshwprojects/OpenBK7231...mmit/945c5211ddabe00b1f965f853b25222b27a1def7
    Helpful post? Buy me a coffee.
  • #74 21243725
    max4elektroda
    Level 20  
    Thank, great. Just trying with a charts build for W800 and LN882H

    Added after 56 [minutes]:

    ok for LN882H, forgot the discussion about W800 and "ENABLE_DRIVER_BL0937" - next try fixing the for OBK_DISABLE_ALL_DRIVERS

    Added after 32 [minutes]:

    Found quite some points where the presence of BL09XX was instead "overwritten" by only looking for "OBK_DISABLE_ALL_DRIVERS".
    Hopefully I'm finished soon ...
    ATM I'm just using "#ifdef ENABLE_DRIVER_BL0937" instead ...

    Added after 22 [minutes]:

    ... hoping for 10th commit now ...

    Added after 29 [minutes]:

    Yes, finally I did it: W800 is showing charts and I removed "#define OBK_DISABLE_ALL_DRIVERS 1".

    So PR#1368 might be a starting point to fix the "misuse" ;-) of "OBK_DISABLE_ALL_DRIVERS" instead of checking for energy drivers.

    It's not tested with other devices and only tested with BL0937 on one LN882H (and it will definitively fail if only BL0942 is used, for I'm only testing for BL0937).
    But it's a start ...

    Added after 23 [minutes]:

    LN882H with running BL0937 printing the values to charts
    The screen shows data on voltage and current with a graph for a device connected to a BL0937 driver.

    backlog startDriver charts; startDriver NTP; waitFor NTPState 1; chart_create 48 2 2; chart_setVar 0 "Voltage" "axv"; chart_setVar 1 "Current" "axc"; chart_setAxis 0 "axv" 0 "Voltage (V)"; chart_setAxis 1 "axc" 1 "Current (A)"; addRepeatingEvent 5 -1 chart_addNow $voltage $current


    Added after 2 [minutes]:

    @p.kaczmarek2 could you please also check W600 SDK? Seems this one is still missing an update.
  • #75 21243933
    p.kaczmarek2
    Moderator Smart Home
    W600 updates.
    https://github.com/openshwprojects/OpenBK7231...mmit/56233df0aa9c6c0121a3deebbc4e5a499cead9cc
    What's next to merge?
    Is this "sort pins by name" double-checked? Some pin roles requires like two channel fields so I hope this change respects that...
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1361
    Helpful post? Buy me a coffee.
  • #76 21243961
    max4elektroda
    Level 20  
    p.kaczmarek2 wrote:
    Some pin roles requires like two channel fields so I hope this change respects that

    Yes, that should work exactly as before:
    Therefore the sorted driver selection is still using the original values which are set by the enum in C code. The number of channels is linked to the original list.
    BTW: There is one entry I was wondering about: BL0937SEL_n is actually showing 1 channel, while BL0937SEL is configured with 0 channels.

    And we could even fix and shorten the text on the page:
    
    Only for button roles another field will be provided to enter channel to toggle when doing double click. It shows up when you change role to button and save.

    The last part ("It shows up when you change role to button and save.") is not true any more, number of needed channels now is changing together with the selected role:


    Configuration form assigning roles to pins with dropdown lists and channel fields.
  • #77 21244009
    p.kaczmarek2
    Moderator Smart Home
    SEL roles should not have any channels, please do fix it if you can.
    Merged sort change:
    https://github.com/openshwprojects/OpenBK7231...mmit/2c7cfd5909e0a75f72531e67d9f3c51508d42946
    Thank you!

    So, what's next, charts? Just make sure to remove #define from obk_config.h .

    I can add a ring buffer self test myself later if needed.
    Helpful post? Buy me a coffee.
  • #78 21244054
    max4elektroda
    Level 20  
    Charts should be possible now for every platform with defining it in obk_config (with the known issues on W800 with DISABLE_ALL_DRIVERS defined.
    Ring buffer is in testing.
    So if you maybe could take a look at PR1368 for some ideas to fix the DISABLE_ALL_DRIVERS issue that would be great.
  • #79 21244134
    p.kaczmarek2
    Moderator Smart Home
    For me, the changes listed here:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1368/files
    seems acceptable. I can merge it if it's ready.

    I can later dedicate some time to testing various combinations (e.g. check if it really compiles on Beken with BL0937 disabled, etc) but that's not a priority.
    Helpful post? Buy me a coffee.
  • #80 21244196
    max4elektroda
    Level 20  
    It will break a config with BL0942 only, but for the actual obk_config.h, BL0942 and BL0937 are always set as "twins", so no problem expected here.

    First commit changed config to include charts for W800 and LN882H, I just removed this from PR.
  • #81 21244206
    p.kaczmarek2
    Moderator Smart Home
    I think I may have see one more issue with that:
    https://github.com/openshwprojects/OpenBK7231T_App/pull/1368
    Do you have ENABLE_DRIVER_BL0937 anywhere?
    For me, it looks like it would disable BL0937 globally if I were to merge it now.
    Helpful post? Buy me a coffee.
  • #82 21244215
    max4elektroda
    Level 20  
    No, I didn't set them, but these defines are set in obk_config.h for various platforms using energy metering.
    The only change to obk_config.h left is commenting out "#define OBK_DISABLE_ALL_DRIVERS 1" for W800.
  • #83 21244223
    p.kaczmarek2
    Moderator Smart Home
    Hmm ok, merged, so what is the next step?
    Helpful post? Buy me a coffee.
  • ADVERTISEMENT
  • #84 21244255
    max4elektroda
    Level 20  
    I'll try W800 with charts tomorrow to check if it's working as expected.
    For today I'm done...
  • #85 21244589
    max4elektroda
    Level 20  
    The change worked as expected for W800:
    Drivers are usable now, DS1820 and charts are working.

    Screenshot of temperature and humidity charts for OpenW800.

    The change didn't break BL0937, at least for my LN882H smart plug.

    Added after 9 [hours] 15 [minutes]:

    When waiting for the checks to run on an "online build" I remembered a point seen on local docker builds and maybe there is someone who can decide whether my idea is stupid, impossible or maybe can be implemented:

    Every single build will allways download/install the sdks for all platforms and then clear all sdks during a make.

    My idea/question is: can a build for a specific platform only install the single sdk needed for this platforms?
  • #86 21245312
    DeDaMrAz
    Level 19  
    @max4elektroda

    There is an option to streamline the build process with what you suggested and also to possibly cache some of the files to speed up the build process as well. But it will entail a lot of changes so that is on a todo list for now. There are also some build actions that are being deprecated soon so I am working on that first and will look into the other stuff soon or "soon" as I am in severe time deficit.
  • #87 21250985
    divadiow
    Level 34  
    So that the submodule doesn't need updating, could the values for the ota/rf/net start and length be moved into OpenBK7231T_App so a quick easy patch PR in the browser is an option to get a build going with different values?

    https://github.com/openshwprojects/OpenBK7231...beken378/func/user_driver/BkDriverFlash.c#L62
    to couple with https://github.com/openshwprojects/OpenBK7231...af86faed4191cb1f61d75ca24bb/src/ota/ota.h#L10

    extending that, move the coeff key into the main app too so a different key can be tried without submodule changes https://github.com/openshwprojects/OpenBK7231...777/platforms/bk7231n/bk7231n_os/build.sh#L76
  • #88 21251662
    max4elektroda
    Level 20  
    You could "move" the files to the new folder "platforms" and change SDK to include it or make a link for the file.

    Or, if you want "ota.h" be the "leading" file, you could change (for the last time ;-)) the file in SDK to use the "#defined" values from app:

    include "ota.h" and change the line with to the start address to

    ".partition_start_addr = START_ADR_OF_BK_PARTITION_OTA,"

    diff --git a/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c b/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c
    index c7bdbb6..edbb42c 100755
    --- a/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c
    +++ b/platforms/bk7231n/bk7231n_os/beken378/func/user_driver/BkDriverFlash.c
    @@ -33,9 +33,17 @@
     #include "rtos_error.h"
     #include "uart_pub.h"
     #include "mem_pub.h"
    +#include "../../../apps/OpenBK7231N/src/ota/ota.h"
     
     static beken_mutex_t hal_flash_mutex;
     
    +// Just to test if its working
    +// make a string from value
    +#define XSTR(x) STR(x)
    +#define STR(x) #x
    +// print stringified value
    +#pragma message "DEBUG: The value of START_ADR_OF_BK_PARTITION_OTA: " XSTR(START_ADR_OF_BK_PARTITION_OTA)
    +
     /* Logic partition on flash devices */
     const bk_logic_partition_t bk7231_partitions[BK_PARTITION_MAX] =
     {
    @@ -59,7 +67,9 @@ const bk_logic_partition_t bk7231_partitions[BK_PARTITION_MAX] =
         {
             .partition_owner           = BK_FLASH_EMBEDDED,
             .partition_description     = "ota",
    -        .partition_start_addr      = 0x12A000,
    +//        .partition_start_addr      = 0x12A000,
    +// use value defined in /src/ota/ota.h
    +        .partition_start_addr      = START_ADR_OF_BK_PARTITION_OTA,
             .partition_length          = 0xA6000, //664KB
             .partition_options         = PAR_OPT_READ_EN | PAR_OPT_WRITE_DIS,
         },
    
    


    Same for other values ...


    It works for OTA:
    beken378/func/user_driver/BkDriverFlash.c:46:9: note: #pragma message: DEBUG: The value of START_ADR_OF_BK_PARTITION_OTA: 0x12A000
     #pragma message "DEBUG: The value of START_ADR_OF_BK_PARTITION_OTA: " XSTR(START_ADR_OF_BK_PARTITION_OTA)


    For the second wish, you need to give input to the build scripts and "forward" it to the chain, or change the build.sh to "import" a file with the values you want.

    OpenBK7231N/platforms/bk7231n/bk7231n_os/build.sh 
    is called from
    OpenBK7231N/build_app.sh
    which is called by
    OpenBK7231N/bXXX.sh  (b_full.sh, b_rebuild.sh ...)

    I stopped here ...

    Added after 2 [hours] 18 [minutes]:

    ... or you can put a file "key.txt" in /platforms/BK7231N/key.txt and alter build.sh to read it (if that's what you wanted).

    diff --git a/platforms/bk7231n/bk7231n_os/build.sh b/platforms/bk7231n/bk7231n_os/build.sh
    index c663759..a365225 100755
    --- a/platforms/bk7231n/bk7231n_os/build.sh
    +++ b/platforms/bk7231n/bk7231n_os/build.sh
    @@ -73,7 +73,15 @@ if [ "$BUILD_MODE" = "zerokeys" ]; then
            python mpytools.py bk7231n_bootloader_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
     else
            echo "Using usual Tuya path"
    -       ./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin 510fb093 a3cbeadc 5993a17e c7adeb03 10000
    +       if [ -e ../../../../../apps/OpenBK7231N/platforms/BK7231N/key.txt ]; then 
    +               key=`cat ../../../../../apps/OpenBK7231N/platforms/BK7231N/key.txt | sed -n "/[0-9a-f]\{8\} [0-9a-f]\{8\} [0-9a-f]\{8\} [0-9a-f]\{8\} [0-9]\{5\}/ p"` 
    +               if [ "x$key" = "x" ];  then 
    +                       echo "key read, but in uexpected format - using \"510fb093 a3cbeadc 5993a17e c7adeb03 10000\""
    +                       key="510fb093 a3cbeadc 5993a17e c7adeb03 10000"
    +               fi
    +       fi
    +       echo "DEBUG key= #$key#"
    +       ./${ENCRYPT} ${APP_BIN_NAME}_${APP_VERSION}.bin $key
            python mpytools.py bk7231n_bootloader_enc.bin ${APP_BIN_NAME}_${APP_VERSION}_enc.bin
     fi
  • #89 21252147
    divadiow
    Level 34  
    🤯 thank you for taking time to reply! I'm away for a week now but will endeavour to understand what you've posted and to try stuff soon.
  • #90 21252219
    max4elektroda
    Level 20  
    No problem.
    I must admit I maybe didn't totally understand the question, never having to do changes there.
    If you could explain it a bit more, I can find a more intuitive solution.

    The main point will probably be the same:

    Put the information/values to a place in app repository and change the code in SDK to get the information from this source.

    For the first part e.g. I didn't know, if you meant what I tried to code:

    In ota.h is the define line with START_ADR_OF_BK_PARTITION_OTA
    and I understand you may need to change the value, which needs to be changed in the SDK file BkDriverFlash.c, too?
    So I made BkDriverFlash.c to import the header file ota.h and then used the definition from there instead of the value here.
    So if you change ota.h at anytime, BkDriverFlash.c will use the changed value w/o any change inside the SDK.

    For the key it's a bit more tricky, for the scripts in question are called daisy chained, and you would need to change all scripts if you e.g. want to extend the arguments (though in this case you might also add another function to the BUILD_MODE argument).
    I tried another way: if you put a key in the file key.txt in the platforms folder of your device, the build script checks if it's present ( "-e" means if a file exists) and in this case read the content to a variable if it matches the format of a key as I understood it (4 times 8 hex [0- f] and then 5 numbers).
    If key is "valid", it's used, if not, it defaults to the value in the script now.

    Enjoy your trip!

    Added after 10 [minutes]:

    Maybe you have an example in a PR to the SDK were I can see the changes you needed?

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