Time Based State Machine [3.2.0;3.4.9]

Add-on Marketplace Rule Templates
,
5

Hello. First of all, Rich…you are a wizard! Thank you SO MUCH for all your work here helping people. I and so many others really appreciate it.

I am having a heck of a time getting this to work. Your old version worked great until I upgraded to 3.2. Then it stopped working so I migrated to this addon.
I have my items in a .items file.

String      TimeOfDay        (gTimesOfDay)
DateTime    MorningNight     (gTimesOfDay)    {channel="astro:sun:local:morningNight#start", etod="MORNING_NIGHT"[type="default"]}
DateTime    AstroDawn        (gTimesOfDay)    {channel="astro:sun:local:astroDawn#start", etod="ASTRO_DAWN"[type="default"]}

Note: I have setup the new addon using 'etod", “TimeOfDay”, and “gTimesOfDay”, and I have more entries similar to the ones above.

The error I get is:

[ERROR] [.internal.handler.ScriptActionHandler] - Script execution of rule with UID 'TimesOfDay_Addon' failed: TimeOfDay lacks metadata or metadata value.
Invalid metadata for Item! Expected metadata in the form of etod="STATE"[type="daytype", set="dayset", file="uri"] where set is required if type is dayset and file is required if type is custom. in <eval> at line number 336 at column number 6

My items file looks ok to me, any ideas on where the error could be?

Thanks
Craig
ver 3.2.0

6

The TimeOfDay Item shouldn’t be a member of gTimesOfDay. The rule expects that all members of gTimesOfDay to have proper etod metadata and TimeOfDay doesn’t (and shouldn’t since it doesn’t represent the start of a time of day.

This should have always caused an error so I can’t say why it worked before. It should never have worked.

7

Thanks Rich. I think I know what happend. Before I upgraded OH, I added TimeOfDay to the group because I wanted it to show up in the model grouped into what I call “Boiler Room”. It probably broke then but I never realized it until I upgraded.

It’s all fixed now. Thanks for your time. If you ever come to Vancouver, Canada, Beer’s on me!

Craig

9

I am getting this warning:

[emeris.internal.EphemerisManagerImpl] - This dayset is not configured : trash

Is this a problem? And if so, how do I configure trash?

TIA,
James

10

Well, if you just copied the examples above without really understanding them I’m not surprised. The examples are just that, a set of examples. It’s not nor are they intended to be a complete and comprehensive configuration.

Do you have a special set of times of day for trash day? Do you even care about trash day? If not, then why configure one of your Items to use a custom dayset? If you don’t care about having a special set of times of day for trash day, get rid of those Items or at least that metadata for trash day. If you do, see Actions | openHAB for instructions on how to define a custom dayset for trash day.

If you are lost and don’t understand what any of those Items and their metadata do or mean, reread the top post with the understanding that the examples are exemplars. Default_Bed shows how to set the metadata for a Default time of day. Weekend_Evening shows how to set the metadata for a weekend dayset, Trash_Morning shows how to set the metadata for a custom dayset (you have to define the custom dayset your self) and Birthday_DAY shows how to set the metadata for a custom holiday (you have to define the custom holiday yourself).

If this approach is still too hard to follow and set up there is a simpler way. See Creating Capabilities with Rule Templates: Time of Day. ,That approach is much simpler but somewhat less capable.

11

Despite reading this article multiple times I had quite a hard time to get this working. Since I never used a template from the automation store before I had even more questions. Here all struggles I went through:

  1. You can add tags (e.g. totd to get “To Today” working) in textual config too (see example below)
  2. Example of a item holding the time of day and a group definition
Group:DateTime TimesOfDay
String TimeOfDay "Current time of day [%s]"

DateTime Default_Morning (TimesOfDay) { channel="astro:sun:local:rise#start", tod_sm="MORNING"[type="default"] }
DateTime Default_Day (TimesOfDay) { channel="astro:sun:local:rise#end", tod_sm="DAY"[type="default"] }
DateTime Default_Afternoon (TimesOfDay) ["totd"] { init="13:00:00", tod_sm="AFTERNOON"[type="default"] }
DateTime Default_Evening (TimesOfDay) { channel="astro:sun:local:set#start", tod_sm="EVENING"[type="default"] }
DateTime Default_Night (TimesOfDay) ["totd"] { init="22:00:00", tod_sm="NIGHT"[type="default"] }
DateTime Default_Bed (TimesOfDay) ["totd"] { init="23:00:00", tod_sm="BED"[type="default"] }

  1. As advised I installed “To Today” from automation store to update actual date on the static items. Trouble is that you need to set a time on your static items otherwise they are ignored by the “to today” rule.
    → Question: I thought init="23:00:00" would do that job but it doesn’t work for me. So I did it over the console (e.g. openhab> openhab:send Default_Bed "23:00:00").

  2. It was not clear to me that I need to manually add a rule in order to trigger the state machine. Retrospective is it clear but adding this step under initial setup would make it clear from the beginning.

12

Yes, a tag is a tag no matter how the Item is defined. See Items | openHAB for the parts of the docs that talk about tags.

I assumed that creating a String Item and a Group Item was basic enough not to need an example. Eventually I plan on making the rule template create at least the String Item and possibly the Group Item too. But I’m also probably going to only show UI examples goring forward.

If that exists anywhere here or in the ToToday then I need to know about that to correct it. If you are just remembering that init metadata from older versions of the Time of Day implementations, I no longer support that feature. There are so many good ways to initialize the state of an Item, including Date Time pickers you can put on MainUI, that there is no need for an init feature like there was in OH 2.x.

I do have a whole section above that talks about how to initialize the DateTime Items. Time Based State Machine [3.2.0;3.4.9] which includes links to these widgets as well as discusses initializing the Item in various other ways.

If it’s not clear that To Today is something you would need in addition to initializing the Item I’m open to suggestions to make that more clear.

This is all covered in the Getting Started Tutorial and will be covered in more depth in updates to the rules section of the docs which are in work. It should not be the responsibility of individual rule templates to document the generic stuff that’s true for all rule templates.

13

@rlkoshak Thanks for sharing your great work - the state machine works just great (as the previous rule based version did). However also the new solution does not support one of my scenarios when Day-Morning or Evening-Night times overlap over the course of the year. Example: Morning time is fixed to 6:45 - Sunrise is set by astro binding, today it was around 6:30. This results in having all day tod=morning.

grafik
grafik950×397 22.5 KB

My expected result (wish!) would be to skip “Morning” if the day starts earlier, or with other words the squence of ToDs should always be the same.

Having read the documentation multiple times I don’t think this is supported or easy to be implemented.

Assuming that I am maybe not the only one with this issue, is there an suggested solution?

Thanks so much in advance
Christian

14

This. It’s not easy to support. All the rule sees and knows is that you have a bunch of Items and each Item has a DateTime. It puts those in order and schedules the timers. It has no concept that MORNING should normally happen before DAY.

However, all is not lost. You have some options depending on where the DateTime in Morning and Day comes from.

  1. Set a no earlier than in the Sunrise channel to something later than the static start for MORNING. So if you set that, no matter what the sun is doing, sunrise will never be earlier than 6:46 AM (for example).

  2. My MORNING is actually driven by the alarm clock on my phone. When it’s set it triggers a rule (using the Alarm Clock rule template for now, but you should use the new Time is <item> trigger). The rule checks to see if it’s NIGHT or BED and only if so does it run and set the TimeOfDay Item to MORNING. On weekends and days where I don’t need to get up, no alarm is set and those days do not have MORNING state.

  3. You can modify the rule and make it smarter. Add some if statements that look to see if DAY actually occurs before MORNING and adjust the times as appropriate. But that’s something that will be unique to you and can’t be something I can make generic. You could even put this into a separate rule that checks the DateTimes sometime after the rule runs at midnight and adjusts the times as necessary. Changing the DateTimes will cause the rule to run again and reschedule the Timers.

Tl;dr, it’s up to you to make sure the DateTimes are in the order you require, but there are options to make sure that’s the case that are not too onerous.

1 Like
15

Awesome, thanks for the comprehensive answer and providing even 3 different approaches. I wasn’t aware that I can set a earliest/latest for the astro binding, whichdoes the trick for me and is so simple to implement!

Thanks again!

16

I hate to pollute this thread with a support request (please lmk if there is a more appropriate venue and I’ll happily redirect!), but I was hoping someone may be able to offer some insight. My TOD setup has been working rather well, until I noticed the following (that I had not seen in the couple of weeks I have been using my current TOD config) happen tonight:

2022-11-02 21:00:00.005 [INFO ] [del.script.Rules.rules_tools.Time_SM] - Transitioning Time of Day from EVENING to NIGHT
2022-11-03 00:00:00.582 [INFO ] [del.script.Rules.rules_tools.Time_SM] - Today is a default day.
2022-11-03 00:01:00.695 [INFO ] [del.script.Rules.rules_tools.Time_SM] - The current time of day is DAY

(at which point TimeOfDay became DAY, and triggered my script that turned lights on)

This is incredibly odd to me (and somewhat unfortunate, because it resulted in the bedroom lights turning on while my sick partner was asleep! :/), because normally 00:01:00.695 would not correspond to DAY, and there was no “Transitioning” message in the log, just a state change. Looking back through my event logs, this seems to be the first time this has happened out of ~two weeks of logs, so I am somewhat doubtful that it is mis-configuration on my part (though I would always be happy to learn it is!). I’m not aware of anything in my config changing recently related to TOD.

openhab> items list Default*
Default_Bed (Type=DateTimeItem, State=2022-11-02T00:05:00.000-0700, Label=null, Category=null, Tags=[totd], Groups=[TimesOfDay])
Default_Day (Type=DateTimeItem, State=2022-11-02T09:30:00.000-0700, Label=null, Category=null, Tags=[totd], Groups=[TimesOfDay])
Default_Morning (Type=DateTimeItem, State=2022-11-03T08:10:00.000-0700, Label=null, Category=null, Groups=[TimesOfDay])
Default_Night (Type=DateTimeItem, State=2022-11-03T21:00:00.000-0700, Label=null, Category=null, Tags=[totd], Groups=[TimesOfDay])
Default_Evening (Type=DateTimeItem, State=2022-11-03T18:10:00.000-0700, Label=null, Category=null, Groups=[TimesOfDay])

Where would you look to debug this infrequent problem? I would not expect that createTimersGenerator() would events.sendCommand(), but it does. I’ll enable debug on that module, but if you have any guesses on where to look I’ll happily poke at it. :slight_smile: Upon entry, mostRecentState would have been NIGHT according to my event log, which means that it hit if(dt.isBefore(now) && dt.isAfter(mostRecentTime)) {}.

Debug context: openhab 3.3.0 in a docker container on ARM, javascript is marketplace:128245 (I’m unsure if this auto-updates, but I set this up on 10/20 and haven’t touched it since).

17

That’s what this thread is for.

I probably won’t be able to help much without more information. Either modify your log4j2.xml file or the karaf console to add a logger for org.openhab.automation.script.Rules.rules_tools set to DEBUG level logging or modify the rule itself and change all the log debug statements to log infos. Then post the debug logs from the rule when this behavior occurs.

For some reason, the part of the code that schedules the timers for the next day scheduled the DAY timer to one minute after midnight. Without knowing what the state of that DateTime Item was at the time the rule ran I couldn’t guess as to what went wrong.

It might help a bit to see the events.log showing which of your DateTime Items changed and when they changed in relation to when the state changed to DAY. It might be a timing issue where the rule ran in response to an event from Astro (for example) before To Today was able to update the DAY Item, meaning it was still scheduled for yesterday and ran immediately. I’ve never seen that before but it makes sense logically.

If that is the case I can add some logic to prevent that. But I need more details to know if that’s the case.

It doesn’t. But I’ve not modified the template since February of this year so you should have the latest.

To upgrade you need to remove the template, add it again, and then delete and recreate the rule(s) instantiated from the template.

18

Thanks, Rich. I always appreciate the support I see you give. I enabled debug on org.openhab.automation.script.Rules.rules_tools.Time_SM, so hopefully I’ll catch a hint later.

At 00:00, I see my hard-coded times rolled forward to the next day via marketplace:127921.
I also see my *_Morning and *_Evening times updated (Astro; the others are manually set).

I give the earliest event of the day (00:05) a several-minute buffer after time rolls forward to hopefully avoid any race condition.

I left one non-TOD entry in my event log here for fun: I came home right around midnight and triggered my motion sensor, the clear event happening at the very same second that the DAY command was issued, but it was SURELY a complete coincidence. :slight_smile: (There are no rules tied to it currently - just a note in the event log.) I don’t see any more hints here.

2022-11-03 00:00:00.009 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Holiday_Bed' changed from 2022-11-02T02:00:00.000-0700 to 2022-11-03T02:00:00.000-0700
2022-11-03 00:00:00.025 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Night' changed from 2022-11-02T21:00:00.000-0700 to 2022-11-03T21:00:00.000-0700
2022-11-03 00:00:00.027 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Weekend_Bed' changed from 2022-11-02T02:00:00.000-0700 to 2022-11-03T02:00:00.000-0700
2022-11-03 00:00:00.028 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Holiday_Night' changed from 2022-11-02T22:00:00.000-0700 to 2022-11-03T22:00:00.000-0700
2022-11-03 00:00:00.052 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Weekend_Day' changed from 2022-11-02T11:00:00.000-0700 to 2022-11-03T11:00:00.000-0700
2022-11-03 00:00:00.060 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Holiday_Day' changed from 2022-11-02T11:00:00.000-0700 to 2022-11-03T11:00:00.000-0700
2022-11-03 00:00:00.062 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Weekend_Night' changed from 2022-11-02T22:00:00.000-0700 to 2022-11-03T22:00:00.000-0700
2022-11-03 00:00:30.125 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Holiday_Morning' changed from 2022-11-02T08:09:00.000-0700 to 2022-11-03T08:10:00.000-0700
2022-11-03 00:00:30.136 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Weekend_Morning' changed from 2022-11-02T08:09:00.000-0700 to 2022-11-03T08:10:00.000-0700
2022-11-03 00:00:30.137 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Morning' changed from 2022-11-02T08:09:00.000-0700 to 2022-11-03T08:10:00.000-0700
2022-11-03 00:00:30.139 [INFO ] [openhab.event.ChannelTriggeredEvent ] - astro:sun:local:morningNight#event triggered START
2022-11-03 00:00:30.140 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Holiday_Evening' changed from 2022-11-02T18:11:00.000-0700 to 2022-11-03T18:10:00.000-0700
2022-11-03 00:00:30.141 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Evening' changed from 2022-11-02T18:11:00.000-0700 to 2022-11-03T18:10:00.000-0700
2022-11-03 00:00:30.143 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Weekend_Evening' changed from 2022-11-02T18:11:00.000-0700 to 2022-11-03T18:10:00.000-0700
2022-11-03 00:01:00.213 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'F1_LivingRoom_multisensor_Motion' changed from ON to OFF
2022-11-03 00:01:00.756 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'TimeOfDay' received command DAY
19

Ok, that’s weird.

First, please use code fences for logs.

```
code/logs/configs go here
```

Here is what I see.

  • 9 msec after midnight the To Today rule starts updating the time of Day Items. This will trigger the Time Of Day rule
  • It takes about half a second for that first trigger to get to the point where it’s calculated what type of day it is. During all this time the many triggers caused by the To Today rule are queueing up. A 30 second timer is created to wait for all these updates to finish happening before calculating the time of day.
  • The Time of Day rule is triggered 6 more times from the To Today but because the timer exists, it’s just rescheduled. The Items updates are:
    • Holiday_Bed
    • Default_Night
    • Weekend_Bed
    • Holiday_Night
    • Weekend_Day
    • Holiday_Day
    • Weekend_Night
  • At 30 seconds after midnight Astro kicks in and calculates the next day’s date times. The timer still exists in the Time of Day Rule so the timer gets rescheduled. The Items updated by Astro are:
    • Holiday_Morning
    • Weekend_Morning
    • Default_Morning
    • Holiday_Evening
    • Default_Evening
    • Weekend_Evening
  • About one minute after midnight the timer finally expires and calculates the time of day as DAY.

Notice anything missing? Default_Day was never updated. So it still had the previous date which was in the past and therefore it was the earliest date time found by the rule.

So the problem isn’t the Time of Day rule, it’s the To Today rule (I assume). Why wasn’t Default_Day updated? Does it still have the “tod” tag (given its state I’m assuming it’s not driven by Astro) or is it driven by something else that To Today?

Looking at the states you posted above, indeed, both Default_Bed and Default_Day have yesterday’s date. So what ever is supposed to update those two Items (perhaps others) is not working.

Put the To Today rule into DEBUG logging too (assuming these rules are usually driven by To Today). That’s where the problem lies.

I might be able to put a check for date times that are the previous day. But I don’t know what’s appropriate to do in that case, ignore it? I’m not sure that’s right.

20

re code fences: thanks - that’s what I was looking for! That’s what I get for posting after midnight! Fixed.

Wow, good eye! I didn’t notice the absence of Default_Day. I just confirmed that Default_Day has the same (sole) tag as Default_Night (which, as you saw, did get moved). I’ll definitely look at the rollover script more closely now. Funny that this has worked so well every other day:

cat /usr/local/openhab/userdata/logs/events.log | grep Default_Day
2022-10-20 16:24:18.351 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from NULL to 2022-10-20T09:30:00.000-0700
2022-10-21 00:00:03.729 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-20T09:30:00.000-0700 to 2022-10-21T09:30:00.000-0700
2022-10-22 00:00:00.596 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-21T09:30:00.000-0700 to 2022-10-22T09:30:00.000-0700
2022-10-23 00:00:00.488 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-22T09:30:00.000-0700 to 2022-10-23T09:30:00.000-0700
2022-10-24 00:00:00.485 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-23T09:30:00.000-0700 to 2022-10-24T09:30:00.000-0700
2022-10-25 00:00:00.480 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-24T09:30:00.000-0700 to 2022-10-25T09:30:00.000-0700
2022-10-26 00:00:00.473 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-25T09:30:00.000-0700 to 2022-10-26T09:30:00.000-0700
2022-10-27 00:00:00.548 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-26T09:30:00.000-0700 to 2022-10-27T09:30:00.000-0700
2022-10-28 00:00:00.524 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-27T09:30:00.000-0700 to 2022-10-28T09:30:00.000-0700
2022-10-29 00:00:00.475 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-28T09:30:00.000-0700 to 2022-10-29T09:30:00.000-0700
2022-10-30 00:00:00.613 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-29T09:30:00.000-0700 to 2022-10-30T09:30:00.000-0700
2022-10-31 00:00:00.572 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-30T09:30:00.000-0700 to 2022-10-31T09:30:00.000-0700
2022-11-01 00:00:00.504 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-10-31T09:30:00.000-0700 to 2022-11-01T09:30:00.000-0700
2022-11-02 00:00:00.471 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Default_Day' changed from 2022-11-01T09:30:00.000-0700 to 2022-11-02T09:30:00.000-0700

Somewhat unrelated, is it normal to have spaces embedded in the namespace like this?
.getLogger(“org.openhab.model.script.rules_tools.To Today”)

21

It doesn’t matter one way or the other. I don’t know if it’s normal but it doesn’t cause any problems.

22

I’m late to the party here, I know.
I’ve been doing a lot of digging around - both on this thread and the one for OH4+, in addition to looking around at the ToToday automation.
I am having a difficult time understanding how the Time and Date Machine processes the objects.

My items file is:

String TimeOfDay "Current Time of Day [MAP(weather.map):%s]" <tod>   // weather.map has mapping from caps to lowercase for times of Day

Group TimesOfDay

DateTime DefaultMorning "Default Morning"  <time>  (TimesOfDay) ["DTUpdate"] { tod_sm="MORNING" [type="default"] }
DateTime DefaultDay "Default Day"  <sunrise>  (TimesOfDay) { channel="astro:sun:local:rise#end", tod_sm="DAY" [type="default"] }
DateTime DefaultTwilight "Default Twilight"  <sunset>  (TimesOfDay) { channel="astro:sun:local:set#start", tod_sm="TWILIGHT" [type="default"] }
DateTime DefaultEvening "Default Evening"  <time>  (TimesOfDay) ["DTUpdate"] { tod_sm="EVENING"[type="default"] }
DateTime DefaultNight "Default Night"  <moon>  (TimesOfDay) ["DTUpdate"] { tod_sm="NIGHT"[type="default"] }

DateTime WeekdayMorning "Weekday Morning"  <time>  (TimesOfDay) ["DTUpdate"] { tod_sm="MORNING" [type="weekday"] }
DateTime WeekdayDay "Weekday Day"  <sunrise>  (TimesOfDay) { channel="astro:sun:local:rise#end", tod_sm="DAY" [type="weekday"] }
DateTime WeekdayTwilight "Weekday Twilight"  <sunset>  (TimesOfDay) { channel="astro:sun:local:set#start", tod_sm="TWILIGHT" [type="weekday"] }
DateTime WeekdayEvening "Weekday Evening"  <time>  (TimesOfDay) ["DTUpdate"] { tod_sm="EVENING"[type="weekday"] }
DateTime WeekdayNight "Weekday Night"  <moon>  (TimesOfDay) ["DTUpdate"] { tod_sm="NIGHT"[type="weekday"] }

DateTime WeekendMorning "Weekend Morning"  <time>  (TimesOfDay) ["DTUpdate"] { tod_sm="MORNING" [type="weekend"] }
DateTime WeekendDay "Weekend Day"  <sunrise>  (TimesOfDay) { channel="astro:sun:local:rise#end", tod_sm="DAY" [type="weekend"] }
DateTime WeekendTwilight "Weekend Twilight"  <sunset>  (TimesOfDay) { channel="astro:sun:local:set#start", tod_sm="TWILIGHT" [type="weekend"] }
DateTime WeekendEvening "Weekend Evening"  <time>  (TimesOfDay) ["DTUpdate"] { tod_sm="EVENING"[type="weekend"] }
DateTime WeekendNight "Weekend Night"  <moon>  (TimesOfDay) ["DTUpdate"] { tod_sm="NIGHT"[type="weekend"] }

DateTime HolidayMorning "Holiday Morning"  <time>  (TimesOfDay) ["DTUpdate"] { tod_sm="MORNING" [type="holiday"] }
DateTime HolidayDay "Holiday Day"  <sunrise>  (TimesOfDay) { channel="astro:sun:local:rise#end", tod_sm="DAY" [type="holiday"] }
DateTime HolidayTwilight "Holiday Twilight"  <sunset>  (TimesOfDay) { channel="astro:sun:local:set#start", tod_sm="TWILIGHT" [type="holiday"] }
DateTime HolidayEvening "Holiday Evening"  <time>  (TimesOfDay) ["DTUpdate"] { tod_sm="EVENING"[type="holiday"] }
DateTime HolidayNight "Holiday Night"  <moon>  (TimesOfDay) ["DTUpdate"] { tod_sm="NIGHT"[type="holiday"] }

(the weather.map reference is one that changes lowercase to upper case for the times of day)

I no longer am using the TOD.rules I had in older versions, and have installed the Time Based State Machine for my OH 3.4.2 installation.
I have installed ToToday, for the item tag DTUpdate.
I installed standalone Date and Time Widgets, and have set all the values of the non-astro DateTIme items.

When the day switches over to a weekend, what happens? Does the default item override everything? What happens to the default/weekday, default/weekend, default/holiday, or weekday/holiday conflicts that can occur? (I have my regionalization set up in Ephemeris). Does ToToday blindly move all my holiday start times over to the next non-holiday?
Can I, without further modification, use rules triggered by receiving ‘MORNING’ to do my usual morning things, with the actual time varying by weekday/weekend/holiday parameters?

I haven’t found the answer to this in my reading, although I may have gone cross-eyed a couple times.
Without an exposed dsl rule file that I can tweak, it’s hard to know what happens under the surface.

Thanks
Ben
OH 3.4.2 on a RPi4 running Openhabian

23

At a high level the rule gets triggered a little after midnight and waits a little because it gets triggered multiple times as To Today and Astro and others change the states of the Items.

When the changes stop the rule runs.

First it looks to see what types of day it is using Ephemeris. I say “types” because it could be more than one (e.g. a holiday and a weekend). Then it looks to see if there is a set of items for that day type and use the first one it finds.

It looks in this order: custom, holiday, custom day type, weekend, weekday, default.

No, it’s what is used if none of the others apply.

If you have a set of items for holiday, weekend and default and not one for weekdays (for example), if today is a holiday no matter what other type of day it is the holiday set will be used. Only if there is no set of items for the type of day is the default set used.

And again, the type of day is determined by Ephemeris.

To Today blindly moves those date time items tagged to today’s date (with some extra stuff to properly handle DST changes). It knows nothing about holidays, weekdays or anything to do with Ephemeris and it doesn’t need to. They are completely separate and irrelevant to To Today. Only those Items that are not already updated daily should be tagged for To Today to process.

Ephemeris is used only by this rule to pick which set of date time items to use for today’s state machine.

That’s the whole point of this rule template. Set a different set of Items for default, weekend, and holiday. If it’s a holiday that set of Items are used, even if it’s also a weekend. If it’s a weekend and not a holiday, the weekend set of Items are used. If it’s neither a holiday nor a weekend the default Items are used.

It’s not hidden. It’s not Rules DSL but all the code is there (in this case it’s Nashorn JS). Click on the Link to the source code at the bottom of the first link and you’ll see the raw voice. Or once you instantiate the rule from the template you can inspect and modify the code like any other rule.

Note that the 4.0 version of the template is rewritten in the newer JS and only looks at the time part of the Items so there is no more need for To Today.

24

Thank-you for your many detailed clarifications.

The one missing piece for me that I had been oblivious to was that after installing the Time Based State Machine, I had to add the rule template from Rules (First time doing this for me). Once I saw it was an option there, I added it, and it started to update all the DateTIme items as I expected it.
I am not sure how common this sort of oversight is, but it may be of benefit to add the step ‘and then add the rule’ to the instructions. Now that I’ve started to use these pre-made rule templates, I’ll certainly know to do it in the future.

Thanks again.

25

This is covered in Getting Started: https://www.openhab.org/docs/tutorial/rules_basic.html#rule-templates and somewhat in the Ruels Concetps page: https://www.openhab.org/docs/concepts/rules.html#rule-templates. It doesn’t make sense to duplicate this generic “how to use OH” in each and every rule template posting. That’s a whole lot of duplicated documentation that could be a real problem if the way to install and instantiate a rule from a template ever changes.