I’ve been writing more rules recently, with their complexity growing as my knowledge increases. What bugs me is having to use dummy items just to store the state of something that needs to persist between calls. What (IMHO) would be useful is a binding that implemented a global state object, that could be accessed by all rules. This would / should store any variable type. Any clever people out there willing to take this on?
What’s wrong with persisting the real items ?
And even if you don’t want to do that, what is wrong with using additional virtual items ? It’s essentially the same as persistable global variables, except that it already IS available.
It’s virtual items that I use, but to me it feels like a ‘kludge’. I know what you’re saying about ‘it’s already available’, but I feel that there’s a better way of doing it. It was only a suggestion, just wanted to see if others agreed, or could actually do it 
So if your only argument is “it feels like a kludge.” that’s not a strong point, is it ? And I wouldn’t even agree to that.
Why, any item is a global variable anyway.
It just happens that item object variables are already set with methods to persist and many other things
Just tread a dummy item as a global variable.
You would have to declare it anyway. We do this in a items file that’s the only difference.
1 Like
I’m going to have to agree. You need to provide more detail as to what is wrong with using virtual Items and how creating some central store for global variables fixes that problem.
What feels like a kludge to you, to me is actually pretty elegant. By using Items to store these values I can take advantage of restoreOnStartup to persist the values across OH restarts, I can use Groups to tag and collect them together and aggregate their values and such, I can use them to trigger Rules should the need arise, I can see what they are currently set to on the sitemap should the need arise, and I can modify their values from the sitemap or REST API should the need arise.
Creating a new binding to store global variables won’t be able to do all of this.
There is no need for a feature request, since this functionality already exists by reading/writing the data to a file. This has been discussed a few times in the forum, but give a shout if you have trouble finding it. You can also use JSR223, and have global variables that are accessible by all of your scripts.
But even with these options, I still have plenty of dummy items. 
Thanks all … I see your points, and shall stand down, defeated! @5iver, I’ll look into your suggestion.
1 Like