It all depends what you are trying to do.
Fact A - all Items start life with state NULL, unless you do something about it.
Quote from Rich’s linked post -
There are multiple ways you can deal with this problem
For example, an Item might be linked to an Astro output channel. When the binding starts up, it updates that Item with something meaningful. That’s that one sorted then.
For another example, you might use the interactive REST API tool to manually post a new state to your Item. Sorted.
But wait … back to Fact A. If we reboot, we get state NULL again, wahh.
The Item state is not automatically remembered across a reboot, and that is by design.
Okay, let’s add a “remember” feature and call it restore-on-startup. We configure a persistence service to remember our Item state, say every so often, or when it changes. And also enable the persistence service restore-on-startup feature for our Item.
That’s sorted, now we only need update the Item by hand once using REST API and it’ll get remembered.
At least, until an upgrade or database error or something messes up. Then we’d have to manually fix it again.
Seems a bit clonky, can we automate the initial manual update? Of course, make a rule triggered on system started, that examines the Item state. If it finds NULL, update it with your chosen value, sorted.
Still a bit clonky though - you have to hardcode the desired state into rules. How about if we could attach the desired start-up state to the Item in some way? After all we already define labels and icons and stuff when we define the Item.
Let’s use metadata - in OH3 we can use this pretty freely for our own purposes. So for any Item, we could define a default state in metadata. And then our system started rule is changed so that it looks for NULL, and if it finds it, uses the metadata for the state update (instead of something hardcoded in the rule).
Rich’s solution -
https://github.com/rkoshak/openhab-rules-tools/tree/main/item_init
Another important quote from Rich -
If you want to stick to .items files, you will have to look at the code that is generated to figure out how to apply it in your .items files.
But wait - this is going to ‘reset’ the Item at every boot. My Item is, say. a time to turn on heating. The whole idea of using an Item was so that I could alter this from my UI. If I alter it, that gets lost at reboot, wahh.
Go back to “restore-on-startup” above - you can do more than one thing.
Golly, four things to do now, that’s complicated. Restore, startup metadata, startup rule, and my ‘ordinary’ UI widget for when I want to alter it.
How about if we simplify. Make our UI widget deal with NULL state and offer the default values if needed. That’s what this is about -
None of this is within the scope of this thread.