Time Based State Machine [3.2.0;3.4.9]


Note, sometime in the first half of 2023 this template will be adjusted to only support JS Scripting and depend on the openhab_rule_tools library.

Home automation often follows a set cycle or states. In the morning the house needs to wake up and come alive as the inhabitants get ready for the day. Next the house should go to sleep a bit while everyone begins the work day. Later in the afternoon the house may wake up again to prepare for everyone’s return and so on.

There are a number of ways to define such states but a common approach is to use times of day. This rule template establishes a rule that uses DateTime Items to drive a state machine. A different set of DateTime Items can be defined for different types of days (e.g. one set for workdays, another for weekends, and a third for holidays) with Ephemeris used to choose between the sets of DateTime Items for a given day.

How it Works

Initial Setup

  • The user creates a String Item to hold the current time of day state. For this documentation we’ll call it “TimeOfDay” but you can choose any name.

  • The user creates a Group Item to hold all the DateTime Items that drive the state machine. For this documentation we’ll call it “TimesOfDay” but you can choose any name.

  • The user creates one or more sets of DateTime Items. Each Item is populated with the start time for the time of day state that Item represents. For example, a DateTime Item that represents MORNING might be populated from the Android App’s Alarm Clock feature or Astro’s sunrise time or hard coded to 07:00.

  • Each of those Items must have metadata defined on them. See below for details. This Item metadata is used to identify which type of day the Item belongs to and what time of day state it represents the start of.

  • Each of those Item are also made direct members of the TimesOfDay Group.

  • All the members of TimesOfDay need to be configured with Persistence for restoreOnStartup.


Each DateTime Item requires Item metadata. The namespace can be defined by you. For this documentation we will use “tod_sm”.

// Item metadata defined in .items files
tod_sm="<STATE>"[type="<daytype>", set="<dayset>", file="<uri>"]

// Item metadata defined in the UI
value: <STATE>
  type: <daytype>
  set: <dayset>
  file: <uri>

Replace this with the string you want sent to TimeOfDay at the DateTime held by this Item. The string will be sent as a command but only if it is different from the current state of TimeOfDay.

The rule supports six types of days as defined by Ephemeris.

Type Purpose
custom When custom holidays are defined in an XML file (see the Ephemeris docs) use custom for the type and the file parameter is required.
holiday When configure with country and region in MainUI (Settings → Ephemeris), Ephemeris will become preconfigured with the national holidays observed by that region.
dayset Ephemeris allows for the definition of a custom dayset, such as defining “trash_day” to occur every Monday. When used as the type, the set parameter is required.
weekend For the days defined as weekend in the Ephemeris configuration.
weekday For the days not defined as weekend in the Ephemeris configuration.
default If Ephemeris doesn’t match any of the above day types or if there is no set of DateTime Items defined for any of the above types this set of DateTime Items is used.

The day types are processed in the order presented above. For example, if Ephemeris says today is a holiday, that set of DateTimes will be used even if today is also a weekend and there is a set of DateTimes for that also.

Replace <dayset> withe the custom named dayset defined in the Ephemeris config to use. This parameter is only required when the type is dayset and should be absent in all other cases.

Replace <uri> with the full path to the custom Ephemeris XML file with the custom holidays defined. This parameter is only required when the type is custom and should be absent in all other cases.

The following are for illustrative purposes, they must be customized for your configuration.

// .items files examples
DateTime Default_Bed (TimesOfDay) { tod_sm="BED"[type="default"] }
DateTime Weekend_Evening (TimesOfDay { channel="astro:sun:local:set#start", tod_sm="EVENING"[type="weekend"] }
DateTime Trash_Morning (TimesOfDay) { tod_sm="MORNING"[type="dayset", set="trash"] }
DateTime Birthday_DAY (TimesOfDay) { tod_sm="DAY"[type="custom", file="/etc/openhab/service/birthdays.xml"] }

// UI Metadata
value: BED
  type: default

value: EVENING
  type: weekend

value: MORNING
  type: dayset
  set: trash

value: DAY
  type: custom
  file: /etc/openhab/service/birthdays.xml

Item Sets

At a minimum there should be a set of DateTime Items defined for default type days. This will be the sets of states and times used when no other sets are found for the current day type. You might stop with just the default sets of Items. However, if that is your plan, see Creating Capabilities with Rule Templates: Time of Day for a simpler approach to this rule.

The states for each day type can be unique and there can be a completely separate set of start times for each day type.

The rule does not support reusing the same DateTime Item for more than one day type though.

Populating the DateTime Items

Actually populating and managing the DateTime states of the Items is outside the scope of this rule. Options include:

  • Astro binding based on solar or lunar events.
  • iCal and similar bindings that can define start times.
  • Android app’s Alarm Clock option that publishes the next scheduled Alarm to an Item.
  • Populated by hand via the REST API, the karaf console, or a widget (see DateTime Standalone Widget and DateTime List Item which can be installed from the marketplace)
  • A more advanced timeline picker widget such as Timeline which can be installed from the marketplace.
  • Populated from a Rule.

If using hand populated times, install and configure To Today [3.2.0;3.4.9) to move those DateTime Item’s date to today at midnight.

NOTE: The rule triggers based on changes to these Items. If the Items are not changed to the current day the rule will not trigger and the state machine will stop.

What the Rule Does

Whenever one of the members of TimesOfDay changes its state or openHAB restarts the rule triggers.

The rule first determines what type of day it is. Then it selects those DateTime Items that are for that day type (if no Items exists the “default” set is chosen). Next it determines what the current time of day is based on the times defined on the selected Items, commanding TimeOfDay if the current state is different from the state in TimeOfDay. Finally, for any DateTimes that are in the future, a Timer is created to transition TimeOfDay to that state at that time.

DateTime Items with invalid metadata generate an error. Items with a NULL or UNDEF state are ignored.

Language: Nashorn JavaScript or JSScripting


  • A TimeOfDay String Item
  • A TimesOfDay Group
  • Sets of DateTime Items who are members of the TimesOfDay Group and have valid Item metadata.
  • in OH 4 the Nashorn library needs to be installed separately or change the type of the script to application/javascript;version=ECMAScript-2021 to use JS Scripting.


Version 0.3

  • adjusted for breaking change, will no longer work for versions of OH prior to December 15th

Version 0.2

  • Made compatible with both Nashorn and JSScripting
  • NOTE: Sometime after the release of OH 3.2 I will make this template only work with JSScripting so I can take advantage of the helper library.

Version 0.1

  • initial release




Love your work! I was trying to install this rule template but it seems it is linked to debounce on GitHub instead of Time of Day? Perhaps I’m wrong but could you adjust this? Thanks!

Doh! I refactored my repo and must have messed the link up. I’ll fix is shortly. Fixed. Now I need to go make sure I didn’t mess up my other templates the same way.

Thanks for reporting this!

Works great again! Thanks.

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?

ver 3.2.0

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.

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!


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?


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.

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.

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.

@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.

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

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

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!

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).

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.

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

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.

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”)

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