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 
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. 
The fix has been checked in.
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