Item details: Display persistence status

[mherwege]

This PR adds a section on persistence in item detail screen. It will:

1. Show the different persistence services and indicate if the current item is configured to be persisted and the strategies used.
2. Provides a link to the specific service configuration if editable.
3. Show a general link to persistence service configurations.
4. Shows a badge indicating if the item is actually in the persistence store (with a count of persisted values). This badge will only show if the persistence service has implemented the getItemInfo() method, and not just returns an empty list. This is a contraint of the persistence service implementations, to be revisited in the the persistence addons.

Here is a screenshot:

[relativeci]

#4819 Bundle Size — 12.86MiB (+0.02%).

55145cb(current) vs b43437e main#4818(baseline)

Warning

Bundle contains 2 duplicate packages – View duplicate packages

Bundle metrics   3 changes 1 regression

	Current #4819	Baseline #4818
Initial JS	3.23MiB(~+0.01%)	3.23MiB
Initial CSS	0B	0B
Cache Invalidation	7.09%	7.08%
Chunks	592	592
Assets	669	669
Modules	2603(+0.08%)	2601
Duplicate Modules	0	0
Duplicate Code	0%	0%
Packages	123	123
Duplicate Packages	1	1

Bundle size by type   2 changes 2 regressions

	Current #4819	Baseline #4818
JS	11.14MiB (+0.03%)	11.14MiB
CSS	895.64KiB (~+0.01%)	895.58KiB
Fonts	526.1KiB	526.1KiB
Media	295.6KiB	295.6KiB
IMG	45.73KiB	45.73KiB
Other	847B	847B

Bundle analysis report Branch mherwege:item_persistence_status Project dashboard

---

^{Generated by RelativeCI Documentation Report issue}

[Copilot]

Pull request overview

This PR adds a persistence status section to the item detail screen, showing which persistence services are configured for an item, the strategies being used, and whether the item is actually persisted with a count of stored values.

Changes:

• Added a new Persistence section to the item details page showing persistence service configurations
• Created a new component to display persistence service details including configuration status, strategies, and persisted item counts
• Integrated the component with links to persistence service configurations

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 7 comments.

File	Description
bundles/org.openhab.ui/web/src/pages/settings/items/item-details.vue	Adds the persistence section to the item details page with conditional rendering for non-Group items or Groups with a groupType
bundles/org.openhab.ui/web/src/components/persistence/item-persistence-details.vue	New component that fetches and displays persistence service information, including matching strategies and persisted status with badges

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[florian-h05]

During testing, I discovered that persistence services such as InMemory return an array of null if they aren't able to provide information about the persisted items. Will openhab/openhab-core#5336 fix that?
I had to add filtering for this in this PR, otherwise the UI would fail due to a null access.

[florian-h05]

LGTM, thanks!
A very useful addition!

I've refactored it to the TypeScript Composition API and added a minor fix (see my previous comment). I'll wait with testing so you can have a look at my changes.

[mherwege]

During testing, I discovered that persistence services such as InMemory return an array of null if they aren't able to provide information about the persisted items. Will openhab/openhab-core#5336 fix that? I had to add filtering for this in this PR, otherwise the UI would fail due to a null access.

I am surprised by this. InMemory does return information about the persisted items and does return an empty set if there are no items peristed. From the InMemory addon code, I don't see how it returns a null value in that set:

    public Set<PersistenceItemInfo> getItemInfo() {
        return persistMap.entrySet().stream().map(this::toItemInfo).collect(Collectors.toSet());
    }

[mherwege]

With openhab/openhab-core#5336 and openhab/openhab-addons#20200 there would indeed be much better information available for this.
It will:

• clearly distinguish between nothing persisted and not implemented.
• allow calling the API for a single item, so you do not have to query all every time.

This would change the API as it would return a 404 (not found) if nothing was found, and a 405 (not allowed) if the method was not implemented for the service, making a clear distinction. So this code would have to be updated accordingly as well.
The single item query would actually always return something if the item has been persisted because there is a default implementation that just queries the last persisted state. So for a single item request, a 405 would not happen.

The core and addon PR's where a consequence of what I tried to achieve here, which I found limiting. This should work without these other PR's. But if the other PR's are accepted and merged, this should be revisited to see if adjustments are needed to improve it.

[florian-h05]

I am surprised by this. InMemory does return information about the persisted items and does return an empty set if there are no items peristed. From the InMemory addon code, I don't see how it returns a null value in that set:

I neither, but it definitely does for me. I'll debug this further.

[florian-h05]

Ready for merging?

[mherwege]

Ready for merging?

Not quite. I think your refactoring still changes the logic. The end result will be the same, but only because the new REST API hasn't been fully implemented yet (and this code adapted to that). I prefer keeping the difference between null and {} so the changes will be easier afterwards. Minimal changes would all be covered in the TODO.

[florian-h05]

openhab/openhab-core#5387 fixes the issue with InMemory persistence and potentially also other services.

[mherwege]

openhab/openhab-core#5387 fixes the issue with InMemory persistence and potentially also other services.

Great. Note I already had a very similar fix for this included in openhab/openhab-core#5336.

[florian-h05]

@mherwege Please have a look at my latest changes, these should fully restore the previous logic.

[mherwege]

@florian-h05 What is your view on this? Do we wait for the core and addons PR's to be merged to finalize this? The remaining remarks for me all have to do with the changes as done in the core PR, that will make this more consistent and give better information.
I think the addon PR should also be reviewed and merged at the same time as that one will make sure the UnsupportedOperationException is thrown, instead of still returning an empty list for getItemInfo when not supported. That's ultimately what will make the difference.

In our code base, there is one more call to getItemInfo:

openhab-webui/bundles/org.openhab.ui.cometvisu/src/main/java/org/openhab/ui/cometvisu/internal/backend/rest/DataProviderResource.java

Line 207 in 95d5395

for (final PersistenceItemInfo info : service.getItemInfo()) {

This can never have worked, as RRD4J never implemented this and always returned an empty Set. But I don't know if it will still compile whitout adjusting it for the exception that can be thrown.

[florian-h05]

Do we wait for the core and addons PR's to be merged to finalize this?

Let's wait a few days and hope the core PR gets merged soon.

[florian-h05]

This can never have worked, as RRD4J never implemented this and always returned an empty Set. But I don't know if it will still compile whitout adjusting it for the exception that can be thro

We'll see. If compilation breaks, either you or me can fix it quickly ;-)

[florian-h05]

Your core PR has been merged. Do you want to adjust this PR or should I do it (though I‘ll be away from keyboard for a few days)?

[mherwege]

I can adjust it, but it may take me a few days as well. It is a bit busy at the moment.

[florian-h05]

@mherwege Good news! I had some spare time to finish this PR here. FYI, I had to rebase to get the API client changes in from the main branch. Please have a look at my changes from 55145cb and confirm they are fine, so I can merge after you had a look.

[mherwege]

@florian-h05 I didn't do further testing, but the code looks good to me. Thanks.