Ephemeris condition with offset not working in Rules in OH 3.1.0M5

Does anyone else use the Ephemeris offset config for a rule condition and notice that it does not work?

I configure the holiday rules but with an offset of -1 (previous day). I want to trigger an Ephemeris event the night before (I use it to trigger a sound to so the kid knows its bedtime, but if its a public holiday the following day he can stay up an hour later).

On Monday the 7th (June 2021) it is a public holiday, however I would expect the rule “Weekday” not “Holiday” to be displayed. I would expect “Holiday” if I had set no offset.

Maybe I misunderstand how the offset field works.

I have inspected the source code and I see when the day offset gets applied (target) and looking over the code it seems fine but maybe I am missing something…?

    public EphemerisConditionHandler(Condition condition, EphemerisManager ephemerisManager) {
        this.ephemerisManager = ephemerisManager;

        EphemerisConditionConfig config = getConfigAs(EphemerisConditionConfig.class);
        dayset = DAYSET_MODULE_TYPE_ID.equals(module.getTypeUID())
                ? getValidStringConfigParameter(config.dayset, module.getId())
                : null;
        target = ZonedDateTime.now().plusDays(config.offset);

    public boolean isSatisfied(Map<String, Object> inputs) {
        switch (module.getTypeUID()) {
            case HOLIDAY_MODULE_TYPE_ID:
                return ephemerisManager.isBankHoliday(target);
            case WEEKEND_MODULE_TYPE_ID:
                return ephemerisManager.isWeekend(target);
            case WEEKDAY_MODULE_TYPE_ID:
                return !ephemerisManager.isWeekend(target);
            case DAYSET_MODULE_TYPE_ID:
                final String dayset = this.dayset;
                if (dayset != null) {
                    return ephemerisManager.isInDayset(dayset, target);
        // If none of these conditions apply false is returned.
        return false;

Note: I am using OH 3.1.0 MS 5, so rules with ephemeris conditions show in the schedule.

The Schedule page in MainUI may not take full account of the Ephemeris offsets. I expect the problem is just in display and that the rules will actually execute as they are supposed to. Note that the UI’s code that populates the calendar is separate and independent of the code that actually schedules the rules to run.

I recommend waiting until the 7th and see if it runs as expected. If it does, file an issue on the web-uis repo. If not file an issue on openhab-core.

This is definitely is a bug. The target is initialized once in the constructor with a final value. The offset should be applied on the current timestamp every time the isSatisfied() method will be called. Will you submit a fix for it?



the responsibility for computing occurrences of scheduled rules has been largely moved to the backend i.e. OH Core.

1 Like

Yes, I will take care of PR and do some testing. Thanks Christoph and co.

Okay, so looking into it more I felt that isSatisfiedAt should be the one with the plusDays changes - making changes there vs the satisfiedAt reflects offsets.

Queens Birthday Public Holiday; 7th June 2021
Offset: -1

So it appears to be in the wrong “direction” (should be Sunday).

Looking at logging in the code I changed seems to be doing what expected with addDays:

15:46:54.373 [DEBUG] [ule.handler.EphemerisConditionHandler] - Ephemeris time 2021-06-07T19:00:00.549Z offset -1
15:46:54.377 [DEBUG] [ule.handler.EphemerisConditionHandler] - Offset time 2021-06-06T19:00:00.549Z

This was the JSON that was sent down for the schedule:

    "date": "Jun 7, 2021, 7:00:00 AM",
    "rule": {
      "triggers": [
          "id": "2",
          "configuration": {
            "properties": {
              "time": "19:00"
          "typeUID": "timer.TimeOfDayTrigger"
      "conditions": [
          "inputs": {},
          "id": "1",
          "configuration": {
            "properties": {
              "offset": 1
          "typeUID": "ephemeris.HolidayCondition"
      "actions": [],
      "configuration": {
        "properties": {}
      "configDescriptions": [],
      "uid": "5ac41fc1c5",
      "name": "5ac41fc1c5",
      "tags": [
      "visibility": "VISIBLE"

I also noticed at about midnight last night for most of the night with a 0 offset the Scheduled rule was appearing under the 8th June 2021, instead of 7th. This was occurring under both my main and test instances of OH. Maybe I have stumbled upon a bug or two relating to UTC and Local TZ.

Any thoughts?

Since you’re in NZ so GMT+12, this only makes sense if it’s supposed to be interpreted as UTC time instead of local time.

My server is not set to UTC time but the API response is not UTC in this case (the time in the date field matches the condition’s time):

    "date": "Jun 4, 2021, 5:00:00 PM",
    "rule": {
      "triggers": [
          "id": "1",
          "configuration": {
            "properties": {
              "time": "17:00"
          "typeUID": "timer.TimeOfDayTrigger"

What does date return on your server?

$ date
Fri 04 Jun 2021 12:55:16 PM CEST

Also this code seems wrong:

It seems to compare ISO Dates with local times and strip the timezone.
Please open a JS console on your server and try:

new Date("Jun 7, 2021, 7:00:00 AM").toISOString()

And the schedule has put the rule back under the 8th again, which makes sense based on all this.

Both my test and main server instances report (Debian 10 and Raspbian 10):

Sat 05 Jun 2021 08:57:10 AM NZST

Chrome Console

new Date("Jun 7, 2021, 7:00:00 AM").toISOString()

openHAB is running in docker containers


EXTRA_JAVA_OPTS	-Duser.timezone=Pacific/Auckland`



I’ll look at schedule.vue and fix that too.

That’s interesting, maybe you’ll want to remove that and try again.
I’m not saying it’s not a valuable option - just trying to figure out how many snafus we’re dealing with… if there’s only two they might annul themselves but here we might be looking at three :exploding_head:

I removed the environment var but it did not change the end result.

Offset fix for Ephemeris condition here: [automation] Ephemeris Offset fix by Cossey · Pull Request #2398 · openhab/openhab-core · GitHub

I will continue to investigate issue with Schedule but wanted this bugfix sorted now to get it in for the 3.1 release.

Ephemeris Issues Outstanding:

  • The offset is still going in the wrong direction (IE: -1 is adding day, 2 is removing 2 days), even though the isSatisfiedAt functions ZonedDateTime plusDays is getting passed the correct offset, and adding the correct date from Main UI. I could probably reverse the signed integer in isSatisfiedAt but that feels like a dirty fix.
  • The Schedule is still having a little trouble displaying the Rule under the correct date when its around midnight to midday. Myself being in GMT+12 it makes sense for it to be a Time Zoning problem, still working on this.

Just a follow up, haven’t had any time to work on the two above outstanding issues thanks to RealLife™. I don’t think I will have any time for a long while. I am hoping someone more experienced may have some time to take a look.

Some notes that may help:

  • Server and openHAB docker container are both set to correct timezone
  • Tried it with openHAB container not having timezone set, still no apparent change
  • Date is set via java opts -Duser.timezone=Pacific/Auckland and volume mapping /etc/localtime and /etc/timezone
  • Timezone is GMT+12 - Pacific/Auckland
  • Date in the schedule backend is being sent as a text formatted date instead of Linux epoch number
  • At midnight to midday GMT+12, all the ephemeris conditioned rules appear to be off by one day in the schedule view in Main UI.
  • Main UI Schedule tests were done in Chrome.
  • Confident that both issues are related in someway to time zoning.
  • Maybe a ZonedDateTime conversion or something that isn’t being converted or doing time zone conversions twice?
  • I can replicate this problem on both primary and test servers:
    • Main Server [HP EliteDesk 800 G5 SFF]: Debian 10; amd64; Docker 19.03.8
    • Test Server [Raspberry Pi 3B]: Debian 10 (HypriotOS); armv71; Docker 20.10.6