Open Reminder [3.3.0;3.4.9)

What language is the called rule written in? If it’s ECMAScript 11, the Item is passes as alertItem and the state the Item was in to generate the call is in currState. These are just injected into your called rule as is.

console.log('Received alert from ' + alertItem + ' in state ' + currState);

If ECMAScript 5.1, it comes over in a variable called context.

logger.info('test', 'Received alert from ' + context.alertItem + ' in state ' + context.currState);

I think the other JSR223 rules languages will also get them in that context variable. I’ve no idea how it works/if it works in Rules DSL. I would guess it works like ECMAScript 11, if it works at all.

You can see my use of these in several examples at How I Use Rule Templates

I ran the script in the rule manually but I still see that error

2022-09-21 10:54:23.629 [INFO ] [openhab.event.RuleStatusInfoEvent   ] - Door_Status updated: RUNNING
==> /var/log/openhab/openhab.log <==
2022-09-21 10:54:23.633 [INFO ] [ation.script.rules_tools.door_status] - Resetting looping timers
==> /var/log/openhab/events.log <==
2022-09-21 10:54:23.633 [INFO ] [openhab.event.RuleStatusInfoEvent   ] - Door_Status updated: IDLE
2022-09-21 10:54:33.449 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'WemoPlug_Switch' received command OFF
2022-09-21 10:54:33.450 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'WemoPlug_Switch' predicted to become OFF
2022-09-21 10:54:33.453 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'WemoPlug_Switch' changed from ON to OFF
2022-09-21 10:54:33.453 [INFO ] [hab.event.GroupItemStateChangedEvent] - Item 'gTutorial' changed from ON to OFF through WemoPlug_Switch
==> /var/log/openhab/openhab.log <==
2022-09-21 10:54:33.455 [DEBUG] [.script.rules_tools.reminderswitches] - Running door alert rule with: 
  item:           WemoPlug_Switch
  state:          OFF
  alertState:     ON
  invert:         true
  defaultTimeout: PT0m
  repeatPeriod:   PT5m
  dndStart:       00:00
  dndEnd:         00:00
  noAlertPeriod:  true
  alertRuleUID:   door_open
2022-09-21 10:54:33.455 [DEBUG] [.script.rules_tools.reminderswitches] - WemoPlug_Switch is in the alert state of OFF
==> /var/log/openhab/events.log <==
2022-09-21 10:54:33.456 [INFO ] [openhab.event.RuleStatusInfoEvent   ] - ReminderSwitches updated: RUNNING
==> /var/log/openhab/openhab.log <==
2022-09-21 10:54:33.456 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'ReminderSwitches' failed: java.lang.IllegalStateException: The Context is already closed.

That error only occurs when a rule tries to reference something from the cache that was created by a rule that no longer exists (e.g. you edited the rule, therefore replacing it with a new rule). All I can recommend is to run it manually again or reboot to see if the problem persists. I can’t reproduce this behavior. Once I run the rule manually and I see that “Resetting looping timers” log statement the context errors go away.

Thanks Rich, rebooting cleared the error.

Hi Rich. Thank you for this ruler template.
I am writing this post just to help in case someone finds the problems that I have had.
The template works fine for me using it with a switch, with a PowerState channel defined as switch.
But at first it didn’t work with my garage door, because the status of my garage is reported on a channel defined as a contact point (not a switch). Looking at the logs, I can see that if I use the group in the template, the value of this.event is always undefined. But if I use the channel, it never triggers because the template defines the trigger as a group. This is how the template defines the triggers in the Code tab of the rule:
triggers:

  • id: “1”
    configuration:
    groupName: GarageDoor_DoorState
    type: core.GroupStateChangeTrigger

I resolved this changing in this section the words ‘group’ to ‘item’:
triggers:

  • id: “1”
    configuration:
    itemName: GarageDoor_DoorState
    type: core.ItemStateChangeTrigger

Yes. I tried really hard to make the trigger type be a property you can define when you instantiate the rule, but it’s simply not currently possible. It only results in syntax errros. So if you want any different type of trigger you’'ll have to modify your instantiated rule after the fact, just as you did.

You would probably want to do the same thing if you are using this to implement a motion sensor timer (e.g. turn off a light five minutes after the last time a motion sensor triggers). I’ve posted an example of this and other ways to use this rule template to How I Use Rule Templates.

tl;dr, do not be afraid to adjust a rule created from a template if that works best for you.

I’m glad you figured that out on your own. If you run into any other problems or suggestions for additions or improvements let me know. This rule template is turning out to be my most useful one so far.

And thanks for posting!

The rule stopped working after I updated to 3.4.0:

Failed to execute script:
org.graalvm.polyglot.PolyglotException: TypeError: undefined has no such function “put”
at .put(/etc/openhab/automation/node_modules/openhab/cache.js:47) ~[?:?]
at .:program(:23) ~[?:?]

First, what version of the js scripting library are you using, the one that comes with the add-on or did you install it using npm?

I do have a minor change in the version of the rules I’m running but I made them to work with OH 4 snapshots. Maybe they also need to be back ported to 3.4, but then this template will no longer support 3.3 if I do that. I’ll need to think about it the best way to solve it.

The problem revolves around changes made to the cache. Previously this was something only provided by the JS Scripting add-on. In 3.4, openhab-core added a universal registry as a replacement so now we should use cache.private and/or cache.shared. But I thought that the old cache was still backwards compatible except with an added deprecation warning in the logs. That appears not to be the case.

While I figure out how to handle this without ending up with three versions of this rule template (one for 3.3, one for 3.4, and one fore 4.0) you can make the following changes to your rules to get it working again.

Replace cache.put with cache.private.put and replace cache.get with cache.private.get` (should be two changes in total and they are right next to each other). In truth, the first one is redundant now. The new privateCache will clear itself out when the script is unloaded automatically but removing that stuff will be a bit more work than necessary to get this working again.

used an old version of this template on openhab 3.3, today uninstalled it to bring it up to date… but now i can not install it from addon marketplace, because it’s not listed?? …what i am doing wrong? …found the .yaml for the template, but how can i install this manually??

I don’t think the 3.3 version of OH understands versioning of Rule Templates so this should be listed no matter what. But even if it did understand the versioning, it should be shown in all versions of OH 3.3.0 and later.

All I can think of is maybe you’ve inadvertantly disabled the marketplace or something.

Unfortunately there really isn’t a way to install a template by hand easily. You’ll have to manually edit the JSONDB to add it which is error prone. You might be better off restoring the rule templates JSONDB file from backups. Hopefully you’ve not made too many changes since uninstalling it and it’ll have a backup with the old template still installed.

no marketplace is not disabled, as i see all other templates and just installed your “thing status reporting” without problems… running openhab 3.4.1

will have a look at the jsondb (/srv/openhab-userdata/jsondb/marketplace_ruletemplates.json ?) and backups in the evening…

I think this issue here is that the rule template is listed for up to version 3.4.0 and not 3.4.1. I have the same issue where I don’t see the Open Reminder template but I do for example see the Thing Status Reporting one which is listed for up to version 3.4.1.

From the marketplace page:

Open Reminder [3.3.0;3.4.0)
Thing Status Reporting [3.2.0;3.4.1]

1 Like

You are right. I wanted to block this from showing up in 4.0. I’ll update it to 3.4.9 which should capture the current and future point releases of 3.4 without including 4.0.-

1 Like

Awesome, thanks for the quick fix! I saw you updated many of the other templates that had the same issue as well. :slight_smile:

1 Like

I updated to 3.4.2 and then executed

  • cd /etc/openhab/automation/js
  • npm install openhab
  • npm install openhab_rules_tools

Now I get a different error:

2023-02-27 11:01:17.972 [WARN ] [nhab.automation.script.ui.b95c424861] - "cache.get" has been deprecated and will be removed in a future release. Use "cache.private.get" or "cache.shared.get" instead. Visit the JavaScript Scripting Automation addon docs for more information about the cache.
2023-02-27 11:01:18.010 [ERROR] [b.automation.script.javascript.stack] - Failed to execute script:
org.graalvm.polyglot.PolyglotException: TypeError: (intermediate value).getItem(...).getMetadataValue is not a function
        at <js>.:program(<eval>:153) ~[?:?]
        at org.graalvm.polyglot.Context.eval(Context.java:399) ~[?:?]
        at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:458) ~[?:?]
        at com.oracle.truffle.js.scriptengine.GraalJSScriptEngine.eval(GraalJSScriptEngine.java:426) ~[?:?]
        at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) ~[java.scripting:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:74) ~[?:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.DelegatingScriptEngineWithInvocableAndAutocloseable.eval(DelegatingScriptEngineWithInvocableAndAutocloseable.java:53) ~[?:?]
        at org.openhab.automation.jsscripting.internal.scriptengine.InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.eval(InvocationInterceptingScriptEngineWithInvocableAndAutoCloseable.java:74) ~[?:?]
        at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.lambda$0(ScriptActionHandler.java:71) ~[?:?]
        at java.util.Optional.ifPresent(Optional.java:183) [?:?]
        at org.openhab.core.automation.module.script.internal.handler.ScriptActionHandler.execute(ScriptActionHandler.java:68) [bundleFile:?]
        at org.openhab.core.automation.internal.RuleEngineImpl.executeActions(RuleEngineImpl.java:1180) [bundleFile:?]
        at org.openhab.core.automation.internal.RuleEngineImpl.runRule(RuleEngineImpl.java:989) [bundleFile:?]
        at org.openhab.core.automation.internal.TriggerHandlerCallbackImpl$TriggerData.run(TriggerHandlerCallbackImpl.java:89) [bundleFile:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
        at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
        at java.lang.Thread.run(Thread.java:829) [?:?]
2023-02-27 11:01:18.024 [ERROR] [internal.handler.ScriptActionHandler] - Script execution of rule with UID 'b95c424861' failed: org.graalvm.polyglot.PolyglotException: TypeError: (intermediate value).getItem(...).getMetadataValue is not a function

You can see the warning with the cache, but that shouldn’t be an issue.

Hmmm. There is a breaking change in openhab-js in version 4.0 but I thought that version wasn’t shipping with the 3.4.2 add-on.

Do you have openhab-js installed separately and if so, is it version 4.0 or 4.1? If so, you might need to uninstall openhab-js from $OH_CONF/automation/js to use the version that comes with the add-on (or use npm to install the 3.2.1 (I think) version of the library).

If you do not have openhab-js installed separately, I’m going to have to rethink some of the versioning.

I’m currently working on a new implementation of this rule template that finally merges it with Threshold Alert but it going to be a bit before it’s tested and ready for prime time. If the 4.0 or 4.1 version of openhab-js is shipping with the add-on, I’ll need to set the maximum version of this one to 3.4.1 and the minimum version of the new one to 3.4.2.

If you just want it to work, replace these two lines:

              const metadata = items.getItem(item).getMetadataValue(timeoutMetadata);
              let timeout = generateAlertTime((metadata) ? metadata : defaultTimeout, dndStart, dndEnd);

with

              const metadata = items.getItem(item).getMetadata()[timeoutMetadata];
              let timeout = generateAlertTime((metadata) ? metadata.value : defaultTimeout, dndStart, dndEnd);

openhab-js 4.1 added a variable containing the version of the library that I can check in my rule templates and generate a meaningful error. But that doesn’t help this rule template.

1 Like

I installed it manually and it’s version 4.1.

I did that and now it’s working. Thanks!

sorry for using this topic, but i have a similar problem with accessing metadata info on an item.
Used like this in < 4.0
items.getItem(gRoom${i}_termostat).getMetadataValue(Type) !== "grzejnik")

and now i get :
Error during evaluation of script ‘/etc/openhab/automation/js/rulesCreator.js’: org.graalvm.polyglot.PolyglotException: TypeError: (intermediate value).getItem(…).getMetadataValue is not a function

should i change it to :
items.getItem(gRoom${i}_termostat`).getMetadata()[Type] !== “grzejnik”)
?

ok got it getMetadata(‘Type’).value solved my issue

This thread should be strictly for discussions about Open Reminder. This thread serves as the documentation and help thread for this rule template and it’s important to keep it on topic.