Thx @rlkoshak for your answer. I understand now the difference and I’m also think that the JavaScript/Python versions are better, despite the “old feature” I miss. I’m going to test it with the Astro binding as you said.
Keep up the good work 
Long ago. No replies there nor a fix.
Does that happen to you, too, or is it just me?
It’s all volunteer effort. Filing an issue is no guarantee that the issue will be fixed. Someone must volunteer their time to fix it. And if it’s a problem that is difficult to reproduce, or the issue doesn’t have enough detail for the developer to reproduce, it may never get fixed.
Sometimes you can sweeten the pot by filing a bounty source on the issue. Sometimes a little bit of money will help convince someone to fix an issue or implement a feature request.
But at this point you’ve done your part and that’s about all you can to.
Sorry, that’s not what I meant.
I just wondered if your Ephemeris settings also get screwed up when you restart openhab.
Oh, no. I’ve not had any problems with Ephemeris. Though I’ve only defined weekdays/weekends and my location to get holidays.
1 Like
Strange. It’s the location that gets deleted every time, and that prevents the script from running.
Do you know if I can define that in a config file somewhere in OH3?
I’m sure there is but I’ve never looked into that. Probably ephemeris.cfg. You can set it and then look in /var/lib/openhab/config/org/openhab/ for the ephemeris.config file and see what the cfg file should include.
One thing though that is important is always select from the list, don’t type in a region. If there is no drop down (e.g. there is no city options for my region) don’t enter anything.
That’s the thing, after a restart the dropdown is empty.
I’ll have a look at the config file. Maybe that cures it.
No. You’re not alone. I see the same. Every time I restart openHAB I have to re-select the country …
Curious to hear the results…
Would you share the link to the issue? Were not able to find it…
There wasn’t a config file for ephemeris, and creating one didn’t change anything, so that wasn’t the answer. I currently rely on the DSL version of the script, which does not use ephemeris, so that’s currently working for me.
The issue I opened was this: OH3.0.0: Ephemeris losing entered data on restart · Issue #2024 · openhab/openhab-core · GitHub
No replies or activity, though.
1 Like
I need help with my Time Of Day rule. Ever since the day lights savings change on Sunday my times of day that are based on specific time of day (5:00am & 10:00pm) are running 1 hour late. I tried to update them with a rule and also rebooted. The time shown in the Openhab3 log viewer is correct. Not sure how to fix it. Any help would be appreciated.
Which version of the rule? Show the logs from when the rule runs and when the transition between times of day occur. Put the rule into debug logging, or modify the debug logs to info so we can get more details about what is going on.
If you use the JS rule, maybe the country in ephemeris is not set correctly? Like to a country that’s in the same time zone but has not switched over to DST?
I’m using the rule with the script you created. I have the country in ephemeris set to U.S. . I ended up just changing the times on times of day. Changed 5am to 4am and 10pm to 9pm. The rule now goes off on time, at least until the fall comes.
I’ve posted three different versions in the original post. One in Rules DSL, one in Jython, and one in JavaScript. Which one?
Rich,
interesting fact: I run both the DSL and the JS rule, and just noticed that the JS rule now is an hour off, while the DSL rule (the improved one that was posted by someone else a few months ago) works correctly.
So I’d say he’s using the JS rule.
Can you gather some debug logs for me to look at? Also, check your Items, particularly your “hard coded” Items. Perhaps the logic that moves those forward to the next day didn’t account for the time change. I’ll also look at my own but I’ve not noticed any problems.
Now that you mention it, it looks rather strange.
All fixed items (I wouldn’t call them hardcoded) have shifted an hour, but show a different time offset now:
was: 5:00 GMT-6
now 6:00 GMT-5
As we are in DST right now, GMT-5 is correct.
They get updated, though, so they show today’s date. I could probably just issue an “openhab:send” to update them to the correct time, but that’s just a workaround.
The variable items that use astro are correct.
I’ll try to cook up some debug logs over the weekend.
My working theory is that the code that moves the date times to the next day is messed up.
context.toToday = function(when) {
var now = ZonedDateTime.now();
var dt = toDateTime(when);
return dt.withYear(now.getYear()).withMonth(now.getMonthValue()).withDayOfMonth(now.getDayOfMonth());
}
Date Times are complicated and I suspect that leaving the time part unchanged is skipping the part that will calculate the DST changes.