So in the UK the clocks went back last week so my lights should be coming on in the morning ( i get up at 6am for work) for the next few weeks. Before daylight saving and when sunrise was after my lights (3No. total) were coming on fine, however since daylight saving has kicked in at some point during the night the lights dont come on when im getting up. (today’s sunrise was around 6.35am)
Heres the odd thing, the lights are coming on fine at sunset as expected, and also during the night up to some point in the small hours, for example i got up for a drink around 3am this morning and the lights came on but didnt come on when i got up at 6am. Now one light is using PLTS and the others are using vera scenes, so its not PLTS or Vera specific. Im controlling the ‘up to sunrise’ time using LUA code from the FAQ in here and like i said it was all working fine until the clocks went forward one hour.
Ive also checked vera and its reporting the correct time. Have i missed a tickbox somewhere? what do i need to look at?
NOTE: The log file is buffered so it does not write out immediately … When it does output it can be several minutes behind the real clock.
But you can get a rough idea of the time. To get a more accurate time, interact with your Vera (another browser window) while you are watching the log.
The activity will force the log output more quickly.
Pretty poor design by Vera … There really ought to be a way to see the Vera Time … probably the best place is in the settings where you set the Time Zone.
Well home and the Linux way you showed shows the current time when i scroll to the bottom of the log screen
Having just got home, one light in our porch light is coming on early (uses a vera scene to come on at sunset based on a door sensor, last ran at 19:00 with lua code restricting from sunset to sunrise, sunset today is 19:34) but the lights in our living room which are due to come on 20 minutes before sunset havent come on and are due to run at 19:16.
Code for the porch light which was working before daylight saving:
local pStart = 0 -- Start of time period, minutes offset from sunset
local pEnd = 0 -- End of time period
local allow = true -- true runs scene during period, false blocks it
local mStart = math.floor( (luup.sunset() % 86400) / 60 ) + pStart
local mEnd = math.floor( (luup.sunrise() % 86400) / 60 ) + pEnd
local tNow = os.date("*t")
local mNow = (tNow.hour * 60) + tNow.min
if mEnd >= mStart then
return (((mNow >= mStart) and (mNow <= mEnd)) == allow)
else
return (((mNow >= mStart) or (mNow <= mEnd)) == allow)
end
and here is my bathroom light code (in PLTS) asking lights to come on 20 mins before sunset, which they arent now:
local pStart = -20 -- Start of time period, minutes offset from sunset
local pEnd = "22:30" -- End of time period
local allow = true -- true runs scene during period, false blocks it
local mStart = math.floor( (luup.sunset() % 86400) / 60 ) + pStart
local hE, mE = string.match(pEnd,"(%d+)%:(%d+)")
local mEnd = (hE * 60) + mE
local tNow = os.date("*t")
local mNow = (tNow.hour * 60) + tNow.min
if mEnd >= mStart then
return (((mNow >= mStart) and (mNow <= mEnd)) == allow)
else
return (((mNow >= mStart) or (mNow <= mEnd)) == allow)
end
Lua’s handling of dynamic changes to time zones (that’s what daylight saving is) is rudimentary. Even if the OS has correctly adjusted your time zone for daylight saving - it looks like it has - this change may not propagate to the Lua runtime. Calls like os.date() may continue to assume that you are still on GMT and not know that you are now on BST.
A Luup reload will probably fix this. (Or it might need a Vera reboot but I doubt it.)
Another way to fix it is to avoid any Lua calls that rely on your time zone, such as os.date(). Calls to luup.sunrise(), luup.sunset(), and os.time() probably don’t depend on your timezone, so see if you can rephrase your code using only those functions.
(That said, I think that there’s a bug in the logic of your code, which only becomes visible when your time zone is not the same as UTC. Maybe that’s what’s happening here. Check the values of mStart and mEnd; I bet they still think that you are on GMT.)
Here, let me demonstrate. I’m in UTC+11 (until tonight, coincidentally, when we move back to UTC+10). Any error in the code will be amplified compared to you.
I ran:
luup.log((luup.sunrise() % 86400) / 3600)
luup.log((luup.sunset() % 86400) / 3600)
which ought to tell me how many hours after midnight sunrise and sunset will occur, respectively. The output is:
So sunrise (20.61) must be at 8.36 PM, and sunset (8.14) must be at 8:09 AM! According to an astronomy app of mine they should be 7:34 AM and 7:11 PM respectively. They are out by 11 hours, which is no coincidence. In your location they will be out by 1 hour. Your scenes will run an hour off. In edge cases your scenes may not run at all.
I’m sure that you could tweak the code to offset the values in luup.sunrise() and luup.sunset() by your UTC offset before you perform the modulo with 86400. But I’ve done enough time zone programming to know that this is akin to adding epicycles to the Ptolemaic system, and that it’s probably better to start again with a different approach.