[Js Scripting] Why are we deprecated createTimer?

No, this only impacts JS Scripting ECMAScript 11. Unless you’ve been busy Blockly still uses Nashorn ECMAScript 5.1, right?

Yes, it does.

FTR: Refactor ScriptExecution to plain Java ScriptExtension by J-N-K · Pull Request #3155 · openhab/openhab-core · GitHub

6 Likes

I didn’t want to go through installing the library and editing it so I just added the following to the openhab.log file appender in log4j2.xml.

    <!-- Rolling file appender -->
    <RollingFile fileName="${sys:openhab.logdir}/openhab.log" filePattern="${sys:openhab.logdir}/openhab.log.%i.gz" name="LOGFILE">
      <!-- New Element -->
      <RegexFilter regex=".*actions.ScriptExecution.createTimer.*" onMatch="DENY" onMismatch="NEUTRAL"/>
      <!-- End New Element -->
      <PatternLayout pattern="%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-36.36c] - %m%n"/>

The deprecation warning log will still appear in the karaf console. When all this gets resolved, it’ll be easy enough to remove that one line in the logging config.

Posting here in case there are others who need this temporary work around.

NOTE: Yes, I’m aware that I’ve argued against the use of log filters like this in the past but there are differences in those cases and this one, and I’m not advocating here to make it permanent. In short, I still stand but those past positions.

1 Like

FYI: Thanks to the work of @J-N-K at Refactor ScriptExecution to plain Java ScriptExtension by J-N-K · Pull Request #3155 · openhab/openhab-core · GitHub, I am making pretty good progress at implementing solution 1:

I hope to open a PR tomorrow or on Saturday, but note that it requires on core so first the core PR needs to be merged.

The PR again requires some changes on the openhab-js library, but it should be possible to publish those changes before the addon is updated as I need to keep backward compatibility, so you can soon get rid of that deprecation warning without modifying logging settings.

3 Likes

PR is now open: [jsscripting] Reimplement timer creation methods of `ScriptExecution` by florian-h05 · Pull Request #13695 · openhab/openhab-addons · GitHub.

1 Like

Update: We have just published a new version of the openHAB JavaScript library to npm.
The deprecation warning for createTimer has been removed as this API is no longer deprecated, but createTimerWithArgument will stay deprecated.
The new release is backward compatible, but the timers created by createTimer are only thread-safe when the addon PR is merged and you have the latest version of the addon.

4 Likes

That can be “faked” using a function generator. I think we already cover that in the docs so we are probably already good on that front.

1 Like

Yes, that was also part of our argumentation, and this is also the better way as it is pure JS and less confusing then createTimerWithArgument.

1 Like

Good news: The PR https://github.com/openhab/openhab-addons/pull/13695 has been merged, so createTimer is now thread-safe.

@rlkoshak Can you mark this thread as solved?

1 Like

@rlkoshak Can you please move that thread to the Development category?
I am not sure if the normal forum users should read it‘s content as this is thread is more about technological stuff.

Personally, I found this thread very useful because some of my rules use createTimerWithArgument. I probably wouldn’t have seen this thread in the development category. :grin:

1 Like

If you haven’t seen that thread here, you anyway would have learned that createTimerWithArgument is not thread-safe and deprecated, because ever call to it logs a deprecation warning.

FYI: I would like to have this in the development category because some users got a bit confused with ThreadsafeTimers etc.

Done

1 Like

Having looked at my logs for a while I did indeed see the deprecation warning scroll past a couple of times.

1 Like

I use a lot of these timers too, and would probably get stuck not being able to update for a very long time while trying to rework massive amounts of work if I couldn’t use this anymore

This done and sorted. actions.ScriptExecution.createTimer() is still there (but not createTimerWithArgument() it should be noted). A lock was added to prevent two timers from running in the same rule.

Great.

Will this affect the TimerMgr in your rules-tools library?

My openhab_rules_library keeps up with the openhab-js library (with many thanks to @florian-h05 for helping make that happen in a more timely manner than I can manage on my own). We’ve centralized the creation of Timers in all the openhab_rules_library to a central helper function so this, past (e.g. the ability to name Timers for more meaningful error messages) and future changes in how Timers are handled only has to be changed in the one place (for the most part).

I’m also in the process of rewriting my rule templates too to take advantage of changes in openhab-js and to use openhab_rules_tools and changes in core (e.g. cache.private) and my knowledge of OH (e.g. GenericEvent triggers). When OH 4 is released I’ll be ready! :smiley:

3 Likes

Great work :+1: