Especially this close to the 2.3 release, we really need to know which “one of the snapshot updates.” Most importantly does this problem still exist in the 2.3. Test Release?
Hi Rich. Unfortunately, I don’t know. The lamp that’s controlled by this rule is in an obscure place, and I only noticed the problem whilst looking through the logs at another problem. As for the ‘Test release’, I don’t know how this would be installed. If there’s anything that I can do to pin this down, please let me know.
We don’t care as much about when it first occurred as we do about whether it is still a problem in the release candidate which it appears to be the case.
Now we know it is still a problem in the latest version. The next step is to determine if it is a bug or something else.
Add log statements to log out what now is and what Sunset_Time is before the if statement. Do the times makes sense?
I’ve had the same issue again, and I’m wondering if it’s the transition from the 31st May, to the 1st of June. I’ve performed a reboot of the Pi, and reinstated the extra logging, so I’ll keep an eye on it.
UPDATE: saw the problem again last night, and the culprit is the Astro binding, returning the wrong date:
NOW______2018-06-05T12:31:18.921+01:00
Sunset Time 2018-06-04T21:19:00.000+0100
Note that the day, reported by the Astro binding, is the 4th, whereas ‘NOW’ is the 5th.
Having looked at today’s values, they look correct.
Question: Are these times calculated localy, or retrieved from a remote service?