Set stateDescription for proxy item from a rule (JS Scripting)

Is it possible to write a State Description to an item from a rule? The item is just a proxy/virtual item that isn’t tied to any channel - it just provides a selection of choices for settings based on the State Description.

At this time, I’m manually updating the state description in the UI for several items, but ideally, I’d like to read the states of other items to compile key/value options in the State Description of some proxy items.

I’m able to read the current state description in a loop:

var itemStateDecription = items.getItem("proxyItem").rawItem.getStateDescription().options[i].label;

However, it’s not clear to me that I can change the state description with any command (like some sort of setLabel(). Is this possible?

There is no built-in command for changing the state description. It is stored in the stateDescription metadata namespace for the item so to modify that requires accessing and modifying that metadata. There are built-in JSScripting helper functions for changing single value in a metadata namespace, but this gets more complicated because the state descriptions you want to change are not stored in the metadata value, but in the configuration object.

At a very minimum, it would probably look something like this:

    var MetadataRegistry = osgi.getService('org.openhab.core.items.MetadataRegistry');
    var Metadata = Java.type("org.openhab.core.items.Metadata");
    var MetadataKey = Java.type('org.openhab.core.items.MetadataKey');
    var descriptionMetadata = MetadataRegistry.get(new MetadataKey('stateDescription','proxyItem'));

    descriptionMetadata.configuration.options = "key1=value1,key1=value2"

    MetadataRegistry.update(new Metadata(new MetadataKey('stateDescription','proxyItem'), descriptionMetadata.value, descriptionMetadata.configuration));

Thank you. I’ll start working through it. Appreciate the tip.

A caution ; as state descriptions are not expected to change dynamically, do not rely on any of the UIs taking any notice of changes without a full refresh.

Noted. I’ll report back if I figure out a clever solution. Much thanks.

We should add a function to support metadata with a config. This comes up enough and I personally would not mind having support for that.

1 Like

I use an inordinate number of metadata configurations, so I’m all for it, but I agree that metadata configuration functions would be a huge boon to a lot of users just starting with using metadata.

I haven’t had a chance to try something out yet, but it may be valuable to understand the use case for future reference. Sorry for the long diatribe, but I’m hoping to show that my “edge” case may be more common than it first appears.

I have an extensive use for audio cues about select events (this is a farm operation being largely automated, but some things require a reminder to do something at certain times that must be done manually - and that requires people to be reminded to do things that change at different times of the year). There is, essentially, multi-room audio going to several different buildings and different rooms within buildings. So TTS is a big player here in this case.

I am leveraging the Squeezebox add-on for notifications on 4 different audio channels that speak over different audio systems at different times for different reasons that change frequently. Some notifications are TTS and others require, what amounts to, a playlist option being played at different times.

The proxy items hold the state description of different LMS lists, updated whenever a new “favorite” is added. When an LMS favorite list is updated, the PlayFavorite item for the player (which holds the LMS server’s key/value pairs) dynamically updates and allows sending commands with no problem.

The trick is, how does one schedule different playlist options at different times (which may vary) when the LMS favorites list may change frequently? My approach was using proxy items: items that do nothing but hold the state description that represents the updated LMS server favorites list. A user uses the state description to choose favorites that will be played using rules - not immediately executed. The trick is to make sure the proxy items updates when the LMS favorites list changes. They just hold state options that can be parsed from a rule and selected as needed.

On a more typical use level, this equates to having a proxy item where the only user choice is selecting a preferred choice (ie, at 2:00 pm, play “MyFavoritePlaylist” on Mondays, but “MyOtherFavoritePlaylist” on Thursdays at 1:00, …). It’s just holding state values, but needs to be dynamically updated whenever the LMS favorites list is updated.

In my case, the LMS favorites list (4 server lists, actually, because there is redundancy and other criteria to be taken into account) is updated several times per week. There are currently 14 proxy items (representing "Play this selection at this time - fixed or astro-based) to hold the state description - each is manually updated. Obviously, scripting this would be preferential.

I can see many uses cases for proxy items holding state descriptions - it allows more advanced user-based UI scheduling without modify rules.

Sorry again for the wordiness. Just hoping that it’s clear and more obvious for many different scenarios than just this one.

1 Like

I’d have to see the rules over all but this feels like there might be a better way to achieve this, perhaps just using Item states and an oh-repeater-card. But either way, there are lots of good uses for being able to edit metadata configuration from rules easily.