That’s what happens unless you choose something else.
This is about persistence and restore on startup, topics outside the scope of this thread.
Because you’ve upgraded, you’ve likely carried accross your old persistence settings, and should review what you are persisting where, and what you would like to restore.
I don’t believe its related to persistence because these items are brand new, related to the java version of the Time of Day rule by Rich
There is no persistence configuration for these items (Default_Bed) - the ones set by the binding Astro are fine. It’s the one that use the input-card. My understanding is what once this metadata is set on the item, it should stay across a reboot.
Okay, well whatever magic service you are relying on to carry Item states across a reboot that is not persistence is unknown to us.
If your metadata has gone away, that’s a different business. Are you mix’n’matching defining Items from file and metadata from GUI? Won’t work.
Fair enough
Whats the purpose of this then on an item which has no binding channel?
Makes no sense to me to set meta data that set its time, to not carry across. I dont see the point of the entire post made by Rich when I could have easily just set the values to 1, persisted it for restore on startup. The whole metadata thing for this purpose only doesnt seem useful.
Anyway, ill add them to persistence.
Once that’s done the rule runs @rlkoshak but the times for Default_Night etc are incorrect, despite me having the correct Ephemeris.
Its currently 9.28pm (NIGHT) but this shows:
openhab> openhab:status Default_Night
2021-09-17T00:00:00.000+1000
openhab> openhab:status TimeOfDay
DAY
openhab>
It all depends what you are trying to do.
Fact A - all Items start life with state NULL, unless you do something about it.
Quote from Rich’s linked post -
There are multiple ways you can deal with this problem
For example, an Item might be linked to an Astro output channel. When the binding starts up, it updates that Item with something meaningful. That’s that one sorted then.
For another example, you might use the interactive REST API tool to manually post a new state to your Item. Sorted.
But wait … back to Fact A. If we reboot, we get state NULL again, wahh.
The Item state is not automatically remembered across a reboot, and that is by design.
Okay, let’s add a “remember” feature and call it restore-on-startup. We configure a persistence service to remember our Item state, say every so often, or when it changes. And also enable the persistence service restore-on-startup feature for our Item.
That’s sorted, now we only need update the Item by hand once using REST API and it’ll get remembered.
At least, until an upgrade or database error or something messes up. Then we’d have to manually fix it again.
Seems a bit clonky, can we automate the initial manual update? Of course, make a rule triggered on system started, that examines the Item state. If it finds NULL, update it with your chosen value, sorted.
Still a bit clonky though - you have to hardcode the desired state into rules. How about if we could attach the desired start-up state to the Item in some way? After all we already define labels and icons and stuff when we define the Item.
Let’s use metadata - in OH3 we can use this pretty freely for our own purposes. So for any Item, we could define a default state in metadata. And then our system started rule is changed so that it looks for NULL, and if it finds it, uses the metadata for the state update (instead of something hardcoded in the rule).
Rich’s solution -
https://github.com/rkoshak/openhab-rules-tools/tree/main/item_init
Another important quote from Rich -
If you want to stick to .items files, you will have to look at the code that is generated to figure out how to apply it in your .items files.
But wait - this is going to ‘reset’ the Item at every boot. My Item is, say. a time to turn on heating. The whole idea of using an Item was so that I could alter this from my UI. If I alter it, that gets lost at reboot, wahh.
Go back to “restore-on-startup” above - you can do more than one thing.
Golly, four things to do now, that’s complicated. Restore, startup metadata, startup rule, and my ‘ordinary’ UI widget for when I want to alter it.
How about if we simplify. Make our UI widget deal with NULL state and offer the default values if needed. That’s what this is about -
None of this is within the scope of this thread.
It’s best to address the same topic only in one thread. I’ve provided an answer in the other place you asked this. It is related to persistence just as rossko57 indicates.
To provide a way to initialize the state of an Item from the UI. But if you want that state to be restored you still have to use Persistence.
You are not setting metadata on the Item in that tutorial. You are providing the Item’s state same as when you click on a Switch in BasicUi or postUpdate from a Rule. Nothing more.
The metadata is used to provide additional information to the Time Of Day rule such as what’s is the name of the time of day that starts at the time represented by this Item and what type of day should this Item be used on. The actual DateTime is, always was, and remains the state of the Item. The boot strap tutorial has nothing to do with metadata.
As I’ve already mentioned, every time you change anything with the DateTime Items you need to make sure the Time of Day rule runs. When you change the Item’s state it should run the rule automatically. If you add/remove an Item from the TimesOfDay Group or change the Item’s metadata or modify the rule itself in any way you need to manually rerun the rule. There is no event in any of those cases to trigger the rule with.
Beyond that I’d need to see the Item’s metadata, confirm that it is in the TimesOfDay group, and see the logs from a run of the rule, preferably a debug log.
Unfortunately, an important gotcha with that library is I’ve not implemented it in JavaScript for OH 3 yet. It doesn’t use DateTime Items so it should work if one has Python working and has the latest Helper Libraries installed. I do not yet have a stand alone version of that for OH 3 yet though.
It’s been a low priority since one can simply use a UI widget and persistence and the advantage with that approach is you’ve now a UI widget to adjust it later from MainUI instead of needing to change Item configs. That’s a bit more flexible for setting schedules I think. Eventually I want to get to the point where either this code is replaced by a real scheduler in OH or I can add the ability to add/remove times of day Items through MainUI widgets.
Hi Rich
My items are:
And yes, aware I need to rerun the rule
items:
Group:DateTime TimesOfDay
String TimeOfDay "Current time of day [%s]"
// 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 (TimesOfDay) { etod="MORNING"[type="default"] }
DateTime Default_Day (TimesOfDay) { channel="astro:sun:ihp:set#start", etod="DAY"[type="default"] }
DateTime Default_Evening (TimesOfDay) { channel="astro:sun:ihp:set#start", etod="EVENING"[type="default"] }
DateTime Default_Night (TimesOfDay) { etod="NIGHT"[type="default"] }
DateTime Default_Bed (TimesOfDay) { etod="BED"[type="default"] }
// Weekend day, notice that not all the states are listed, the unlisted states are skipped
DateTime Weekend_Day (TimesOfDay) { channel="astro:sun:ihp:set#start", etod="DAY"[type="weekend"] }
DateTime Weekend_Evening (TimesOfDay) { channel="astro:sun:ihp:set#start", etod="EVENING"[type="weekend"] }
Screen shots are not all the helpful in general. If you have .items files just post those. However I can see that:
This means either the rule didn’t run or it didn’t trigger to run last night a little after midnight. The rule looks at the date for all the Items and if the date is for yesterday it advances the date to today. This also means that your attempts to initialize the Item were not successful. I’m pretty sure you don’t want BED, EVENING, and MORNING to happen a the same time.
Reinitialize the Items not linked to Astro to their proper times. Watch the logs to make sure you see the rule run. If it didn’t run trigger it manually.
When you say reinitalise, you mean set the times for example here:
After putting arbitrary numbers in those non linked items, i see this:
05:36:29.884 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - Today is a weekend day.
05:36:40.901 [INFO ] [core.model.script.Subfloor Humidity: ] - 98
05:36:59.953 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - The current time of day is DAY
05:37:02.196 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - Today is a weekend day.
^C~ openhab>
Its morning, not day…
Not according to your Items. Today is a weekend day and you’ve only two weekend Items, one for DAY and one for EVENING.
Right! Ok, added the new items, initalised and reran
05:51:00.466 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - Today is a weekend day.
05:51:00.608 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - Moved Weekend_Morning to today.
05:51:00.615 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - Moved Weekend_Night to today.
05:51:00.619 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - Moved Weekend_Bed to today.
05:51:30.626 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - The current time of day is MORNING
05:51:31.666 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - Today is a weekend day.
05:51:31.674 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - Moved Weekend_Morning to today.
05:51:31.682 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - Moved Weekend_Night to today.
05:51:31.684 [INFO ] [.openhab.model.script.Rules.TimeOfDay] - Moved Weekend_Bed to today.
Looks better Rich! Lets see tonight how that goes.
That reminds me I need to figure out why it runs twice. But the logs look good now. Hope it works tonight.
Thanks for your help! Ill report back
Rossko, the way I understand this, is if we have some items (DateTime) and we manually set their state in MainUI, which works as expected, then if we then create a persistance file (mapdb.persist) with the following for our item (Default_Morning) then we should always get the value upon a reboot
Default_Morning : strategy = restoreonStartup
Right? problem is, it doesnt persist across reboots. The items not linked to channels are again, NULL
Items:
DateTime Default_Morning (TimesOfDay) { etod="MORNING"[type="default"] }
DateTime Default_Night (TimesOfDay) { etod="NIGHT"[type="default"] }
DateTime Default_Bed (TimesOfDay) { etod="BED"[type="default"] }
DateTime Weekend_Day (TimesOfDay) { channel="astro:sun:ihp:set#start", etod="DAY"[type="weekend"] }
DateTime Weekend_Morning (TimesOfDay) { etod="MORNING"[type="weekend"] }
DateTime Weekend_Night (TimesOfDay) { etod="NIGHT"[type="weekend"] }
DateTime Weekend_Bed (TimesOfDay) { etod="BED"[type="weekend"] }
PERSIST
Default_Morning : strategy = restoreonStartup
Default_Day : strategy = restoreonStartup
Default_Night : strategy = restoreonStartup
Default_Bed : strategy = restoreonStartup
Weekend_Morning : strategy = restoreonStartup
Weekend_Day : strategy = restoreonStartup
Weekend_Evening : strategy = restoreonStartup
Weekend_Night : strategy = restoreonStartup
Weekend_Bed : strategy = restoreonStartup
That’s incomplete. You need to persist as well as restore, everyChange will suffice for that.
I think all this stuff is case sensitive too - restoreOnStartup with big O
None of this is within the scope of this thread.
Ok, thanks I’ll give that a go. Of course it’s within the scope, not persisting the values makes the script not run.
True but anything beyond mentioning that persistence is one way but by no means the only way to make sure the unlinked Items get a value after a reboot. And all of them are generic OH concepts. And for the must part none of the approches have changed since even I stayed using OH way break in certain 1.6.
Troubleshooting a .persist file is out of scope for this tutorial. We can’t convert every tutorial to cover every generic OH concept or capability built into OH.
Fair enough, it still appears despite the items being populated, the TimeOfDay item is not changing. Right now its 1.25PM and its showing morning still
These are my items:
String TimeOfDay "Current time of day [%s]"
// 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 (TimesOfDay) { etod="MORNING"[type="default"] }
DateTime Default_Day (TimesOfDay) { channel="astro:sun:ihp:set#start", etod="DAY"[type="default"] }
DateTime Default_Evening (TimesOfDay) { channel="astro:sun:ihp:set#start", etod="EVENING"[type="default"] }
DateTime Default_Night (TimesOfDay) { etod="NIGHT"[type="default"] }
DateTime Default_Bed (TimesOfDay) { etod="BED"[type="default"] }
// Weekend day, notice that not all the states are listed, the unlisted states are skipped
DateTime Weekend_Day (TimesOfDay) { channel="astro:sun:ihp:set#start", etod="DAY"[type="weekend"] }
DateTime Weekend_Evening (TimesOfDay) { channel="astro:sun:ihp:set#start", etod="EVENING"[type="weekend"] }
DateTime Weekend_Morning (TimesOfDay) { etod="MORNING"[type="weekend"] }
DateTime Weekend_Night (TimesOfDay) { etod="NIGHT"[type="weekend"] }
DateTime Weekend_Bed (TimesOfDay) { etod="BED"[type="weekend"] }
//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" }
Here you can see them populated
openhab> openhab:status TimeOfDay
MORNING
openhab>
Default_Day is showing 23/9/2021 (today), but at 5.50PM which seems odd. Evening and Day, default, also have 5.50pm
Empheris looks right
What’s the best way to troubleshoot this @rlkoshak ? Cheers
These Items are all linked to the same Astro channel. It follows they will all get updated to the same datetime (sunset).
Ah. I’ve used the example, so I’m not sure what else I should do? There was no mention of changing the items
