Yes, but it is an integration and I tried plugin. Now it installed
1 Like
I suppose I could add an optional prefix config variable, which defaults to none. Personally I like sensor.sunrise, sensor.sunset, etc. But I see your point.
EDIT: https://github.com/pnbruckner/ha-sun2/issues/1
EDIT 2: Turns out, there’s already a standard way to do this via the entity_namespace configuration variable.
1 Like
Something is off in the time conversions. I have dusk at 19:20 and sunset at 21:11, which is correct, but the converted times say dusk in 10 hours and sunset in 7 hours. All times PDT (-7)
Dusk, I would think, should come after sunset. So the relative times for sunset and dusk seem about right. Also the sunset time looks about right. But the dusk time definitely does not look right. Are you sure you read it correctly?
EDIT: FWIW, this is what I’m seeing:
dawn 2019-06-19T03:05:47-05:00 12 hours ago
sunrise 2019-06-19T05:17:02-05:00 10 hours ago
sunset 2019-06-19T20:30:59-05:00 In 4 hours
dusk 2019-06-19T22:42:14-05:00 In 6 hours
All times CDT (-5)
Hi please don’t delete the existing repo.
I don’t care that it is effectively unsupported, I understand that this is ‘use at my own risk and it may not work in future HA versions’. It is working great for me and I use to perform an automation that e-mails me solar stats on sunset every day.
Also FWIW, I think having sun2 may be cause confusion, as our solar system only has a single sun 
The astro: name makes more sense to me.
lol!
No plans to do that.
No plans to do that.
Great, thanks. 
Great work Phil. I’m switching to this now.
Just FWIW, I’m using hassio remember and if I try and load Astral module in a python3 session it comes up with the error so astral is not available in the HA or SSH containers hence I was using a shell script on the host which works of course. There is a dependency for Astral I had to do a pip3 install for as well but you can’t do that is the containers… (not have them persistent anyway)
From the ssh addon:
But crap! I am wrong! I can do that in the Home Assistant container… I was having trouble writing a file but worked out how to not use a file so I bet it works now…
EDIT: It works…
So the daylight sensor isn’t precise enough… I’m calculating the change in day length - around 5 seconds at the moment but of course your sensor to 2 decimal places doesn’t show any difference at all.
So I display this:
From the old custom component and my calculations in my python script agree with those values.
Also should the Daylight and Night values = 24?
Thanks Phil.
Yeah, the standard sun component uses astral. It’s definitely part of a HA install.
I can certainly change the # of decimal places to 3. That would resolve to 3.6 sec. Is that enough? Hmm, maybe not. Or 4 places for a resolution of 0.36 sec???
Actually, it might be better to leave the state as it is (i.e., still rounded to 2 places, basically for general display purposes), but add an attribute with the same value, but as a float, and without any rounding. Maybe the yesterday & tomorrow attributes should also not be rounded. Thoughts?
EDIT: Now that I think about it, it might be good for all sensor types to add a today attribute that is the “raw” value of the state. E.g., for those that are datetimes, make the today, yesterday and tomorrow attributes all datetimes (instead of strings in ISO format.) And for daylight and night, make them un-rounded floats. How about that?
EDIT 2: Hmm, I think I like it:
EDIT 3: … and change the state for daylight and night to be rounded to 3 places instead of 2. That way a history graph should show some change from day to day, or so.
EDIT 4: I went ahead and released these changes as 1.1.0.
Huh?
I was in a hurry to get out the door, but it shows
Dusk 2019-06-20T00:19:20-07:00 In 4 hours
Sunset 2019-06-19T21:11:01-07:00 In 1 hour
Not 19:20, it’s 00:19:20 tomorrow, which is even more off than I had thought at a glance.
So it uses the latitude, longitude & elevation from your basic HA configuration. And, of course, it also uses the system’s clock and time zone settings. Are you sure these are all correct?
Regarding the time and time zone settings, please enter the following in the Template editor and let me know what the results are:
{{ utcnow() }}
{{ now() }}
{{ utcnow().astimezone() }}
{{ now().astimezone() }}
{{ utcnow().tzinfo }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}
Also check zone.home on the States page. You don’t have to post the values here, but are the latitude & longitude correct? Lastly, check the Configuration -> General page. Is the elevation correct?
My lat/lon and elevation are correct. They haven’t changed since I setup HA the first time years ago. I display UTC and local time on my main HA page, and they’ve never been off. The anomaly is sensor.dusk being off and sensor.sunset being correct. Shouldn’t they both be wrong if something was misconfigured?
2019-06-20 03:22:39.716907+00:00
2019-06-19 20:22:39.716979-07:00
2019-06-19 20:22:39.717081-07:00
2019-06-19 20:22:39.718476-07:00
UTC
America/Los_Angeles
PDT
Oh sorry… If I add the daylight and night values should it add up to 24 hours?
I’m not a fan of ever rounding raw data at all - for display purposes for sure but destroying data is generally a bad idea IMO.
Hi,
Just added your CC and all is well, except for the Night sensor:
havent added the sensors to the recorder yet, but that probably isn’t it, since the others all show correct state and attributes?
also, just to be fully understanding here, is it correct the sensor.daylight (16.652) doesn’t calculate the time between Sunrise (-5) and Sunset (+11) = 16? Or is this a matter of rounding.
Well, I’m clearly missing something, I’m just not sure yet what it is. I’ve compared my own results against the standard sun component, and although they agree for sunrise and sunset, they don’t seem to be agreeing about anything else, even though as far as I have been able to determine they’re doing (what I thought was) effectively the same thing.
I’ll do some more experimenting today to see if I can figure out what’s wrong.
Thanks for testing it and reporting back your findings!
No. They do not use the same boundaries…
I’m just calling the “standard” astral functions, and that’s how it defines them. I guess the “twilight” times are not represented in either, so that’s the difference???
Can you compare the results you’re getting against the corresponding values in the sun component? Do they seem to agree, or are dawn, solar_noon & dusk off a bit?
Not sure why night has no values. Are you seeing any errors or exceptions in the log?
It’s just a matter of rounding. Sunrise & Sunset specify timestamp for the device class, so the frontend is displaying them in relative terms, and as you can see it is rounding them to the nearest integer hours. So the difference between them compared to what Daylight is showing could be off by up to two hours (again, due to the rounding.)
Actually if it’s time class then you can select relative, absolute etc when you display it…
1 Like