I'm experimenting with YAML file-based widgets

[HenMus]

I’m experimenting with YAML file-based widgets (placed in conf/yaml/, with a version: 1 key and a widgets: map, as described in the YAML Configuration docs). I have a few questions about how these behave in Main UI:

1. Lock icon: widgets loaded this way show up in Developer Tools > Widgets with a small lock icon next to them. I assume this indicates they’re read-only / externally managed (i.e. coming from a file, not the managed/GUI store) - can someone confirm this is indeed what the lock means?

2. Removing them: how do I remove a file-based widget that I no longer want? Deleting it from the widget list in the GUI doesn’t seem to work (presumably because it’s read-only/externally managed). Delete the YAML file doesn’t remove it from the GUI within Main UI?

3. Inconsistent visibility: some of my file-based widgets show up fine in the Widgets list, but others - defined the exact same way, in the same conf/yaml/ folder - don’t appear at all, even after a full restart of the openHAB container. The log does show Adding YAML model yaml/<filename>.yaml for all of them at startup, so they do seem to load without errors, they just don’t all show up in the picker. Has anyone run into this, and is there a known cause (e.g. a caching issue, a naming conflict, or something specific to how/when the file was added)?

Any pointers appreciated - trying to understand the intended workflow here, since I’d like to manage a small personal widget library entirely through files (for version control) rather than through the GUI editor.

[jimtng]

@HenMus

1. Lock icon: widgets loaded this way show up in Developer Tools > Widgets with a small lock icon next to them. I assume this indicates they’re read-only / externally managed (i.e. coming from a file, not the managed/GUI store) - can someone confirm this is indeed what the lock means?

yes

@HenMus

2. Removing them: how do I remove a file-based widget that I no longer want? Deleting it from the widget list in the GUI doesn’t seem to work (presumably because it’s read-only/externally managed). Delete the YAML file doesn’t remove it from the GUI within Main UI?

You’d need to delete the file. It should disappear from the UI

@HenMus

3. Inconsistent visibility: some of my file-based widgets show up fine in the Widgets list, but others - defined the exact same way, in the same conf/yaml/ folder - don’t appear at all, even after a full restart of the openHAB container. The log does show Adding YAML model yaml/<filename>.yaml for all of them at startup, so they do seem to load without errors, they just don’t all show up in the picker. Has anyone run into this, and is there a known cause (e.g. a caching issue, a naming conflict, or something specific to how/when the file was added)?

Can you upload them in a zip file for testing?

[HenMus]

yaml_widgets_for_forum.pdf (4.1 KB). Rename to zip

[jimtng]

Timeline:

1. First placed: 4 separate, single-widget files: accu-tegel.yaml,
   auto-tegel.yaml, net-tegel.yaml, zon-tegel.yaml. All 4 showed up fine in
   Developer Tools > Widgets, each with the lock icon.

Confirmed

2. I then deleted all 4 of those files from conf/yaml/, and did a full
   restart of the openHAB container.

As soon as you deleted the 4 files, they will disappear from mainui. No need to restart openhab. But you do need to refresh the widget list page.

3. Replaced them with 2 new files: energiepagina_compleet.yaml (a page) and
   energiewidgets.yaml (a single file containing all 4 widgets combined,
   under one widgets: key, with the same widget UIDs as before:
   zon-tegel, net-tegel, accu-tegel, auto-tegel).

The widgets will re-appear in the widgets list.

Point 2 (removing) - re: “delete the file, it should disappear”:
That did not hold true in my case. After deleting the 4 original files and
restarting, all 4 widgets (accu-tegel, auto-tegel, net-tegel, zon-tegel)
remained visible in Developer Tools > Widgets, still with the lock icon.
Trying to delete them directly from within the GUI also does not work.

Point 3 (inconsistent visibility):
At the same time, the widgets defined in the NEW file (energiewidgets.yaml)

• using the exact same widget UIDs (zon-tegel, net-tegel, accu-tegel,
  auto-tegel) - do NOT show up in the widget picker at all. Same goes for the
  new page file (energiepagina_compleet.yaml) - not visible either. This is
  despite the startup log confirming both files are read without error
  (“Adding YAML model yaml/energiewidgets.yaml” / “…/energiepagina_compleet.yaml”).

So right now: the OLD (deleted) widgets are still shown (ghosts, can’t be
removed), while the NEW (currently present, same UIDs) widgets/page are not
shown at all. I suspect these might be two sides of the same underlying
cache/reload issue - possibly something not properly releasing/refreshing
the old UID registration, which then blocks the new file’s widgets with the
same UID from registering - but that’s just a guess.

I cannot reproduce this behaviour. Everything seems to be as they should to me.

1. I first put these files into conf/yaml:

conf/yaml/accu-tegel.yaml
conf/yaml/auto-tegel.yaml
conf/yaml/net-tegel.yaml
conf/yaml/zon-tegel.yaml

They appear in the Widgets list page

2. Then I deleted those 4 files. The widgets list after hitting refresh, show no widgets

3. Then I placed these 2 files into conf/yaml

conf/yaml/energiepagina_compleet.yaml
conf/yaml/energiewidgets.yaml

They appear in widgets list (again, I had to refresh the page)

5. They also appear in the list of widgets that I can add to a page:
   
   

[jimtng]

@HenMus if you could try refreshing your browser window and then take a screenshot of the page whilst confirming what’s inside conf/yaml that’d be helpful.

Also note that yaml files are also loaded from conf/items, conf/things, conf/tags. Also both *.yaml and *.yml are loaded.

[HenMus]

Thanks. Follow-up on the widget file test:

You were right — I re-tested and see now that a single YAML file containing multiple widgets under one widgets: key does show up correctly, with each widget appearing as a separate entry in the Widgets list (identified by its UID, not by filename). Delete the file and all of them disappear together. So no ghost widgets — that was my misreading of the earlier screenshots. Thanks for the patience.

New finding on pages though:

I ran into something with pages that I can’t fully explain. My energiepagina_compleet.yaml file loads without errors in the log, but the page does not appear in the sidebar. I had originally given it a readable UID:

uid: page_energie_bestand

When I replaced that UID with a GUI-style auto-generated one:

uid: page_1bc8ca20f2

…the page suddenly shows up in the sidebar and renders fine (screenshot attached — the widgets are empty because the referenced items don’t exist in this test, but the layout is there).

Is there a naming convention or specific pattern that page UIDs must follow to be picked up by the sidebar? It looks like only UIDs matching the auto-generated page_ + hex pattern are recognized, but I couldn’t find this documented anywhere. Or is this a bug?

[jimtng]

@HenMus

My energiepagina_compleet.yaml file loads without errors in the log, but the page does not appear in the sidebar.

It does on my system

@HenMus

Is there a naming convention or specific pattern that page UIDs must follow to be picked up by the sidebar?

There are only two criteria, if I’m not mistaken:

1. Having config sidebar: true
2. Having the proper permission (User vs Admin) i.e. the visibleTo config.

Neither the file name nor the UID has any bearing on it appearing on the sidebar.

@HenMus

Or is this a bug

Can you write step by step on how to reproduce it if you think it’s a bug?

At the moment I cannot reproduce the problem.

[HenMus]

Is working. The issue occurred because an f7-card requires internal wrapper structures (such as f7-card-content) to properly display list elements, causing only the outer frame to render when wrapping a separate oh-list.

Switching to oh-list-card resolves this, as it natively combines the card container with list functionality, allowing the list items to render directly.