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.
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) {
super(condition);
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);
}
@Override
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);
}
break;
}
// 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?
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
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.
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
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