Error:
Platform error binary_sensor.sun2 - cannot import name 'helpers' from 'custom_components.sun2' (/config/custom_components/sun2/__init__.py)
unfortunately… won’t pass config checker.
Strike that ^^^ , and wait, I hadn’t noticed the helpers.py file. sorry.
seeing this now:
so it’s working and correct 
could you make this have a bit more friendly state: tomorrow at 08:11:04 would be cool…
Nice! Let me know if you see any hiccups.
Probably not. That’s a frontend issue. I’m more concerned about backend issues like making it more useful for automations and template sensors. As it is I’ve broken the rules by making it local time instead of UTC. In the famous words of Lou Costello, “I’m a bad boy!” 
Ahh so that’s why I’ve seen so many complaints about prayer call components having to be converted from UTC.?
Probably. I really don’t understand the idea of making datetime attributes UTC. If they were naive datetimes, then maybe. But they’re time zone aware datetimes, so whether they’re local time or UTC makes absolutely no difference when using them in calculations. But making them local sure makes it easier for a human reading them.
Amen to that
I still have to consult a model in my head about if a time zone is east or west, which way the earth turns as to whether the offset is ahead of me or behind me (day wise) 
sure, none so far, its either true or not true
about the frontend: of course I was a bit overzealous , but I meant to ask maybe more like this:
The backend can’t really do that, since it doesn’t know when it will be displayed. However, you can certainly create a template sensor with {{ state_attr('sensor.sun_is_up', 'next_change") }} and then set its device_class to timestamp so the frontend can display it that way.
Hi Phil,
thanks, but you’re confusing me now…
the screenshot I posted contains only the entities you’re component has made, without any template or setting in device_class on my behalf.
that’s why I would have hoped it to be possible you set the same format for these next_changes attributes directly in the component itself.
Those are sensors whose state is a datetime string, and they have device_class set to timestamp already. Look at them on the States page.
Now you’re asking about an attribute. Attributes don’t have a device_class.
of course! forgot about that, so sorry.
could be a nice feature request to have attributes that are datetime strings use the timestamp device_class…
Hi, today i have strange behaviour of the sun2 component.
Now it’s 12:06pm in my place and i discovered this inside the sun2 component related to the sun elevation:
While the default sun integration shows at the same time:
As you see the right elevation comes from the default sun.
How is it possible the sun2 component is so wrong?
All my automations went crazy since this morning… 
That happened also tonight with the same behaviour:
the sensor.elevation stopped at -66.5 degree as you can see and the time now is 10:27am.
The right elevation at this moment is 23.04.
In the log i see:
2019-11-30 00:55:48 ERROR (MainThread) [homeassistant.helpers.entity] Update for sensor.elevation fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 270, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 448, in async_device_update
await self.async_update()
File "/config/custom_components/sun2/sensor.py", line 117, in async_update
self._update()
File "/config/custom_components/sun2/sensor.py", line 316, in _update
rnd_elev + _ELEV_RND, self._sol_noon - _PEAK_MARGIN)
File "/config/custom_components/sun2/sensor.py", line 250, in _get_nxt_time
nxt_time = _calc_nxt_time(time0, elev0, time1, elev1, trg_elev)
File "/config/custom_components/sun2/sensor.py", line 216, in _calc_nxt_time
time0 + (time1 - time0) * ((trg_elev - elev0) / (elev1 - elev0)))
ZeroDivisionError: float division by zero
Thanks for the details, and sorry this isn’t working for you. I’ll see if I can spend some time in the next few days to work on a fix. Could you tell me your GPS coordinates (via a PM) or at least tell me roughly in what part of the world you are so I can try to reproduce this?
Released sun2 1.5.0
Adds elevation binary sensor.
Note that the default elevation binary sensor, configured in this way:
binary_sensor:
- platform: sun2
monitored_conditions:
- elevation
will result in an entity named binary_sensor.above_horizon which will be 'on' when the sun is above -0.833° (i.e., between sunrise & sunset.)
Is anyone else having trouble updating to the latest version thru HACS?
it says 1.5.0 is available and I can click to update and it says restart required but when I restart HA it goes right back top saying that 1.4.0 is installed.
Then if I check the files that are downloaded I don’t have the binary_sensor.py or helpers.py that are in the repo.
I’ve tried a few times with the same results
I haven’t personally tried it. I gave up on HACS a long time ago. Seems more work than it’s worth. But, if someone can figure out if there’s something I need to change to make it work I’m happy to do it. I just don’t want to keep trying to keep up with HACS; it’s too painful.
EDIT: FWIW, someone noted problems with HACS above. See:
Installed and updated via HACS worked fine for me.
Just browsing the latest HACS docs for developers, there seems to be (at least) two new requirements. The repository is supposed to have “topics.” I didn’t have those. Just added a couple. Not sure how much difference this makes.
It also now seems to require a new hacs.json file. I have not created that. No idea what not having that file does to HACS’ ability to use my repository.
I think those changes are only for new repos… when you’re in it should work anyway. As I said I updated via HACS ok. My own custom component also updates ok…