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.
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?
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?
Sure. Add .strftime('%I:%M') to the end.
1 Like
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.
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.
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!
Welcome aboard! Your ‘magnificent obsession’ has just begun! 
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!
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
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.
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
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.
Totally understand. But then why reject a useful incremental improvement for the existing component, especially after someone has taken the time to make the change, update the tests, and update the documentation, and several people chimed in that the improvements are useful and would be used? Go figure!
Completely agree here. Useful changes. The ‘perfect’ quest means the good gets rejected… Happens quite a lot unfortunately. I use Phil’s great sun.py.
I completely understand your reaction. I know of at least two PRs for MQTT HVAC that were recently cancelled. Both would’ve provided useful improvements. I know one was cancelled because it did not conform to a proposed architectural change (key word here is proposed). Without it, MQTT HVAC’s history chart is less than useful (arguably useless). I incorporated the code into my own custom component for MQTT HVAC
2 Likes
I just found this thread and need some help.
I have 2 dark sky setups. One for where I live and another for where my wife moved to work in a hospital as an ER Doc in Wisconsin.
For a few years I have a automation that is sent daily with weather settings and other daily family announcements.
I want to add the Wisconsin weather to the automation. All has gone well with two exceptions.
sensor.wisconsin_sunset and sensor.wisconsin_sunrise.
Today’s sunset is at 4:19 pm cst and sunrise is 7:06 am cst. (I am in the Arizona where time does not change, we are either mst or pst)
Well anyway the info for sunset is 2020-12-01 22:21:00 and sunset is 2020-12-01 13:07:00 as listed in the ha states section.
Even calculating for timezone changes I have no clue where these numbers are coming from. It has to be a UTC “thing” I have no idea how to correct it.
My dark sky config for my location is dead on accurate. So I am very confused.
Do I need to create a template conversion? If so how?
{{ utcnow() }}
{{ now() }}
{{ utcnow().astimezone() }}
{{ now().astimezone() }}
{{ utcnow().tzinfo }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}
gives me this
2020-12-01 22:40:00.004943+00:00
2020-12-01 15:40:00.004963-07:00
2020-12-01 15:40:00.004986-07:00
2020-12-01 15:40:00.005024-07:00
UTC
America/Phoenix
MST
Any help is greatly appreciated.
Did you mean to say MST? When I look at online references for the current time in Arizona, it is reported to be MST (not CST). Current Local Time in Phoenix, Arizona, USA
According to this web-site, sunrise and sunset for December 1st is: 7:14 am – 5:15 pm (MST) or in 24-hour format: 07:14 - 17:15 (MST
UTC is seven hours ahead of you so if we add 7 hours we get (7+7=14 and 17+7=24 or 0 hours):
14:14 and 00:15
That definitely doesn’t correspond to this:
Subtract 7 hours from those values and you get:
15:21 (3:21 PM)
06:07 (6:07 AM)
Those hours are offset by 1 hour compared to the sunset/sunrise times reported by the web-site. Not sure what’s causing that (can’t be due to DST).
In contrast, this is what I see for sun.sun on the east coast (UTC - 5 hours):
``
next_rising: 2020-12-02T12:15:26+00:00 7:15
next_setting: 2020-12-02T21:14:17+00:00 16:14
Subtract 5 hours from each and you get:
07:16 (7:16 AM)
16:14 (4:14 PM)
That's correct for my timezone (EST).
Just for fun, paste this into the Template Editor:
{{ now().timetuple().tm_isdst > 0 }}
If it reports `true` it means Daylight Saving Time is in effect (it should report `false` because it's not observed in your state and it isn't currently in effect even in places where it is normally observed).Thank you for responding,
I did mean to say CST. The offset I need for the second dark sky is from MST to CST.
The dark sky for my MST location works fine, but the one set for Wisconsin (CST) as you pointed out is not displaying properly.
How do I create a template to convert to the correct time.
You gave an excellent explination. Is it possible to have a sun.sun available for two locations. That would solve a lot of problems.
BTW the code {{ now().timetuple().tm_isdst > 0 }} reported False which is correct for me since we do not observe DST.