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.
I’ll show you how to add/subtract an hour (or whatever amount).
- Use
as_timestamp()to convert sunrise/sunset to a timestamp. - Add/subtract, in seconds, whatever amount you want to offset it. For example, for one hour you can use
3600or60 * 60ortimedelta(hours=1).seconds - Use
timestamp_local(), ortimestamp_custom()to convert the adjusted timestamp to a datetime string.
This one line does it all and can be used in a Template Sensor.
{{ (as_timestamp(state_attr('sun.sun', 'next_rising')) - timedelta(hours=1).seconds)| timestamp_local() }}
You can create separate Template Sensors (one for CST sunset and the other for CST sunrise) or you can create a single Template Sensor that contains attributes for sunrise and sunset in CST.
Paste this into the Template Editor and experiment with it to understand how it works:
{{ state_attr('sun.sun', 'next_rising') }}
{{ as_timestamp(state_attr('sun.sun', 'next_rising')) }}
{{ (as_timestamp(state_attr('sun.sun', 'next_rising')))| timestamp_local() }}
{{ as_timestamp(state_attr('sun.sun', 'next_rising')) - timedelta(hours=1).seconds }}
{{ (as_timestamp(state_attr('sun.sun', 'next_rising')) - timedelta(hours=1).seconds) | timestamp_local() }}
Thank you. It is solved thanks to your great explanation.
Took me a while to get it working but it works well.