Skip to content

Enhancements for import/export #948

Open
Open
Enhancements for import/export#948

Description

@tylerpieper
tylerpieper
opened on Jul 3, 2026

Mostly a personal punch list with some ideas I had that I wanted to jot down before I forgot, but if someone wants to take a stab at them, go ahead! Most of these are specifically related to .cfg import export but they could be used for yaml as well I guess.

  • --preview-config or similar - reads a provided config file and prints all the settings configured within. Necessary because you can't just open the binary in notepad like you can the yaml file. Perhaps this should be default behavior - showing the config you are importing before writing the settings to the node (with an option to blindly import if desired, akin to -confirm:$false in powershell.
  • Partial import and export. I imagine arguments like --include-settings and --exclude-settings to choose categories or specific settings to include or exclude from the import or export. For example, --exclude-settings position,mqtt.mqtt_enabled would import everything in the cfg file except all of the position settings, and specifically the MQTT enabled setting (but the rest of MQTT would be imported)
  • direct manipulation of the settings in a cfg file without needing a node attached - allow the creation and editing of config files without needing to use a node as a template. Include support for removing settings from a file to make it a partial file.

Activity

  1. ianmcorvidae commented on Jul 3, 2026

    @ianmcorvidae
    ianmcorvidae
    on Jul 3, 2026
    Contributor
    1. I'd support a general purpose --yes/-y option like tools like apt have. We do have to be careful not to break workflows too much but it might be fine to add this for --configure
    2. Already sort of supported -- missing sections won't be applied, but present-but-default would be I think. YAML is more forgiving here because it has what protobufs would call presence by default, so it's possible to distinguish not-present from default values on all fields. More specificity would require command line arguments though.
    3. I'm kind of unsure the CLI is a good place for this generally, but I think the editable yaml + an argument that will convert yaml to deviceprofile (in the context of a connected node -- YAML import depends on this but device profiles largely don't) might be fine. For full-on editing a purpose built tool seems better, perhaps a simple webapp.

  2. ianmcorvidae commented on Jul 3, 2026

    @ianmcorvidae
    ianmcorvidae
    on Jul 3, 2026
    Contributor

    re: 2, as well, this would be nice to support something similar for channel URL imports, which could help refine the plan

  3. tylerpieper commented on Jul 17, 2026

    @tylerpieper
    tylerpieper
    on Jul 17, 2026
    ContributorAuthor
    1. I'd support a general purpose --yes/-y option like tools like apt have. We do have to be careful not to break workflows too much but it might be fine to add this for --configure

    Should we just skip preview by default for yaml import and preview by default for binary? Would that be a good middle ground?

  4. tylerpieper commented on Jul 17, 2026

    @tylerpieper
    tylerpieper
    on Jul 17, 2026
    ContributorAuthor

    resolved by #960

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions