5.1.0.M2, JS does not store any data

[scuba (Hans-Jürgen König)]

Hello,

I’m currently trying to migrate to version 5.1.0.M2.

I’ve noticed that variables in the rules (JS11) aren’t retaining their values. This works fine in version 5.0.2.

Here’s a simple example:

var daten;

console.log("First Log: " + daten);

daten = 42; 

console.log("Second Log: " + daten);

Log during and after second execution of the rule:

2025-11-12 11:58:38.652 [INFO ] [nhab.automation.script.ui.1a45b24836] - First Log: undefined
2025-11-12 11:58:38.666 [INFO ] [nhab.automation.script.ui.1a45b24836] - Second Log: 42
2025-11-12 11:58:38.997 [INFO ] [nhab.automation.script.ui.1a45b24836] - First Log: undefined
2025-11-12 11:58:39.013 [INFO ] [nhab.automation.script.ui.1a45b24836] - Second Log: 42
2025-11-12 11:58:39.373 [INFO ] [nhab.automation.script.ui.1a45b24836] - First Log: undefined
2025-11-12 11:58:39.382 [INFO ] [nhab.automation.script.ui.1a45b24836] - Second Log: 42

In version 5.0.2, starting with the second call, both log entries output 42..

How can I change this behavior?

[djal (Dusan Jaluvka)]

I noticed this too after upgrade to 5.1.0.M2 and I don’t know, if it is possible to change this behaviour somewhere.

I fixed my rules by using private cache for storing such information between rule executions, which is probably correct solution for this problem.

var daten = cache.private.get("daten");
console.log("First Log: " + daten);

daten = 42; 
cache.private.put("daten", daten);
console.log("Second Log: " + daten);

[scuba (Hans-Jürgen König)]

Thank you so much for your suggestion!

In my case, this would mean a lot of work, so I’ll wait and see. I think/hope it’s just a bug that will be fixed soon; it wasn’t working like this before.

[rlkoshak (Rich Koshak)]

The old behavior was never really supported. So the new behavior is not really a bug. It’s just a side effect of another change and since the impact was never really supported in the first place, it’s not a regression that the behavior changed.

@djal shows the proper supported way to store values between executions of the rule.

But you can go back to the old behavior by navigating to Settings → JS Scripting, click “Show Advanced in the upper right. Now toggle off “Wrap Script Conditions in Self-Executing Function” and " Convert Event from Java to JavaScript type in UI-based scripts”. You’ll need to reload your rules. The easiest way to do that is just restart OH. Or you can disable and re-enable all the rules manually or run the following in a script.

const { ruleRegistry } = require('@runtime/RuleSupport');
utils.javaSetToJsArray(ruleRegistry.getAll()).map(r => r.getUID().toString())
                                             .filter(id => id != ruleUID && rules.isEnabled(id))
                                             .forEach( id => {
                                                console.info('Disabling ' + id);
                                                rules.setEnabled(id, false);
                                                Java.type('java.lang.Thread').sleep(500);
                                                console.info('Enabling ' + id);
                                                rules.setEnabled(id, true);
                                              });

Note that these new features that you’ll be losing include:

• use of const to define variables
• use of let to define variables
• use of return
• a much more robust and JS enabled event Object as opposed to the raw Java event Object which requires extra work to make it usable with JS sometimes. See JavaScript Scripting - Automation | openHAB for details about the event Object and note that the old raw Java event Object is no longer in the docs (used to be the “UI Event Object” section).

In the long run, you’ll want to gradually move to using the cache so you can enable these new features again.

[scuba (Hans-Jürgen König)]

Hello Rich,

Thank you so much for your reply.

I found and disabled the two options. Openhap was restarted, but the behavior remained the same.

Here a screenshot of the settings:

[rlkoshak (Rich Koshak)]

You can try adding the following to the top of each script:

use wrapper=false

If that doesn’t work file an issue. But also be aware that all of this stuff is actively undergoing development and there may be radical changes between milestone releases. We try to limit breaking changes between full releases, but there is no guarantee of that between milestone releases.

[scuba (Hans-Jürgen König)]

Hello,

Setting usewrapper=false doesn’t help with the problem either.

Thank you anyway for your help. I’ll continue with OH5.0.2 for now and then gradually implement djal’s solution.

[agrarina (Veso)]

Guys,

I’m running openhab 5.0.2 after recent migration from openhab 4 and it seems I`m no longer able to store value in variable and reuse it in another execution of a rule. I use Blocky. The following example gives proper result:

2025-11-23 21:38:12.496 [INFO ] [nhab.automation.script.ui.1923e821b6] - 21:38

Then if I run only second line seems that the value is lost:

2025-11-23 21:48:22.677 [INFO ] [nhab.automation.script.ui.1923e821b6] - null

This used to work fine in openhab 4. Not sure if it is the same case that was mentioned above, but advise will be really appreciated! Thanks!

[rlkoshak (Rich Koshak)]

@agrarina

This used to work fine in openhab 4. Not sure if it is the same case that was mentioned above, but advise will be really appreciated! Thanks!

The only way this could work even in OH 4 is if there is another rule that accesses “a1” from the shared cache and that other rule accessed the value before you changed this rule and saved it.

If that didn’t happen when this rule is unloaded and reloaded, any values it stored in the shared cache will be removed because as far as OH is concerned, no other rule is using that value.

[agrarina (Veso)]

Thanks for pointing this out! Indeed, my problem was that I was experimenting with a script without attaching it to rule. Cheers, mate!

[florian-h05 (Florian H.)]

@rlkoshak

But you can go back to the old behavior by navigating to Settings → JS Scripting, click “Show Advanced in the upper right. Now toggle off “Wrap Script Conditions in Self-Executing Function” and " Convert Event from Java to JavaScript type in UI-based scripts”.

The old behaviour is only available for script actions if and only if the use wrapper directive is set to false. The switch in the add-on settings only applies to conditions.

@rlkoshak

See JavaScript Scripting - Automation | openHAB for details about the event Object and note that the old raw Java event Object is no longer in the docs (used to be the “UI Event Object” section).

The old Event object is still in the docs, but it’s collapsed:
Click on „Raw Script Module Event Object“ right above the Scripting Basics section: JavaScript Scripting - Automation | openHAB

[rlkoshak (Rich Koshak)]

@florian-h05

The old behaviour is only available for script actions if and only if the use wrapper directive is set to false. The switch in the add-on settings only applies to conditions.

That’s very confusing.

[florian-h05 (Florian H.)]

@rlkoshak

That’s very confusing.

That is what was decided in the community thread.
And IMO it’s less consfusing to have a single behaviour for script actions (the directive is not documented there) than having two.

[rlkoshak (Rich Koshak)]

@florian-h05

And IMO it’s less consfusing to have a single behaviour for script actions (the directive is not documented there) than having two.

Indeed, it’s less confusing to have a single behavior. But now we have at least three:

• setting on the add-on to turn on/off wrapper for conditions only
• only control of wrapper in actions is a directive, not a setting
• default wrapper is always present for actions and not present for conditions

That’s a lot of context users have to keep up with before they even write a single line of code.

This implementation seems inconsistent. I can’t use what I know to predict how it will work (e.g. I can’t use what I know about the wrapper and how to control it for actions and apply that to conditions). That adds complexity and confusion.

[florian-h05 (Florian H.)]

@rlkoshak

only control of wrapper in actions is a directive, not a setting

That is not documented and shouldn‘t be used, it‘s only a backup plan if there are unexpected issues with the wrapper.

So you officially only have the setting for all conditions (defaults to off), and the directive for single conditions. That‘s also how the docs are written.

For actions, there is NO reason to disable the wrapper and we won‘t tell how to disable.

For actions expect that the wrapper is turned on. For conditions, use the directive to control it. With openHAB 5.2 I am planning to log a warning encouraging users to modify their conditions to use the wrapper.

[rlkoshak (Rich Koshak)]

@florian-h05

That is not documented and shouldn‘t be used, it‘s only a backup plan if there are unexpected issues with the wrapper.

And when people learn of it by looking at the code produced by Blockly there’s no place to learn what it means? I really don’t like deliberately undocumented features.

And it’s not only as a backup plan. It’s the only reason I won’t have to rewrite and maintain two different versions of all of my rule templates, one with the wrapper and one without.

I may have to do that anyway since I can’t predict whether the wrapper is on or off for the conditions and there is no way for me to detect in the code if the wrapper is on or not.

I guess I’m off to rewrite my rule templates. Maybe JS isn’t the best choice anymore for those.

[florian-h05 (Florian H.)]

@rlkoshak

And when people learn of it by looking at the code produced by Blockly there’s no place to learn what it means? I really don’t like deliberately undocumented features.

Blockly adds the directive of return is used, and as the directive is only a special string, that won’t harm.

@rlkoshak

And it’s not only as a backup plan. It’s the only reason I won’t have to rewrite and maintain two different versions of all of my rule templates, one with the wrapper and one without.

Why? Wrapping Script Actions does not change their behavior. Remember we talk about Script Actions here, not Script Conditions.
For Script Actions, everything is properly
documented.

@rlkoshak

I may have to do that anyway since I can’t predict whether the wrapper is on or off for the conditions and there is no way for me to detect in the code if the wrapper is on or not.

For all rule templates targeting openHAB 5.1.x and newer, simply decide decide what you want and add that directive. And if you want only a single template for old and new openHAB versions, just add use wrapper=false. That won’t affect old versions.

I would also like to remind that the chosen approach was discussed on the community and agreed on, and IIRC you also participated in that discussion: Rules and return codes - #60 by florian-h05

[rlkoshak (Rich Koshak)]

@florian-h05

Why? Wrapping Script Actions does not change their behavior. Remember we talk about Script Actions here, not Script Conditions.

But script conditions are different. When the wrapper is enabled I must use return. When it’s not inabled, I must not use return. I can’t write a condition that works both ways.

@florian-h05

just add use wrapper=false. That won’t affect old versions.

But you just said it’s undocumented and shouldn’t be used.

@florian-h05

IIRC you also participated in that discussion: Rules and return codes - #60 by florian-h05

I did and my understanding was that the behaviors works be flipped (conditions would work like actions are now and video versa). that may be in me but that’s what I understood. And there was no discussion about a directive.

[florian-h05 (Florian H.)]

@rlkoshak

But you just said it’s undocumented and shouldn’t be used.

@florian-h05

And IMO it’s less consfusing to have a single behaviour for script actions (the directive is not documented there) than having two.

@florian-h05

For actions, there is NO reason to disable the wrapper and we won‘t tell how to disable.

@florian-h05

For conditions, use the directive to control it.

I have never said it’s undocumented for Script Conditions. It is however undocumented for Script Actions. FYI this is how the docs look like:

(JavaScript Scripting - Automation | openHAB)

@rlkoshak

And there was no discussion about a directive.

@Nadahar

@rlkoshak

but I don’t know how I’ll be able to detect if the wrapper is present.

If the directive is implemented, you won’t have to. Can can dictate it: If you target versions prior to 5.1, turn the wrapper off with the directive, and you know that it’s off. If you only target >= 5.1, turn the wrapper on with the directive, and you know that it’s on.

There was, but you didn’t participate in that part of the discussion.

Before further commenting, please read the
Rules in Main UI section of the docs: https://next.openhab.org/addons/automation/jsscripting/#rules-in-main-ui
Then you’ll see what’s documented and what’s not.

[Nadahar (Nadar)]

@rlkoshak

use wrapper=false

It’s important to note that the directive must be quoted (it’s a string from JavaScript’s POV).

@rlkoshak

I may have to do that anyway since I can’t predict whether the wrapper is on or off for the conditions and there is no way for me to detect in the code if the wrapper is on or not.

No, for rule templates that should work for older versions of OH, you explicitly turn the wrapper off using the directive, and you have predictive behavior.

For Actions, the argument was that there would be no (relevant) difference in behavior, so code written as if there was no wrapper should still behave the same with the wrapper.