Help with shared cache in dsl

Setup, Configuration and Use Beginners
1

Hi,

running OH 4.3.9 (still didnt make the leap to 64bit machine)

I’m trying to figure out if I can replace

val smtp = getActions(“mail”,“mail:smtp:myhostname”)

with shared cache entry, because i need this variable in all of my .rules files.

As I understand, to put things in cache i need to run it inside some rule like on startup, as opposed to defining a variable on the top of the rules file.

so i try, something like

sharedCache.put(‘smtp’, ‘getActions(“mail”,“mail:smtp:myhostname”)’)

and then

sharedCache.get(‘smtp’).sendMail(“email@server.net”, “openHAB Test - Test Switch Changed”, "This is a test message! ")

but it doesnt work. can this cache be used in this way in the first place?

what about timers, how would i replace

var Timer timerLights = null from the top of my file?

with sharedCache.put(timerLights’, ‘null’) ? but how it will know its a timer?

2

@vanja unfortunately i cannot help too much with DSL side and while i understand your need my personal preference is to create a standalone item in openhab ui and set the state to the required value and the just read it in to the rule that needs it. This also gives the advantage that you can change very easily the value and also monitor the value via the UI

If this would be a constant updating item then a cached variable may be preferable from a performance standpoint

As an additional OPTION can use the API to populate the item or if you need to do it more often then change the default standalone widget to input card.

ps Happy to here others feedback on my suggestion as well

3

You’re putting a string into the cache

4

No.

The problem is if the Thing goes offline, even if only briefly, and then comes back online that variable will no longer be valid. You need to pull it from the Thing again.

It’s best to pull the actions in the rule(s) that use them just before calling it.

The same logic applies to global variables. You should not store actions in global variables either for the same reasons.

If the timer is only used in one rule, use the privateCache.

You don’t initialize entries to null in the cache. Non-existent keys already return null. But even if it did, the cache doesn’t care if it’s a timer. It just holds any arbitrary object. You need to know it’s a timer when you retrieve the value.

So you just need to put your new timer to the cache when you create it. When you get the timer from the cache, and it’snull you know the timer doesn’t exist. To remove the timer from the cache put null for that key.

val timer = privateCache.get('myTimer')
if(timer === null) {
    // timer doesn't exist
    privateCache.put('myTimer', createTimer(time, [ | 
        // do something
        privateCache.put('myTimer', null) // I think there is also a remove method
    ]))
}
else {
    timer.reschedule(time)
}

This approach is further described in Design Pattern: Separation of Behaviors. It’s a great approach to centralize stuff like notifications so it’s easier to change things (e.g. change from email to Telegram or the like). There’s only one place to make the change.

Performance differences would be unmeasurable.

5

Thanks both, a lot i need to digest and understand.