I am trying to setup a “virtual item” that is not connected to a channel/binding. It needs to be a string. Is there anyway to specify a default value/string/text in the items config file?
I tried this and it errors. Type Mismatch expecting RULE_ID
// example
String myItemName “Item Label Name” (grGroup) {""}
I feel like I a missing something simple.
Any thoughts?
No way to specify a default but you can set it to a default using a System started rule. If you use persistence with restoreOnStartup you can delete the rule once the item gets its first value.
Or, for more elegance, write the system-started rule so as to check if the Item has a value yet and if not, then set it to default.
(Allows auto recovery from system rebuilds, persistence glitches etc. - might save some head scratching in the far future)
Thanks for the response. Glad I was not missing something silly.
I will look into the startup rule or possibly rethink what I am trying to do.
That rule could look like this (untested):
rule "Set Default Values"
when
System started
then
Thread::sleep(10 * 1000) // let persistance finish restoring a few seconds
if (Virtual_String.state == NULL) Virtual_String.postUpdate('Default value here')
// repeat 'if' for other items
end
Hi @rtvb, I do not like all those “delays” ;-( As far as I could see, onve this solution is the only one, it points to something not well designed … I’m really missing ability for default values in OH…
openHAB Items are first and foremost variables representing the reality, often by being bound to a Binding channel. If you think about that you’ll realize that a “default/initialization value” is not something meaningful in the design of openHAB. Besides that, technically “NULL” is the fixed initialization value.
Let’s look at an example: A Switch Item bound to a lightbulb can either be ON or OFF. If the system is rebooted and hence can’t know about the state of the bulb, NULL is the only valid value the Item may have.
Now with that out of the way I agree that for “virtual items” the situation is a bit different. You can either restore it from persistence or set it in a rule. Both paths depend on the way the Item is logically related to reality. Once again a fixed initialization value doesn’t make much sense here.
What I’m basically trying to say: While in your very specific case a initialization value may make sense, it would be a design error for 99% of Items.
I do not fully agree that an Item is bound to an exisiting device only.
I use a lot of Items for storing parameter settings and proxy Items
What I have done to solve this problem is:
Agree with @HomeAutomation
I can understand items as variables first fo all. If you declare a variable, you have chance to set the initial value of it in any programing language.
It would not make sence for 99% variables. But ther are variables that needs it / makes code cleaner / easier to maintain.
As items are variables and rules functions operating with them, this is missing option IMHO, combined with fact there is no defined startup order of rules/items/persistence forces you to do this “delays” workarouds for al items that does not represent real world object state, but some internals states, as @HomeAutomation mentioned, maybe I’m missing something?
This whole discussion is going to get philosophical.
We can look at Items in one of two ways (there are more ways than this but let’s choose two to focus the discussion).
In this philosophy, an Item should only ever reflect the real world state of the device or system and if that is unknown the Item should indicate that it is unknown (i.e. be NULL). Rules and sitemaps should be written to behave and reflect that the states of these Items are unknown. And this means setting Items which are just configuration parameters (e.g. target temp for HVAC) is best handled using a System started Rule and/or restoreOnStartup because it makes no sense 99% of the time to set a default to an Item that actually should correspond to something in the “real world.”
I’m pretty sure this is the philosophy ascribed to by the maintainers
In this philosophy, an Item does not necessarily represent anything in particular other than state which is needed by one or more Rules or Sitemaps.
Even though I don’t necessarily code my system this way. I operate under the assumption that it is unlikely that my OH will be down for an extended period of time so I assume the real world state of my Items is unlikely to change while OH was down and therefore I can trust the restoreOnStartup state in my Rules. I don’t have anything automated where if my Rule is wrong it will cause something to happen if my assumption proves false (e.g. my lights may flash).
But I do this fully aware that I can’t necessarily trust the state of my Items. It would certainly be more consistent if I let my Items be NULL and just deal with that as appropriate in my Rules. In some cases this may make it simpler as I wouldn’t have to reschedule Expire binding timers on Sytem startup to set my Items to NULL after a certaion amount of time without an update.
I’m not sure what, if anything this adds to the conversation except to say that “I can understand items as variables first of all” is not necessarily a correct interpretation of the intent of Items.
I wonder if a binding that provided an initial value to an Item would be accepted. I’m thinking of something akin to the Expire binding that all it needs to do is postUpdate the value in quotes to the Item on startup. I’m not sure how that would work for a 2.x verison binding though.
Number TargetTemp { default="20" }
I’ll end with this that I wrote in response to this and other similar posts:
I’ve helped some users come up with some elegant solutions to some problems using approach 3.
Thank you @rlkoshak for long comment - I can deal with null, / undefined in my rules, that’s true. I’d also need to count with option that the rule will be executed in not defined order to persistence restore, so there is second volatility I need to cover… When you want to implement e.g. heater status icon with “manual” option switch (if you switch to “Mannual mode”, you can control the heater manualy) and let this be persistent, the rules for this will grow 2-3times because of that check logic only. I just tried to find way if there is simple way to let OH populate item in order “system default values” -> “persistence restored = last known value” -> “state managed by rules + real world changes”. That order would help me a lot for making rules clean and maintainable. I like the Number TargetTemp { default="20" } example, do we know when this value will be postUpdated to the item please? If before persistence restore and rules engine load, that would be great.
Since it is only a half-baked idea there is no answer to this. It will all depend on whether or if it is possible for the binding to know when OH is restarting/reloading and initializing the Items and whether it is possible to delay the restoreOnStartup somehow. I’m skeptical that would be easy of even possible. If it were, there wouldn’t be the problem with rules running before restoreOnStartup in the first place.
Thank you @rlkoshak, I’ll enhance DSL to allow me this and let OH load item with default value at items-loading time
It isn’t strictly a DSL issue. You will have to modify the ESH core as well.
I know, I’ve enhanced it before for instance for matching regexp item names in rules
@HomeAutomation and @jan.kadlec are you sure that you read and understood my comment? Your answers do not sound like it 
Besides making a strong point for “don’t initialize Items” I still see a place for initial values. @rlkoshak the default binding idea could be something (I’d call it initialize, default is misleading). You could probably quickly derive it from the expire binding and no one is stopping you from adding it to the Eclipse IoT Marketplace. 
I would use it to get rid of my “System started” rules
@ThomDietrich I think I have understood, but I do have more types of items than light bulbs ;-( I can see usefull links from @rlkoshak, workarounds, none did fit to my usecase - if the system boots first time - let items controlling manual switches (and similar items like hysteresis direction values) publish with factory defaults. When system reboots (it’s quite often due to power cuts, electricity maintanance) it should restore to last values, that humans touched - otherwise it’s anoying in long term. If you can advise me how to achieve this behaviour in asynchronous / random order when loading items / rules / persistence please?
I’ve read that you do not use restoreOnStartup at all, how do you solve some switches like “Winter/Summer”, maintanance flags, etc?
Thank you for reply
I’ve read that you do not use restoreOnStartup at all
By now there is actually one instance where I do -for maintaining my apartment-wide heating mode.
All you are asking for can be solved. Maybe a few more examples will help you find your own solution:
All in all my system is fully functioning and real-world-synchronized after around 5 minutes. In that time no wrong actions are executed or wrong states shown in sitemap. If a Binding or device is not working, I’ll become aware oft that through the sitemap error elements.
I hope this clarifies some things! Otherwise please don’t hesitate to ask.
Enjoy!
I don’t know when I’d get a chance to work on it, but it would be an excellent choice for a first binding for someone to code up if anyone wants to run with this before I get a chance to code something up.
I’m not sure how it would work as a 2.x version binding. It seems awkward to have to create a Thing and then link Channels of that Thing to Items. But as a 1.x version binding, it leaves out the growing population of UI only OH users. but if we solved this for an initialValue binding then perhaps the same would work for Expire 2.x.
Reviving this old topic - I also would love to have an “initialize” or “default” binding as described above
Item
String AStringItem { initialize=“xyz” }
Has someone created something like this?