You might need to enable it. I can’t remember if it’s enabled by default. Settings → Community Marketplace and toggle on “Enable Community Marketplace” and you’ll see rule templates listed under the add-ons.
Upgrade to OH 4 M3 which should include the fix in openhab-js that will fix this problem. IIRC it was released before M3. If not you can install openhab-js by running npm install openhab from the $OH_CONF/automation/js folder and setting the add-on to not use the built in library under Settings → JavaScript Scripting.
There was a bug in the library that parses Date Time Strings which has since been fixed.
I just tested it on snapshot #3477 and can confirm that the fix exists in at least that version.
That’s not going to work. Mainly it’s not going to understand what to do with the properties and it’s not going to to the parameter substitution ( the stuff in {{ }} gets replaced with the value selected for that given parameter when the rule is instantiated from the template).
You could modify things manually but it’s better to install the template from the marketplace. Then you will create a new rule and select the template to create the rule from. You’ll have some properties to fill in and then the rule will be instantiated.
2023-05-24 23:42:57.106 [ERROR] [ity.CommunityMarketplaceAddonService] - bundle org.openhab.core.addon.marketplace:4.0.0.M2 (151)[org.openhab.core.addon.marketplace.internal.community.CommunityMarketplaceAddonService(49)] : Error during instantiation of the implementation object
java.lang.reflect.InvocationTargetException: null
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[?:?]
at jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77) ~[?:?]
at jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[?:?]
at java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499) ~[?:?]
But in Karaf, the bundle is listed as active. Trying to restart it logs nothing:
openhab> list | grep -i community
152 │ Active │ 80 │ 4.0.0.M2 │ openHAB Core :: Bundles :: Community Marketplace Add-on Service :: Karaf
This is the only thing a search for time gives me …
When you upgraded did you do anything to any of the marketplace files in $OH_USERDATA/jsondb? There is a formatting change between OH 3 and OH 4 that requires these files to be regenerated on OH 4. I don’t know if the new upgrade tool that has been released in M3 handles this or not.
Stop OH, move any file with “marketplace” in the name out of the jsondb folder and any backup for those files in the jsondb/backup folder also. If you miss the backups OH will just move to use those instead.
I think only the org.openhab.marketplace.json needs to be deleted but you may as well be thorough. But if you are worried you can just start with that file and see what happens.
You were right!
There was one org.openhab.marketplace.json and 4 variations in backups all from 7. April. Stopped OH, deleted them, restarted OH, and Viola.
I’m back:
2023-05-25 19:28:18.003 [INFO ] [omation.rules_tools.TimeStateMachine] - All etod Items are configured correctly
2023-05-25 19:28:18.789 [INFO ] [omation.rules_tools.TimeStateMachine] - Today is a default day.
2023-05-25 19:28:19.017 [INFO ] [omation.rules_tools.TimeStateMachine] - The current state is EVENING
^
Final question: the old rule (now deleted) had a schedule associated with it.
Still needed?
I’m not sure what you mean by a schedule. Do you mean it appeared in the Schedule rules screen? That’s just a different view of rules. It shows those rules with a “Schedule” tag which have time based triggers. But this latest version of the rule doesn’t have a time based trigger so it wouldn’t show up there even if it had the “Schedule” tag.
IC. It was a leftover from a few years back then.
Looks good now.
My system discussed so far was x86_64 Ubuntu server, but when logging in to my remote home, running a Rpi4 Bullseye 32, OH apt installed, I had to do the exact same thing minus the marketplace.
For others coming here, there are several solutions
And after updating to M3 I get: (nothing else changed)
2023-05-25 21:34:11.680 [WARN ] [omation.rules_tools.TimeStateMachine] - Time Based State Machine Usage:
All date times must be a member of TimesOfDay.
Each member of the Group must have etod Item metadata of the following format:
.items file: etod="STATE"[type="daytype", set="dayset", file="uri"]
UI YAML: use 'etod' for the namespace and metadata format:
value: STATE
config:
type: daytype
set: dayset
file: uri
Where "STATE" is the state machine state that begins at the time stored in that Item, "daytype" is one of "default", "weekday", "weekend", "dayset", "holiday", or "custom". If "dayset" is chosen for the type, the "set" property is required indicating the name of the custom dayset configured in Ephemeris. If "custom" is chosen as the type, the "file" property is required and should be the fully qualified path the the Ephemeris XML file with the custom holidays defined. The "set" and "file" properties are invalid when choosing any of the other "types".
2023-05-25 21:34:12.121 [WARN ] [omation.rules_tools.TimeStateMachine] - The config is not valid, cannot proceed!
There should be one or more line above that that starts with something like"Item X’s configuration is invalid:" with a message for what’s wrong with it.
2023-05-25 22:17:29.412 [WARN ] [omation.rules_tools.TimeStateMachine] - Item Weekend_Bed's configuration is invalid:
Weekend_Bed is not initialized!: NULL
2023-05-25 22:17:29.422 [WARN ] [omation.rules_tools.TimeStateMachine] - Item Default_Evening's configuration is invalid:
Default_Evening is not initialized!: UNDEF
2023-05-25 22:17:29.429 [WARN ] [omation.rules_tools.TimeStateMachine] - Item Default_Morning's configuration is invalid:
Default_Morning is not initialized!: NULL
2023-05-25 22:17:29.434 [WARN ] [omation.rules_tools.TimeStateMachine] - Item Default_Night's configuration is invalid:
Default_Night is not initialized!: NULL
2023-05-25 22:17:29.444 [WARN ] [omation.rules_tools.TimeStateMachine] - The following Items have an invalid configuration: Weekend_Bed,Default_Evening,Default_Morning,Default_Night
Group:DateTime TimesOfDay
String TimeOfDay "Current time of day [%s]" <time>
// Default day, initialization for JavaScript should be done thgrough MainUI. See https://community.openhab.org/t/oh-3-examples-how-to-boot-strap-the-state-of-an-item/108234
DateTime Default_Morning "MORNING [%s]" <time> (TimesOfDay) { etod="MORNING"[type="default"] }
DateTime Default_Day "DAY [%s]" <time> (TimesOfDay) { etod="DAY"[type="default"] }
DateTime Default_Evening "EVENING [%s]"<time> (TimesOfDay) { etod="EVENING"[type="default"] }
DateTime Default_Night "NIGHT [%s]" <time> (TimesOfDay) { etod="NIGHT"[type="default"] }
DateTime Default_Bed "BED [%s]" <time> (TimesOfDay) { etod="BED"[type="default"] }
// Weekend day, notice that not all the states are listed, the unlisted states are skipped
DateTime Weekend_Day "WEEKEND DAY [%s]" <time> (TimesOfDay) { channel="astro:sun:home:rise#start", etod="DAY"[type="weekend"] }
DateTime Weekend_Evening "WEEKEND DAY [%s]" <time> (TimesOfDay) { channel="astro:sun:home:set#start", etod="EVENING"[type="weekend"] }
DateTime Weekend_Bed "WEEKEND BED [%s]" <time> (TimesOfDay) { etod="BED"[type="weekend"] }
But this worked on M2. I also tried deleting and recreating the rule. Same error.
Well the error should be pretty clear. The states of those Items-- are NULL. The rule requires all the members of the Group TimesOfDay to have a valid state. They can’t be NULL. They can’t be UNDEF.
Something happened during the upgrade that caused those Items to not restoreOnStartup or something is about all I can guess.
Yes, population from influx probably failed. Plan a separate thread for that. It times out. Probably because I have a lot of history. Seems OK after a while, as I get historical values in my sitemap graphs.
Repopulated and now it is OK. How did you see they were NULL/UNDEF?
Log just said ‘invalid configuration’, not invalid value …
M3 did not turn out well for me …
No rules were executed! Tried rebooting several times. Could control items, but no rules triggered.
Downgraded to M2 and all was well again, but when the ephemTOD script startet at 00:05 it threw this:
2023-05-26 00:05:14.987 [INFO ] [omation.rules_tools.TimeStateMachine] - All etod Items are configured correctly
2023-05-26 00:05:15.256 [INFO ] [omation.rules_tools.TimeStateMachine] - Today is a default day.
2023-05-26 00:05:15.346 [WARN ] [omation.rules_tools.TimeStateMachine] - There is no date time for today before now, we can't know what the current state is.
Same on my 2nd site:
2023-05-26 00:05:10.794 [INFO ] [omation.rules_tools.TimeStateMachine] - All etod Items are configured correctly
2023-05-26 00:05:10.955 [INFO ] [omation.rules_tools.TimeStateMachine] - Today is a default day.
2023-05-26 00:05:11.056 [WARN ] [omation.rules_tools.TimeStateMachine] - There is no date time for today before now, we can't know what the current state is.
Seems like it started working on the MORNING trigger:
2023-05-26 01:29:20.262 [WARN ] [omation.rules_tools.TimeStateMachine] - There is no date time for today before now, we can't know what the current state is.
2023-05-26 01:35:56.265 [INFO ] [omation.rules_tools.TimeStateMachine] - All etod Items are configured correctly
2023-05-26 01:35:56.478 [INFO ] [omation.rules_tools.TimeStateMachine] - Today is a default day.
2023-05-26 01:35:56.509 [WARN ] [omation.rules_tools.TimeStateMachine] - There is no date time for today before now, we can't know what the current state is.
2023-05-26 01:37:39.177 [INFO ] [omation.rules_tools.TimeStateMachine] - All etod Items are configured correctly
2023-05-26 01:37:39.294 [INFO ] [omation.rules_tools.TimeStateMachine] - Today is a default day.
2023-05-26 01:37:39.325 [WARN ] [omation.rules_tools.TimeStateMachine] - There is no date time for today before now, we can't know what the current state is.
2023-05-26 01:37:39.327 [WARN ] [omation.rules_tools.TimeStateMachine] - time.toZDT()=2023-05-26T01:37:39.326+02:00[SYSTEM]
2023-05-26 07:00:00.016 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from EVENING to MORNING
2023-05-26 07:00:00.016 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from EVENING to MORNING
2023-05-26 07:00:00.017 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from EVENING to MORNING
2023-05-26 07:00:00.017 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from EVENING to MORNING
2023-05-26 07:00:00.019 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from EVENING to MORNING
2023-05-26 07:00:00.028 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from EVENING to MORNING
2023-05-26 07:00:00.042 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from EVENING to MORNING
2023-05-26 07:37:25.351 [INFO ] [omation.rules_tools.TimeStateMachine] - All etod Items are configured correctly
2023-05-26 07:37:25.471 [INFO ] [omation.rules_tools.TimeStateMachine] - Today is a default day.
And now the 2nd site followed suit am hour later.
First is at GMT+2, the other one at GMT+1
There’s something fishy with DST…
IC.
My influxDB system fails with a timeout during startup, and my RRD4j system is not able to persist strings?
Since Default_Day.sendCommand(“09:00:00”), why does both systems change state at 10:00?
2023-05-26 10:00:00.006 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from MORNING to DAY
2023-05-26 10:00:00.006 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from MORNING to DAY
2023-05-26 10:00:00.006 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from MORNING to DAY
2023-05-26 10:00:00.007 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from MORNING to DAY
2023-05-26 10:00:00.007 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from MORNING to DAY
2023-05-26 10:00:00.010 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from MORNING to DAY
2023-05-26 10:00:00.010 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from MORNING to DAY
2023-05-26 08:00:00.002 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from NIGHT to MORNING
2023-05-26 10:00:00.001 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from MORNING to DAY
And Default_Morning.sendCommand(“06:00:00”) at 07:00?
Is it related to Regional time setting? (Which don’t seem to follow DST automatically).
MapDB configured to just do restoreOnStartup. It’s embedded so it will always be there and it will be very fast.
rrd4j for stuff you want to chart configured without restoreOnStartup
External databases only for those Items you want to do some serious analysis on using external tools
This gives the maximum robustness to meet all of those requirements.
You’ve got a timezone issue somewhere. There are multiple places where the timezone can be taken from:
operating system
JVM
openHAB regional settings
Most of the time, when there is a problem with timezones it can be fixed by setting it on the JVM side. There are tons of posts on the forum but I believe it just involves adding extra options to the java command that kicks off OH and there is a config file somewhere that does that. I don’t have an installed version of OH, just Docker and I can set the timezone through an environment variable with that sort of install. I can’t tell you where it is on an installed OH.
Still all state changes are 2hrs behind.
I decided to take a more simple approach:
// Time Of Day
rule "06_00"
when
Time cron "0 0 6 ? * * *" // 06:00
then
TimeOfDay.sendCommand("MORNING")
logInfo("TimeOfDay", "Transitioning from BED to MORNING")
end
rule "09_00"
when
Time cron "0 0 9 ? * * *" // 09:00
then
TimeOfDay.sendCommand("DAY")
logInfo("TimeOfDay", "Transitioning from MORNING to DAY")
end
rule "18_00"
when
Time cron "0 0 18 ? * * *" // 18:00
then
TimeOfDay.sendCommand("EVENING")
logInfo("TimeOfDay", "Transitioning from DAY to EVENING")
end
rule "23_00"
when
Time cron "0 0 23 ? * * *" // 23:00
then
TimeOfDay.sendCommand("NIGHT")
logInfo("TimeOfDay", "Transitioning from EVENING to NIGHT")
end
rule "00_00"
when
Time cron "0 0 0 ? * * *" // 00:00
then
TimeOfDay.sendCommand("BED")
logInfo("TimeOfDay", "Transitioning from NIGHT to BED")
vDayOfWeek.sendCommand(now.getDayOfWeek.toString())
logInfo("System", "DAY=" + now.getDayOfWeek)
end
Works fine:
yaml
omr@shs2:~$ grep -i transition /var/log/openhab/openhab.log | grep -i trans
2023-06-01 20:00:00.003 [INFO ] [omation.rules_tools.TimeStateMachine] - Transitioning Time State Machine from DAY to EVENING
2023-06-01 23:00:00.496 [INFO ] [.openhab.core.model.script.TimeOfDay] - Transitioning from EVENING to NIGHT
2023-06-02 00:00:00.495 [INFO ] [.openhab.core.model.script.TimeOfDay] - Transitioning from NIGHT to BED
But, I will always wonder why it didn’t work out with the template …
All I can think of is that the TZ on the DateTime Item states themselves was off, or maybe the times themselves.
I do recommend the simpler approach anyway in cases where you don’t have a different set of times based on the type of the day. It would be interesting to see what would happen if you used the Time is <Item> timeOnly trigger instead of cron. Would those still trigger two hours off?
