openLuup is_night() problem

Plugins & Plugin Development openLuup
#1

I’ve noticed some strange behavior in the morning which I traced to luup.is_night() thinking it is still night when the sun is definitely up.

print(os.date("%c")) return luup.is_night()
returns “true” and prints “Thu Sep 21 08:38:18 2017”. The date/time is correct, but it is certainly not night! I don’t recall changing anything that would affect this. I used luup.attr_get to check the latitude and longitude and they show the correct values (roughly 37, -122). Any ideas?

#2

Well, the critical thing is what time you get from luup.sunrise() and luup.sunset().

#3

sunrise shows as 1506088537.7906, sunset shows 1506132249.217. Those values look correct, sunrise is 6:55 AM tomorrow in my local timezone (using http://www.convert-unix-time.com/?t=1506132249.217). I do have the timezone attribute set to “-8”.

#4

is_night is defined in openLuup/timers.lua as:

now < rise or now > set

where [tt]rise[/tt] and [tt]set[/tt] are TODAY’s times (ie. not necessarily the ones returned by luup.sunrise() and luup.sunset().)

However, thinking further, it seems that the logic I’ve used for ‘today’ revolves (inevitably) around universal time. This is obviously not the case. I need to work on this.

The timezone attribute is not used - it’s purely cosmetic in case other plugins need it, and you can set it to anything you like (it’s not set automatically by the longitude.)

#5

I’m having the same problem. Suspect an equinox rounding error. rise_set() seems to be returning the wrong noon ie a day out.

Was having a track through rise_set(). This seems to include the local time zone. I would have thought it would all be done in UTC?

J2000 = os.time {year = 2000, month=1, day=1, hour = 12}

os.date (“*t”, t) may need to os.date (“!*t”, t)

Any way that’s not the root cause - I’ll keep looking!

Need to sort it out before the equinox passes?

#6

I’ve temporarily switched to the use of the DayTime plugin which is working for me. It’s a little more cumbersome as you have to grab the variable in order to use it.

#7

Yes - looks like an equinox problem. All has come good here to-day. Did some checking:

Line 115:

local noon = t - 240*(q - RA + longitude)

q and Ra move through up to +180 then flip to -180. But they don’t it simultaneously, so noon ends up being the noon for the next day. This then causes is_night() to fail.

Not sure if there is an easy solution. I wrote up some code using this approach (note: linked example contain errors). Possibly this method could be utilised if an solution cannot be found:

#8

Thanks for that diagnostic. Yes, I need to revisit this. Whilst the basic calculations are good (I think), all the stuff around it to make it act like Vera is somewhat ad hoc.

#9

That explain why Day or Night plugin stop working too?

#10

[quote=“DesT, post:9, topic:197235”]That explain why Day or Night plugin stop working too?[/quote]Hmm, the DayNight plugin continued to work for me, no problems. And now that the equinox has passed, is_night() is working again as @a-lurker pointed out.

#11

[quote=“a-lurker, post:7, topic:197235”]Yes - looks like an equinox problem. All has come good here to-day. Did some checking:
…
q and Ra move through up to +180 then flip to -180. But they don’t it simultaneously, so noon ends up being the noon for the next day. This then causes is_night() to fail.

Not sure if there is an easy solution.[/quote]

Well, it has taken me a while, but I hope (believe) that the latest development release 18.2.4 has fixed this.

My approach is simply to use vector rotation to calculate the difference angle, rather than straight-forward subtraction. The amended code is now:

  -- 2018.02.04  correct quadrant error using vector rotation to calculate angular difference
  --
  -- local noon = t - 240*(q - RA + longitude)               -- actual noon (seconds)
  --
  -- thanks to @a-lurker for diagnosing this problem:
  -- see: http://forum.micasaverde.com/index.php/topic,50962.msg330177.html#msg330177
  
  local s = sin_q * cos_RA - cos_q * sin_RA               -- vector rotation
  local c = cos_q * cos_RA + sin_q * sin_RA
  
  local q_RA = atan2(s,c)                                 -- the (q - RA) difference
  local noon = t - 240*(q_RA + longitude)                 -- actual noon (seconds)

Many thanks to all, particularly, @a-lurker. Hopefully fixed in time for the next equinox!

#12

@akbooer… Any reason why you would not make this last development branch a formal release? It’s been a long time since the last one.

#13

Interesting you should ask. It’s been too long, but is in hand. The documentation has been updated and I’ve been refactoring the server, as well as many smaller tweaks. There is one known monthly timer bug remaining.

I’ve also been updating VeraBridge in advance of the Vera security updates. Can?t fully test this until they are released, but I won’t wait until then.

Coming soon.

#14

[quote=“a-lurker, post:7, topic:197235”]Yes - looks like an equinox problem. All has come good here to-day. Did some checking:

q and Ra move through up to +180 then flip to -180. But they don’t it simultaneously, so noon ends up being the noon for the next day. This then causes is_night() to fail.[/quote]

I fixed this a while ago, but having just gone into DST here, I?m hoping you had no problems this time?

#15

Well a few equinoxes have passed by and I think I can now safely declare this as fixed! The vector rotation technique is a good one. Thank you.

Just out of interest; besides Vera’s monthly restarts, it also does a daylight saving transition restart at 3 am local time.

1 Like
#16

…well then, so can I!

Yup, spotted that already…

https://community.getvera.com/t/disable-automatic-luup-reload-ie-at-1st-of-month-on-dst-changes/209525