getThing('someThing').setLabel('aLabel') does not persist after a restart

[proggprod]

Expected Behavior

When a rule or script runs the command
getThing('someThing').setLabel('aLabel')
The label of the Thing should change as expected, and when openhab restarts the Thing should still have this new label

Current Behavior

When openhab is restarted, the label returns to whatever it was set to previously.

Possible Solution

Steps to Reproduce (for Bugs)

1. Choose any Thing in your list or add one.
2. Note the name (Label)
3. Create a new javascript script or rule and run the command
4. getThing('UIDOfThing').setLabel('newLabel')
5. Notice that the thing's label has changed. As expected.
6. Restart openhab
7. The label of the Thing has reverted to the previous label

Context

Your Environment

• Version used: (e.g., openHAB and add-on versions)
• Environment name and version (e.g. Chrome 111, Java 17, Node.js 18.15, ...):
• Operating System and version (desktop or mobile, Windows 11, Raspbian Bullseye, ...):

[J-N-K]

This is not a bug. Changing things requires updating the thing in the registry, not modifying the thing instance itself.

[proggprod]

If it's not a bug how do I make it persist? What would be the point of it not sticking? The docs don't describe this.

[J-N-K]

You need to get the thing registry and call "update" with the updated thing as parameter.

[proggprod]

Like this???
getThing('UIDOfThing').update
I can't find any mention of any of this in the docs

[clinique]

You're by passing common usage - reaching dev side

[proggprod]

What would be the common usage of renaming a label that doesn't persist?
I'm pretty sure I'm not mad for thinking that renaming something should persist after a restart.

Could you just tell me how to do this?

[rkoshak]

Changing the name of a Thing from a rule is not something that would be common to do from a Rule. The names of Things tend to be static and manually set to something meaningful. There really is no need to change it dynamically from a rule. That's what @clinique means. It's an odd request and smells greatly of an XY Problem.

And the how is outlined above by @J-N-K.

You don't mention which JavaScript you are using which could change the answer some. In both cases things represents the ThingRegistry.

For Nashorn JS see https://www.openhab.org/javadoc/latest/org/openhab/core/thing/thingregistry or the actual code at

openhab-core/bundles/org.openhab.core.thing/src/main/java/org/openhab/core/thing/ThingRegistry.java

Line 35 in be74889

public interface ThingRegistry extends Registry<Thing, ThingUID> {

.

For GraalVM JS Scripting it doesn't look like direct access to the ThingRegistry's update is made available (besides enabling and disabling it's very odd to change anything else about a Thing from a Rule) so you'll either need to import the ThingRegistry which is probably easiest with the line

var {things} = require('@runtime);

Note this will overwrite the helper library things and replace it with the raw Java ThingRegistry, so again look to the links above for how to use it.

[clinique]

Let say it differently: you're diving -at the surface - of OH Core guts. Don't expect this to be fully user documented as it is not the intended audience.

[proggprod]

Thanks for the help.

But I don't understand the resistance I'm sensing from everyone???
The functionality of renaming a Thing label is stated in the main docs in the first few lines about Things. If it's not for rules or scripts then what is it for?

The nature of (and beauty of) software is that people will always find a new yet unintended use for something.
When I bulk import things, I often want to change the default naming for a lot of items at once. So a rule is perfect for this. I don't see what's so strange about this. The reason to do this in a rule is to avoid 100 mouse clicks and typing almost the same thing 20 times.

If not persisting is expected behaviour, it's not mentioned anywhere. And when would not persisting be desirable behaviour?

[rkoshak]

The reason to do this in a rule is to avoid 100 mouse clicks and typing almost the same thing 20 times.

There are other ways to handle that use case including the karaf console, REST API, text based .things files, etc. Rules in general are not really intended to be

The functionality of renaming a Thing label is stated in the main docs in the first few lines about Things.

I suspect that they are there for completeness. You can open an issue on openhab-js to change the implementation of those methods so that the changes get preserved in the registry or remove the methods. I'm surprised to even see they exist in the helper library in the first place. It was probably a case of "while I'm here I may as well be complete" and ultimately it wasn't implemented correctly.

The nature of (and beauty of) software is that people will always find a new yet unintended use for something.

Sure, but that doesn't mean we are obligated to document each and every possible thing that could be done in rules, especially for things that are considered outside the scope of what rules are intended to do. And there isn't a complete lack of documentation. It's there in the javadocs and the code, which is where the intended audience for these methods would find them.

But over all, it's not resistance to what you are doing. It's resistance to the expectation that we would necessarily cover it in the end user docs.

[florian-h05]

You can open an issue on openhab-js to change the implementation of those methods so that the changes get preserved in the registry or remove the methods.

Feel free to open an issue so I have a reminder to fix this once I have the time.

I'm surprised to even see they exist in the helper library in the first place. It was probably a case of "while I'm here I may as well be complete" and ultimately it wasn't implemented correctly.

I added this in openhab/openhab-js#132, and IIRC it was like you described: If I’m here …

[rkoshak]

@florian-h05 openhab/openhab-js#270