Dark Sky Sunrise / Sunset Times Off

Configuration
1

I’ve created a dark sky sensor and everything appears to be working fine except the sunrise and sunet times are way off. I suspect it’s showing me GMT time instead of my local time. I’m -6 GMT. It says my sunrise time is 12:55 and sunset is 23:52. Any idea how I can correct this?

2

To check some basics, try entering these into the Template editor:

{{ utcnow() }}
{{ now() }}
{{ utcnow().astimezone() }}
{{ now().astimezone() }}
{{ utcnow().tzinfo }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}

What do you get?

E.g., I’m also in GMT-6, and I get this:

2019-02-08 20:46:57.063095+00:00
2019-02-08 14:46:57.063326-06:00
2019-02-08 14:46:57.063606-06:00
2019-02-08 14:46:57.064296-06:00
UTC
America/Chicago
CST

If you get similar results, then it would appear your clock and time zone settings are correct.

When you say you’re using Dark Sky, do you mean Dark Sky Weather, or Dark Sky Sensor? I’m assuming the latter. In any case, can you post what you see for the corresponding entities from the States page?

3

This is the output:
2019-02-09 02:37:04.584090+00:00
2019-02-08 20:37:04.584213-06:00
2019-02-08 20:37:04.584370-06:00
2019-02-08 20:37:04.592659-06:00
UTC
America/Chicago
CST

And you are correct, I was talking about the sensor.

4

Ok, I think that verifies that the clock is set correctly, and the time zone setting in HA and the time zone setting in the environment in which HA is running both agree and are correct.

What do the full states of these sensors look like? E.g., on the State page.

EDIT: I’ve been using the darksky sensor platform, but only with icon in monitored_conditions. I just tried adding sunrise_time and sunset_time, but it failed. Hmm, I’m still on 0.84.6 and it looks like these options were added later. Still, if you can tell me what the states look like, I might be able to help.

5

Sure thing.

Sunrise state = 2019-02-08 12:55:02
Sunset state = 2019-02-08 23:52:03

Also, I’m running 0.87.0

6

So those are naive date/times, since they don’t include a UTC offset. So, by themselves, there’s no way to know what time zone they are intended to show. But, as you’ve discovered, they seem to be UTC.

You could convert them to local time via a template, something like this:

{% set state = '2019-02-08 12:55:02' %}
{{ strptime(state, '%Y-%m-%d %H:%M:%S')
   .replace(tzinfo=utcnow().tzinfo).astimezone(now().tzinfo) }}

Of course, change the first statement to reference the state of the sensor, e.g.:

{% set state = states('sensor.dark_sky_sunrise_time') %}
1 Like
7

Thanks! So I pasted that into the template editor and changed the state value with the sensor name and the output showed the correct time. But now I’m not sure what to do with the template information.

8

You can create a Template Sensor, one for sunrise and one for sunset. Then show those in the frontend instead of the “raw” sensors. Let me know if you haven’t used that before and if you need any help. Does this make sense?

9

Makes perfect sense. I followed the template sensor link in you reply and got it to work! Thanks a ton! Now, is there a way to change the output of the template from 2019-02-09 06:54:17-06:00 to just the time 6:54. And is it possible to use 12 hr time instead of 24 hr time?

10

Sure. Add .strftime('%I:%M') to the end.

1 Like
11

Is there a reason you are using sunrise/sunset from Dark Sky instead of the Sun component?

12

Check out PR #19492 and related Issue #85438.

And, as long as we’re on the topic, check out my rejected PR #15961.

And, I guess I might as well add, my custom version of the sun component.

13

You mean this?

So the sun component calculates sunset only after sunrise has occurred?

If that’s true then I empathize with the desire to use something else … but that still leaves the Sun component with an ugly little quirk. Should this issue be added to Github? Only open issue I found (using this search term) was this one but I don’t think it’s the same thing.

14

Actually, I didn’t know there was another way to do it as I’m still new at HA. Only on day 2.

I saw the sunrise and sunset times as monitored conditions when I set up the darksky sensor so I just ran with those. Glad I did though because that’s what prompted me to ask my question and now I know about template sensors. Yay!

15

Welcome aboard! Your ‘magnificent obsession’ has just begun! :slight_smile:

16

Thanks! I dug deep into luup and vera when I started this journey a few years back. Then programmed Savant for a while. I know all about the ‘obseesion’! lol. Now HA. So far so good!

17

The sun component does not have sunrise and sunset attributes. It has next_rising and next_setting. Which mean they indicate when the next sunrise or sunset will be. So, e.g., before sunrise next_rising will be today’s sunrise. But immediately after sunrise it changes to tomorrow’s sunrise. Same thing happens with next_setting (but, of course, at sunset.) So it has no attributes that indicate today’s sunrise and sunset for the entire day. Although the next_xxx attributes are ok for display purposes, they’re pretty useless for templates.

1 Like
18

Thanks for helpful explanation … and I agree with your assessment of their utility.

FWIW, there’s a lot to like about Home Assistant but some of the fundamentals have weak implementations. My observation is based on personal experience using another system for over a decade. It has a ‘SYSTimes’ object with 19 methods. Two of those methods are sysSunrise() and sysSunset() (and they work as one would expect). Here’s a simple example of turning on a light if the current time is between sunset and sunrise:

with times
     if .sysTime > .sysSunrise(.sysDate) and _
        .sysTime < .sysSunset(.sysDate) then
          Home.Greenhouse.Heat_Lamps.PowerState = True
     end if
end with

I like the enhancements in your custom Sun component. Any reason you haven’t submitted it as a PR? Seems like it should be part of the release version.

19

I think you missed this:

Notice how I described it as rejected. The reason it was rejected, I believe, is that they want to completely overhaul the sun component to be more inline with how sensors are done now, rather than accept a useful incremental change. That was over five months ago. As far as I can tell, nobody has signed up to overhaul the sun component in this way.

Feel free to use my custom sun component. As far as I know, it still works just fine. (I’m using it on 0.84.6.)

1 Like
20

Oops! Sorry! I did miss that!

FWIW, discussions for overhauling the climate component started last March and also appear to be on the back-burner. Like many open-source projects, something must first attract a developer’s attention in order for it to get done. Revising existing sun and climate components isn’t nearly as interesting as new integrations or major new features.