Time Based State Machine [4.0.0.0;5.9.9.9]

thanks for your very quick reply!

I feel a bit stupid because I just noticed that this exact issue was in the second post of this thread :man_facepalming:

If you by ā€œhelper libraryā€ mean Openhab rules tool then I’m pretty sure I installed it manually, seems like I was running version 2.02 and now I’ve updated to 2.03, but without any luck.

However, then I found that I was running version 0.2 of the template so created a new rule on 0.5 and now it works. Thanks for your help Rich!

No, there are two libraries involved: openhab_rules_tools, and openhab. I’ve referring to the latter. This either comes with the add-on or can be installed separately. If installed separately it’s up to you to keep it up to date.

Unfortunately there is no automated mechanism to update a rule template. That’s why I started adding a comment with the version in a comment to the top of the Script Action of all my rules. I haven’t found any place to add it more prominently that doesn’t cause other problems.

The rule templates now also test the versions of the helper library and OHRT to ensure the minimum versions are met and throws an error if they are not.

There is a lot to track and I try to make it as easy as I can.

After updating to 4.2 M2 the rule fails on my system with a type error while checking the types of the input items (DateTimeItem in line 59 and StringItem in line 119).
When I change the code to check against DateTime and String it seems to work.
Has something changed regarding the type-naming in M2 (issue for the M2-discussion?) or is just an update for the rule-template necessary?

I’ve been on 4.2 M2 for a few days now and I’ve not experienced the same problem.

Can you log out what items[itemName].type (line 59) and items[SATE_ITEM].type is in your rule (obviously prior to the if statements)?

Both are still as expected in mine. There was not mention of any changes to the types in the release notes for M2 and I doubt they would have changed as that would be a pretty big breaking change.

Also, just in case, show the definition of the relevant Items (just one of the DateTime Items is fine, I don’t need all of them, click on the edit page and post the contents of the code tab if you are not using .items files.

I really can’t guess why it’s suddenly failing for you and more importantly, how your change actually fixed it.;

NOTE: I do notice that line 117 where I import the StringItem class from Java is superfluous and should be removed.

Of course. That’s what I did to notice that the type is DateTime:

  if(items[itemName].type != 'DateTimeItem') {
    console.warn (items[itemName].type)
    throw itemName + ' is not a DateTime Item!';
  }

Output:

2024-04-09 19:07:32.187 [WARN ] [omation.rules_tools.TimeStateMachine] - DateTime
2024-04-09 19:07:32.188 [WARN ] [omation.rules_tools.TimeStateMachine] - Item Default_Bed's configuration is invalid:
Default_Bed is not a DateTime Item!

The output for the String:

2024-04-09 19:23:09.569 [WARN ] [omation.rules_tools.TimeStateMachine] - String
2024-04-09 19:23:09.570 [WARN ] [omation.rules_tools.TimeStateMachine] - The state Item TimeOfDay is not a String Item!
2024-04-09 19:23:09.861 [WARN ] [omation.rules_tools.TimeStateMachine] - The config is not valid, cannot proceed!

Anything else I can test?

I can’t think of anything. I’m not seeing anything like that and I’m running 4.2 M2. I can’t imagine why it’s different for you.

20│2024-04-09 08:23:47.921 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.923 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.926 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.929 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.932 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.935 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.938 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.941 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.943 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.947 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.949 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.952 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.955 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.958 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
20│2024-04-09 08:23:47.961 [INFO ] [omation.rules_tools.TimeStateMachine] - DateTimeItem                                                                                                                                                 │
00│2024-04-09 08:23:47.963 [INFO ] [omation.rules_tools.TimeStateMachine] - All etod Items are configured correctly                                                                                                                      │4520│2024-04-09 08:23:47.964 [INFO ] [omation.rules_tools.TimeStateMachine] - StringItem                                                                                                                                                   │  20│2024-04-09 08:23:48.219 [INFO ] [omation.rules_tools.TimeStateMachine] - Today is a default day.                                                                                                                                      │  20│2024-04-09 08:23:48.261 [INFO ] [omation.rules_tools.TimeStateMachine] - The current state is DAY                                                                                                                                     │  

What version of openhab-js are you running? Maybe there’s a discrepancy there?

I did just look and I might have an older version installed through npm. I removed it and when I run using the built in library and now I do see this error. There was nothing mentioned in the release notes about a change like this.

I tracked down the source of the change and filed an issue: items.MyItem.type no longer includes "Item" in the type Ā· Issue #327 Ā· openhab/openhab-js Ā· GitHub.

In the mean time, the template needs to be updated to work with 4.2 M2. I don’t know if the change needs to be permanently made or if the breaking change in openhab-js will be backed out as a result of the issue.

So I’m probably going to change the template to use startsWith() instead of == so it matches both ā€œStringā€ and ā€œStringItemā€. That should cover all the bases.

Edit: This uncovered a minor bug in OHRT too. Productive day. :slight_smile:

The fix has been checked in.

1 Like

Dear Rich,
thank you very much for this great template. It works very well and helps a lot to simplify rule creations for activities over the day.
One additional feature, which I think would be helpful, is a connection to iCalendar which would decide what type of day the current day is. At the moment a private holiday can be defined via an Ephemeris XML file which is not very handy. It would be much easier to have an entry in a calendar with a trigger word matching the dayset.

Cheers, Tobias

I don’t use the iCal binding so probably wouldn’t be the best to implement something like that. But if someone were to submit a PR I’d review it and merge it. Of course, anyone can make any changes they want to to a rule once it’s instantiated by a rule template. One of the great things about templates is that they can be customized by the end users.

Dear Rich,
thank you for your fast answer. I was looking a bit into your code and I think a very simple solution would be to put another string item as a type at the highest priority (custom_string, custom, holiday, dayset, weekend, weekday, default).
The string item can be filled by an external rule using the iCalendar or by something else. If it is ā€œUndefinedā€ it is ignored and one of the other types is used, otherwise the DateTime items matching the string are taken.
You could even go a step further and remove the complete Ephemeris stuff and put it into the external rule and only use the string item to select the proper DateTime items but this might require more work by the user.

Cheers, Tobias

Well, like I said, I’ll gladly accept and merge a PR that provides this capability.

Hi Rich, ive been using your time of day rules in OH2 and 3 with success but its not clear to me what I need to do for this in OH4

I can’t find your script either?

My items file is:

Group:DateTime TimesOfDay
String TimeOfDay "Current time of day [%s]"

DateTime Default_Morning (TimesOfDay)   { etod="MORNING"[type="default"] }
DateTime Default_Day (TimesOfDay)       { etod="DAY"[type="default"] }
DateTime Default_Evening (TimesOfDay)   { etod="EVENING"[type="default"] }
DateTime Default_Night (TimesOfDay)     { etod="NIGHT"[type="default"] }

//Astro

String vDaylight_Duration                           { channel="astro:sun:ihp:daylight#duration" }
Number:Angle vSun_Azimuth                           { channel="astro:sun:ihp:position#azimuth" }
Number:Angle vSun_Elevation                         { channel="astro:sun:ihp:position#elevation" }
Number vMoon_Percent                                { channel="astro:moon:ihp:phase#name" }
DateTime vSunrise_Time "Day [%1$tH:%1$tM]"          { channel="astro:sun:ihp:rise#start" }
DateTime vSunset_Time "Evening [%1$tH:%1$tM]"       { channel="astro:sun:ihp:set#start" }

Can you dumb it down a little for me/us?

The error I get is:

15:45:32.918 [ERROR] [t.javascript.Time_of_Day_Calculations] - Failed to execute script: The {{timeOfDay}} Item is not defined!
        at <js>.:program(<eval>:321)
        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 java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:262)
        ... 75 more
15:45:32.918 [ERROR] [.internal.handler.ScriptActionHandler] - Script execution of rule with UID 'Time_of_Day_Calculations' failed: org.graalvm.polyglot.PolyglotException: The {{timeOfDay}} Item is not defined!

I just want to calculate the time of day for Morning, Day, Evening and Night - nothing special I dont think

If you don’t need different times for different types of days this might be a little overkill for you. You can set the DateTime Items states and then use the Time is <item> trigger on a rule to change the states.

  • Trigger the rule with each of the four time of day Items using the Time is Item trigger to use the time only and ignore the date so you don’t need to update the Item every day
  • The script action in JS for a managed rule would be something like:
var tod = event.itemName.replace("Default_", "").toUpperCase();
items.TimeOfDay.sendCommandIfDifferent(tod);

In Blockly the script action would look something like

What do you mean you can’t find it. It’s not showing up in the Add-on store? It should be listed under Add-on Store → Automation → Rule Templates

Click ā€œAddā€ and verify that it installs (the ā€œaddā€ will change to ā€œremoveā€). If if fails you’ll get a toast telling you it failed and you’ll see why in openhab.log.

Then you need it instantiate a rule based on the template.

  1. Navigate to Settings → Rules → +
  2. Fill out the rule metadata (ID, label, description, etc.).
  3. Choose ā€œTime Based State Machineā€ as the template and fill out the form

Choose your ā€œTimeOfDayā€ Item from your list of Items for the first one, your ā€œTimesOfDayā€ Item from the list of Items for the second one and enter ā€œetodā€ for the Time of Day Namespace.

  1. Click save

Watch the logs. The rule will run automatically when you hit save but there is a 10 second delay from when the rule triggers and it actually runs so the rule doesn’t run a bunch at midnight when Astro et. al. are updating Items with the new times for the current day. If there is an error it should generate a meaningful error message in the logs. Otherwise you will see it update TimeOfDay.

2024-07-29 00:05:10.184 [INFO ] [omation.rules_tools.TimeStateMachine] - All etod Items are configured correctly
2024-07-29 00:05:10.386 [INFO ] [omation.rules_tools.TimeStateMachine] - Today is a default day.
2024-07-29 05:59:00.000 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from BED to DAY

You don’t need to copy/paste/edit or even look at the code. That’s the whole point of rule templates. However, if you did want to look at or modify the code, you can navigate to the Rule you instantiated based on the template and examine the code that was generated. Once instantiated it just a rule like any other.

All of my rule templates require the JS Scripting add-on and openHAB Rules Tools Announcements.

If you are looking for a file based rule, you will not be able to use rule templates. Rule tempaltes are UI/managed rules only.

I have no plans on creating a file based version of any of my templates (I’ve stepped way back from file based config support, it’s a waste of my time fighting syntax errors). You should be able to look at the code generated though and create your own. The link at the bottom of the OP is the raw rule template code and you can use that too to create your own file based version. Just be aware that in my rule templates roughly half of the code is checking the configuration and other tests to make sure the configuration is correct and generating meaningful and actionable error logs when there is a problem. If you are just wanting something for yourself you can cut a lot of that out.

Thanks Rich and do you have sample items file?

Seems ive got something wrong, log file says:


08:43:23.625 [INFO ] [tomation.rules_tools.TimeStateMachine] - All etod Items are configured correctly
08:43:23.629 [WARN ] [tomation.rules_tools.TimeStateMachine] - The state Item Default_Day is not a String Item!
08:43:23.797 [WARN ] [tomation.rules_tools.TimeStateMachine] - The config is not valid, cannot proceed!

Changing them to String, from DateTime fixes that but then I get:

08:45:09.747 [WARN ] [tomation.rules_tools.TimeStateMachine] - Item Default_Night's configuration is invalid:
Default_Night is not a DateTime Item!
08:45:09.749 [WARN ] [core.internal.scheduler.SchedulerImpl] - Scheduled job 'ui.Time_of_the_Day.debounce' failed and stopped
org.graalvm.polyglot.PolyglotException: TypeError: Assignment to constant "isGood"
        at <js>.:=>(/etc/openhab/automation/node_modules/openhab_rules_tools/helpers.js:64) ~[?:?]
        at <js>.checkGrpAndMetadata(/etc/openhab/automation/node_modules/openhab_rules_tools/helpers.js:53) ~[?:?]
        at <js>.validateAllConfigs(<eval>:110) ~[?:?]
        at <js>.createTimersGenerator(<eval>:205) ~[?:?]
        at <js>.:=>(/etc/openhab/automation/node_modules/openhab_rules_tools/timerMgr.js:66) ~[?:?]
        at <js>.callbackFn(/node_modules/openhab.js:2) ~[?:?]
        at com.oracle.truffle.polyglot.PolyglotFunctionProxyHandler.invoke(PolyglotFunctionProxyHandler.java:154) ~[bundleFile:?]
        at jdk.proxy1.$Proxy649.run(Unknown Source) ~[?:?]
        at org.openhab.automation.jsscripting.internal.threading.ThreadsafeTimers.lambda$0(ThreadsafeTimers.java:85) ~[bundleFile:?]
        at org.openhab.core.internal.scheduler.SchedulerImpl.lambda$12(SchedulerImpl.java:189) ~[?:?]
        at org.openhab.core.internal.scheduler.SchedulerImpl.lambda$1(SchedulerImpl.java:88) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
        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:1136) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
        at java.lang.Thread.run(Thread.java:840) [?:?]

My items are:

Group:DateTime TimesOfDay
String TimeOfDay "Current time of day [%s]"

String Default_Morning (TimesOfDay)   { etod="MORNING"[type="default"] }
String Default_Day (TimesOfDay)       { etod="DAY"[type="default"] }
String Default_Evening (TimesOfDay)   { etod="EVENING"[type="default"] }
String Default_Night (TimesOfDay)     { etod="NIGHT"[type="default"] }


Your ā€œDefault_XYZā€ items should be DateTime and not String. You had it right before… :wink:

1 Like

I have an issue after the update to OH 4.2 (including JS-Scripting). I had everything working fine before.
Now I get the log message

2024-07-30 09:44:08.601 [WARN ] [omation.rules_tools.TimeStateMachine] - Item Default_Bed's configuration is invalid: Default_Bed is not a DateTime Item!

All of my Time-Items are DateTime:

I even created ā€œDefault_Bedā€ new from scratch. No success. :frowning:

Metadata also is according to documentation (and worked before)

Any ideas?

I don’t use .items files.

The first error is you chose the wrong Item for the Time of Day State Item. You need to choose your TimeOfDay Item, not Default_Day. The TimeOfDay Item is properly defined as a String.

The second error is because all the members of TimesOfDay need to be DateTime Items and all of them must have a non NULL and non UNDEF state. Ony the time portion of the DateTime will be used though so you don’t have to worry about the date. You’ve defined them as String Items.

That’s weird. It only complains about that one Item? I’m on OH 4.2 release too.

What do you get output from the following two lines (run them from -Scratchpad- or a temporary rule or something:

console.info('openhab-js version: ' + utils.OPENHAB_JS_VERSION);
console.info('OHRT version: ' + helpers.OHRT_VERSION);

Also put the logging level to DEBUG for org.openhab.automation.rules_tools.TimeStateMachine. You can do this all the usual ways including by editing the line at the top of the script action:

//osgi.getService('org.apache.karaf.log.core.LogService').setLevel(console.loggerName, 'INFO');

becomes

osgi.getService('org.apache.karaf.log.core.LogService').setLevel(console.loggerName, 'DEBUG');

That will change the logging level in the rule itself. Run the rule manually then comment the line out so it doesn’t try to change the level every time the rule runs. If a rule is triggered too quickly and it changes it’s log level every time you run the risk of wiping out your log4j2.xml file.

Please post the debug logs. Also click on the code tab and post what you find under ā€œconfigurationā€. For example here’s mine.

configuration:
  namespace: etod
  timesOfDayGrp: TimesOfDay
  timeOfDay: TimeOfDay

Alternatively you can look at scrpt action and post the properties. Here’s mine for example:

// Properties
var STATE_ITEM  = "TimeOfDay";
var DT_GROUP    = "TimesOfDay";
var DAY_TYPES   = ['custom', 'holiday', 'dayset', 'weekend', 'weekday', 'default'];
var NAMESPACE   = 'etod';
1 Like

I just upgraded today to 4.2 and have a similar issue as @Marfi. For now, because I need to get it working, I’m reverting back to 4.1 tonight (Proxmox VM backup) until I have time to look at it in more detail. It complained about debounce failing. There was Warning of a constant for isGood and debounce failed. I’ll try to post more information as I try it again tomorrow. Several Default_XYZ items noted as not configured correctly, even though it has worked without issue from the 3.x to 4.1-y releases.

I’ll need logs for most of that but if you just upgraded and it’s complaining about Items it’s likely those Items are NULL instead of having a valid DateTime.

Yes, it complains just about ā€œDefault_Bedā€. All other items seem to be ok.

It says

2024-07-31 07:34:03.789 [INFO ] [nhab.automation.script.ui.scratchpad] - openhab-js version: 5.3.1
2024-07-31 07:34:03.793 [INFO ] [nhab.automation.script.ui.scratchpad] - OHRT version: 2.0.3

Debug Log of the rule shows the following:

2024-07-31 07:36:10.063 [DEBUG] [omation.rules_tools.TimeStateMachine] - Starting state machine in ten seconds...

2024-07-31 07:36:10.269 [INFO ] [port.EventAdminConfigurationNotifier] - Sending Event Admin notification (configuration successful) to org/ops4j/pax/logging/Configuration

2024-07-31 07:36:20.136 [DEBUG] [omation.rules_tools.TimeStateMachine] - Validating Item types, Item metadata, and Group membership

==> /var/log/openhab/openhab.log <==

2024-07-31 07:36:20.276 [WARN ] [omation.rules_tools.TimeStateMachine] - Item Default_Bed's configuration is invalid:

Default_Bed is not a DateTime Item!

2024-07-31 07:36:20.290 [WARN ] [ore.internal.scheduler.SchedulerImpl] - Scheduled job 'ui.c80e2e1740.debounce' failed and stopped

org.graalvm.polyglot.PolyglotException: TypeError: Assignment to constant "isGood"

	at <js>.:=>(/etc/openhab/automation/js/node_modules/openhab_rules_tools/helpers.js:64) ~[?:?]

	at <js>.checkGrpAndMetadata(/etc/openhab/automation/js/node_modules/openhab_rules_tools/helpers.js:53) ~[?:?]

	at <js>.validateAllConfigs(<eval>:110) ~[?:?]

	at <js>.createTimersGenerator(<eval>:205) ~[?:?]

	at <js>.:=>(/etc/openhab/automation/js/node_modules/openhab_rules_tools/timerMgr.js:66) ~[?:?]

	at <js>.callbackFn(/etc/openhab/automation/js/node_modules/openhab/src/actions/actions.js:271) ~[?:?]

	at com.oracle.truffle.polyglot.PolyglotFunctionProxyHandler.invoke(PolyglotFunctionProxyHandler.java:154) ~[?:?]

	at jdk.proxy1.$Proxy530.run(Unknown Source) ~[?:?]

	at org.openhab.automation.jsscripting.internal.threading.ThreadsafeTimers.lambda$0(ThreadsafeTimers.java:85) ~[?:?]

	at org.openhab.core.internal.scheduler.SchedulerImpl.lambda$12(SchedulerImpl.java:189) ~[?:?]

	at org.openhab.core.internal.scheduler.SchedulerImpl.lambda$1(SchedulerImpl.java:88) ~[?:?]

	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]

	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:1136) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]

	at java.lang.Thread.run(Thread.java:840) [?:?]

Configuration of the rule is

configuration:
  namespace: tsm
  timesOfDayGrp: gTimesOfDay
  timeOfDay: TimeOfDay

Here are my properties:

// Properties
var STATE_ITEM  = "TimeOfDay";
var DT_GROUP    = "gTimesOfDay";
var DAY_TYPES   = ['custom', 'holiday', 'dayset', 'weekend', 'weekday', 'default'];
var NAMESPACE   = 'tsm';

OK, that eliminates different versions of the libraries being a cause. I’m running with the exact same versions.

Show the definition of this Item.

This error comes from the following lines of code:

  if(!items[itemName].type.startsWith('DateTime')) {
    throw itemName + ' is not a DateTime Item!';
  }

There’s not a whole lot that should be able to go wrong with that so it’s not clear what’s happening.

In -Scratchpad- can you run and report the logs from the following line?

console.info(items.Default_Bed.type + ' ' + items.Default_Bed.type.startsWith('DateTime'));

Hmmm, I’ve fixed this before.

Are you running the latest version? At the top of the script action there is a comment indicating the version. It should read:

// Version 1.0

If not you are not running on the latest version and there are indeed breaking changes in openhab-js 4.9.0 which would break the rule’s ability to determine if the time Items are a DateTime type. openhab-js 4.9.0 changed then return of items[itemName].type from "DateTimeType" to DateTime. Previously I was testing to see if the type equals"DateTimeType" which obviously fails now. I changed it to ā€œstartsWithā€ so it would work with older openhab-js still as well as the new versions going forward.

The isGood error I fixed at the same time and it was caused by declaring isGood as a const instead of using let.

Unfortunatly there isn’t a way to automatically update rule tempaltes. You have to watch them for updates and use the following process to update:

  1. remove the instantiated rule
    a. if the rule has lots of properties copy the ā€œconfigurationā€ from the code tab for use later
  2. go to the Add-on store and remove the rule template
  3. refresh the page (this step probably isn’t necessary
  4. re-add the rule template
  5. reinstantiate the rule(s) based on the template, use the config saved from step 1.a. if necessary
  6. run the rule manually to test out the config

If you or @RipNCode are on version 0.5 or even earlier then that would explain why it’s not working.

You should get into the habbit of reviewing the rule templates you’ve installed every time you upgrade OH to see if there is a newer version you need to install. Just like regular rules, rule templates require changes to keep up with breaking changes to the API.