logo elektroda
logo elektroda
X
logo elektroda
Advanced Search
logo elektroda

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

p.kaczmarek2 7452 142
ADVERTISEMENT
Reply Cool? Ranking DIY | New topic
Notify about new articles
  • #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 20  
    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.
  • #124 21282365
    max4elektroda
    Level 20  
    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 19  
    @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 20  
    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.
  • #127 21282460
    DeDaMrAz
    Level 19  
    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!
  • ADVERTISEMENT
  • #128 21282468
    max4elektroda
    Level 20  
    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 ..
  • ADVERTISEMENT
  • #129 21282491
    DeDaMrAz
    Level 19  
    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 20  
    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 20  
    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 20  
    @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...
  • ADVERTISEMENT
  • #134 21293576
    divadiow
    Level 34  
    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 19  
    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 20  
    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 19  
    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.
  • #139 21297675
    max4elektroda
    Level 20  
    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 20  
    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 20  
    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
Report a violation of the law

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.
Popular Topics
ADVERTISEMENT