logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

[OpenBeken] How to get device full name or short name in a script?

Tilator 48 1
ADVERTISEMENT
  • #1 21933381
    Tilator
    Level 12  
    Posts: 138
    Help: 2
    Rate: 13
    @ElektrodaBot How do I get OpenBeken device full name or short name in a script?
  • ADVERTISEMENT
  • No built-in script variable for device names

    #2 21933384
    ElektrodaBot
    AI OpenAI ChatGPT4
    Posts: 8846
    Help: 361
    Rate: 948
    Tilator wrote:
    @ElektrodaBot How do I get OpenBeken device full name or short name in a script?
    Direct answer

    In the normal OpenBeken command script / autoexec.bat script, there is currently no documented built-in script variable such as:

    Code: text
    Log in, to see the code


    So you cannot reliably do:

    Code: text
    Log in, to see the code


    and expect OpenBeken to expand it.

    OpenBeken internally does have both names:

    - Full / long device name: returned in C by
    CFG_GetDeviceName()

    - Short device name: returned in C by
    CFG_GetShortDeviceName()


    The source shows these functions returning
    g_cfg.longDeviceName
    and
    g_cfg.shortDeviceName
    respectively. (github.com)

    What you can do

    1. To set the names

    Use the normal OBK commands:

    Code: text
    Log in, to see the code


    The command list documents
    FriendlyName
    as setting the full name, and
    ShortName
    as setting the short name; the short name is used for MQTT topics. (github.com)

    2. To use the device short name in MQTT publishing

    Usually you do not need to manually read the short name when publishing from the same device. OBK automatically prefixes non-raw MQTT publishes with the device topic/name. The documented
    publish
    command example shows that the final topic is built as:

    Code: text
    Log in, to see the code


    unless you pass raw mode as the third argument. (github.com)

    Example:

    Code: text
    Log in, to see the code


    will publish under this device’s own OBK MQTT prefix.

    If you want to publish to an absolute/raw topic, use:

    Code: text
    Log in, to see the code


    3. In Berry scripting

    Berry can read OBK legacy variables with:

    Code: Text
    Log in, to see the code


    but the current generated constants list does not include a short-name or full-name variable; it lists variables such as
    $CHn
    ,
    $voltage
    ,
    $current
    ,
    $hour
    ,
    $uptime
    , etc. (github.com) The Berry tutorial also shows
    getVar("$voltage")
    ,
    getVar("$current")
    , and
    getVar("$power")
    , but not a device-name variable. (elektroda.com)

    So this will probably not work unless your firmware build has been modified:

    Code: Text
    Log in, to see the code


    Practical workaround

    For now, if you need the name inside a script, define it yourself:

    Legacy OBK script

    Code: text
    Log in, to see the code


    Berry

    Code: Text
    Log in, to see the code


    If you are modifying firmware

    The clean firmware-side solution would be to expose two new script constants, for example:

    Code: text
    Log in, to see the code


    mapped internally to:

    Code: text
    Log in, to see the code


    The relevant C getters already exist in
    new_cfg.c
    , so this is mainly a tokenizer/constants exposure issue, not a missing configuration feature. (github.com)

    Summary

    -
    ShortName ...
    and
    FriendlyName ...
    set the names.
    - OBK internally has
    CFG_GetShortDeviceName()
    and
    CFG_GetDeviceName()
    .
    - The current documented script constants do not expose those names.
    - In normal scripts, use a hardcoded label or rely on
    publish
    auto-prefixing.
    - For a proper dynamic script variable, firmware support would need to be added.
    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