Hours of Daylight

Configuration
41

How exactly are you getting those values? Are you using the value being returned in day_length, or are you calculating them from sunrise and sunset? And if the latter, how exactly are you obtaining sunrise and sunset?

Of course everything I said depends on the website actually functioning correctly. :slight_smile:

What I have now I just set up about four hours ago, so it hasn’t even gone through a complete day cycle. I expect the values to update shortly after midnight local. Whatever happens, I can report back tomorrow night after it’s gone a full day.

42

Well I’m using this:

  - platform: rest
    resource: !secret daylength_yesterday
    name: "Day Length Yesterday (sunrise-sunset.org)"
    value_template: "{{ value_json.results.day_length }}"
    scan_interval:
      minutes: 60
  - platform: rest
    resource: !secret daylength_today
    name: "Day Length Today (sunrise-sunset.org)"
    value_template: "{{ value_json.results.day_length }}"
    scan_interval:
      minutes: 60
  - platform: rest
    resource: !secret daylength_tomorrow
    name: "Day Length Tomorrow (sunrise-sunset.org)"
    value_template: "{{ value_json.results.day_length }}"
    scan_interval:
      minutes: 60

With the URL: daylength_yesterday: https://api.sunrise-sunset.org/json?lat=redacted&lng=redacted&date=yesterday

ditto for today and tomorrow.
Weird thing too is that if I put the URL into a browser yesterday is correct length.

But I think what you are missing (?) is that it’s giving you the UTC day/date so if the UTC date is for the wrong day it’s going to be wrong. You aren’t specifying a date so it’s always going to be today I think and correct.

43

That’s weird. What you have seems correct. I wonder if that is pointing to another issue. Are you getting any errors? What is the last_updated and last_changed for these entities? (You don’t have to tell us. Just saying you might want to look at that.) Also note that you have scan_interval set to 60 minutes, which is fine, but that means that when the website does switch/shift days, it can take up to that long before your entities will show that. Just something to keep in mind.

Not true. It doesn’t matter if UTC is tomorrow morning, because that translates to tonight (assuming, again, for me, we’re in the 7:00 PM to midnight local time period.) Just because the UTC’s date is tomorrow’s date, doesn’t mean it’s representing tomorrow local. For me, 8:00 PM local today is the same as 1:00 AM UTC tomorrow.

Anyway, enough on that. If the website is reporting the day_length for today, then it doesn’t matter whether you’re using formatted or not, or whether the sunrise and sunset are reported in local or UTC. Again, assuming the website is working correctly.

44

and I just restarted Home Assistant and it’s updated and showing image

45

yeah I thought that might be it… it might have missed the 10am switchover amd might refresh at 11ish…
I did change to 1 hour instead of 60 minutes too before I restarted.

but hang on…
it’s getting the info for the UTC date. The UTC date will change from yesterday to today at 10am here (we are +10) so before 10AM if I execute the URL I would expect it to show a different result to if I do it after 10am because the UTC date has changed.
Interestingly, if I search for Sydney on that site, it shows totally different day lengths and sunrise/sunset times in the table! (only a few minutes different but still different)

46

see also

image
image1151×99 7.59 KB

for today and tomorrow it ticked over at 10:11am, for yesterday at 10:48 when I restarted.

47

No, it’s getting the info for the lat/lon you give. At least that’s what I assume. The date of the UTC representation of those times doesn’t matter. It’s the date of the local time representation of those times that matters. Let me make this concrete. In your case, where the local timezone is +10:00, the sunset for your “today”, represented in the local timezone, will have your local today’s date, and the time will be what you expect. But, if you take that exact same date/time, and represent it in UTC, the date will be one less (“yesterday”), and the time will be +14 hours. So, e.g., 7:00 AM “today” local is the same date and time as 9:00 PM “yesterday” UTC. It doesn’t matter that the UTC date is yesterday, the date/time still represents your today. Oh well, that’s the best I can do in trying to explain it. If we still disagree, then I guess we’ll have to agree to disagree. :slight_smile:

48

You can see from the screenshots that’s it’s updating the day length at midnight UTC.

49

Yep, I definitely see that. I’m just not sure I understand why. It doesn’t make sense to me.

BTW, the fact that yesterday’s day length didn’t change at the same time as the others could simply be explained by the fact that it takes three separate exchanges to get all three values, and the yesterday one might have hiccuped.

I’ll report back what I see on my setup tomorrow. I’ll go ahead and add sensors for yesterday and tomorrow, too, to make it more like yours.

This is weird.

1 Like
50

You know, I was just looking at the code for the standard sun component, and the annoying part of all of this is, it could provide the current day’s sunrise and sunset as attributes (in addition to the others.) It seems to have all the information available to it. Whoever wrote it, though, apparently just decided not to include them. :frowning:

It uses the Python astral package. And there are functions provided in homeassistant.helpers.sun that can be used to do this (pretty much the same ones that sun.py uses.) Maybe I’ll write a custom component for this. The plus is it doesn’t need to query any website; it appears to be based on some data and equations. Add one to the project list…

(Yeah, I know, this should be done via an issue or pull request. Still really don’t know how to do that.)

1 Like
51

confused…

I use:

      nextsunrise:
        friendly_name: 'Next Sunrise'
        value_template: >
          {{ as_timestamp(states.sun.sun.attributes.next_rising) | timestamp_custom(' %I:%M%p') | replace(" 0", "") }}
        icon_template: mdi:weather-sunset-up
      nextsunset:
        friendly_name: 'Next Sunset'
        value_template: >
          {{ as_timestamp(states.sun.sun.attributes.next_setting) | timestamp_custom(' %I:%M%p') | replace(" 0", "") }}
        icon_template: mdi:weather-sunset-down

it does tick over to tomorrow though after sunrise/sunset…

52

Yes, that’s kind of the whole point to this topic, right? :slight_smile: I.e., the standard sun component does not provide the day’s sunrise and sunset for the entire day, so that you can’t just calculate the length of the day at anytime throughout the day.

So I think I owe you an apology. I was so stuck on how I thought the website should work I was explaining away the results you were seeing. You are clearly right. It seems to select the date by what the date is in Greenwich (i.e., UTC.) So I went back and looked at the documentation on the website again, and so far I’m not sure how to get around that, at least with the REST Sensor (that doesn’t allow for templates in the resource URL.)

I really think the right way to attack this problem is to enhance the standard sun component to provide the current (local) day’s sunrise and sunset for the entire (local) day as additional attributes. I’m going to do that by copying the standard code and turning it into a custom component. If I get that working I’ll probably post it in a new topic and reference this one. The other advantages to doing it this way is that it can update right a midnight, and it doesn’t require polling any external website.

1 Like
53

Sweet. I’ve been following this convo (using REST method) - looking forward to this.

1 Like
54

I think I might have finally found a solution to this method!

Instead of using yesterday, today and tomorrow, (for your +10:00 timezone) use “-14hours”, “+10hours” and “+34hours”. I haven’t really tested this yet, other than using those strings in the query, but I think this has a chance of working. So, again for your timezone, the URLs become (for yesterday, today and tomorrow, respectively):

https://api.sunrise-sunset.org/json?lat=redacted&lng=redacted&date=-14hours
https://api.sunrise-sunset.org/json?lat=redacted&lng=redacted&date=+10hours
https://api.sunrise-sunset.org/json?lat=redacted&lng=redacted&date=+34hours

So, e.g., at your midnight, when it’s 2:00 PM the day before UTC, it will add 10 hours to UTC and get midnight UTC with the same date as your local timezone date, and therefore, should switch days at midnight local.

I’m going to update my URLs accordingly (except, of course, since my timezone is -05:00, I’ll use “-29hours”, “-5hours” and “+19hours”) and see what happens at 7:00 PM tonight and at midnight!

I have a feeling this is how the website is intended to be used. Sure would be nice if they had a small note about it.

1 Like
55

FWIW, I made a custom sun component that adds (local) today’s sunrise and sunset as attributes which should stay constant throughout the entire (local) day. It was actually pretty simple. I’m testing it out now and, like I said, if it seems to work I’ll probably create a new topic to share it. I’m really surprised someone else hasn’t already done this (or maybe they have and I haven’t seen it.)

2 Likes
56

It’s interesting… my sensors haven’t ticked over today yet - still showing the same data as yesterday afternoon. All saying they were updated 16 hours ago.

I had been thinking overnight of toying with testing the UTC and local to see if they were the same day and then taking a different URL… basically creating 4 dummy sensors and then depending on the test creating real ones but yours is better.

Note: 10:39am here and just now yesterday and tomorrow updated but today is still old data… I think I might also change the refresh time to 10 minutes!

used -14,+10 and +34 and set refresh to 10 minutes and restarted. All correct now. It’s maddening you have to hammer their api like that!!! I’d prefer to minimize the calls but if it’s failing updating then I’m just going to have 10 minutes!

Looking forward to your new component.

57

@DavidFW1960 and @chrisw (and whoever else is interested), you can give it a try if you like. Just place a copy in a directory named custom_components in your HA config directory, and this one will take precedence over the standard component.

https://github.com/pnbruckner/homeassistant-config/blob/master/custom_components/sun.py

I know I probably should have forked it or something, but after using several other version control systems over the years, I just don’t have the strength to learn yet another one! :wink:

Anyway, let me know what you think.

3 Likes
58

can you clarify… /custom_components or /custom_components/sensor
I’m thinking /sensor?

59

custom_components. It’s replacing components/sun.py.

1 Like
60

yeah copy that. I put it in that folder under the sensor folder and it didn’t work so I just moved it up and restarting now.

Isn’t this FUNNNNNNNN

1 Like