Why different types of Triggers within openLuup & ALTUI

[a-lurker]

Wanted to check if was day or night and figured I would use:

local altitude = luup.variable_get(SID.SOLAR, 'ALT', ID.OPEN_LUUP)

If altitude is positive it's day, else it's night. However when I read these variables they are incorrect for my locale. The actual values for sunset and midday are correct but do not occur at sunset or midday. I have checked the clock that openLuup uses and it's correct.

Now the time for midday is one hour out and the time for sunset is 13 hours out.

I checked this by getting the UNIX epoch for my location for both sunset and midday and then adding the hours of offset and then called:

local ID = {
   OPEN_LUUP = 2
}

local SID = {
   OPEN_LUUP = "openLuup",
   SOLAR = "solar"
}

--local localTime = my_epoch_for_midday + (3600*1)
local localTime = my_epoch_for_sunset + (3600*13)
local coords = {Epoch = localTime, '', Latitude = '', Longitude = ''}

luup.call_action(SID.SOLAR, "GetSolarCoords", coords, ID.OPEN_LUUP)

local altitude = luup.variable_get(SID.SOLAR, 'ALT', ID.OPEN_LUUP)
local azimuth = luup.variable_get(SID.SOLAR, 'AZ', ID.OPEN_LUUP)

print('New altitude: '..altitude)
print('New azimuth: '..azimuth)

and I get the right answers.

Not sure what I'm doing wrong. Or perhaps there is some code mix up with UTC versus local time. I checked the documentation but no mention of the solar variables.

If I look at the chart it looks like the whole thing is correct but shifted by my timezone. However I wouldn't expect the timezone to come into play in these calculations.

Feature request: would like to see an openLuup variable that is true for day and false for night. eg IsDay

[akbooer]

Thanks for that report. Always difficult to check these things when development occurs in the Greenwich time zone! HOwever, I thought I had this nailed. Are you absolutely sure that your locale is set correctly on your host system? It is, of course, possible to have the system set to the correct local time but be in the wrong zone.

Aside from that, are your latitude and longitude attributes set correctly in openLuup?

@a-lurker said in OpenLuup - problem with solar AZ and ALT variables?:

Feature request: would like to see an openLuup variable that is true for day and false for night. eg IsDay

Good idea... I'll do that.

[akbooer]

Given that there is already a luup.is_night() function call, it would perhaps be more consistent to have an "IsNight" variable?

Does that call, by the way, give you a correct result?

Out of interest, what will you use this for? You can already trigger scenes at sunrise and sunset.

[a-lurker]

Lat and lng are correct and so is the time zone - the latter was tested with the code below, which returns seconds. Still. I don't see what the time zone has to do with anything.

Mmmm I'd forgotten about luup.is_night() and yes it works perfectly. So maybe a "IsNight" variable is probably not required.

local function get_timezone()
  local now = os.time()
  return os.difftime(now, os.time(os.date("!*t", now)))
end

All a bit odd. Here are the SIDs and ID I'm using:

local ID = {
   OPEN_LUUP = 2
}

local SID = {
   OPEN_LUUP = "openLuup",
   SOLAR = "solar"
}

I've modified my previous post to reflect that.

openLuup has been working really well for me, so thanks once again for all your efforts.

[a-lurker]

Out of interest, what will you use this for?

I have some blinds that go down if:
a) it becomes dark (ie sunset trigger) (eg in winter)
b) at a certain time (ie time trigger) if its still day time (eg in summer). (hence the day/night check)

[a-lurker]

Something else I've noticed: I've been running this solar test code in the openLuup console and when I switch to the "Devices" tab I get this error message and nothing else shown - may be related?

./openLuup/panels.lua:70: bad argument #2 to 'date' (number expected, got string)

[akbooer]

@a-lurker

Oooh, useful diagnostic maybe. I’ll dig into that.

[akbooer]

Very odd... argument #2 for os.date() should be a string, not a number.

I can, however, replicate this error.

Still looking...

[akbooer]

OK. This bad argument error should be fixed in development version 22.06.20

Can you give it a go?

Still thinking about the GetSolarCoords error. Can you confirm that everything is correct in the running system (ie. their current values on the device panel / variables) it's only the returns from this action call that are in error?

Thanks.

AK