No issues for me. It didn’t need to be moved BTW
Hmm… Looking in dev-state everything looks ok. I could have sworn that clicking on the sun entity to bring up the card also displayed this extra info. Is this the case? All I see is
Setting In 1 hour 7:44 PM
Rising In 12 hours 6:37 AM
Elevation 23.01
Even so, I still get the above error in my logs.
Wait. what?
(I am not yet on 0.88) but when I am are you saying no changes are needed for this sun component?
This may not have been the most dramatic breaking change but it is one of the most confusing…
That is correctly ZERO changes are needed for sun.py It is now and remains in the /custom_components folder with no changes. (That’s probably why it stopped working for @cjsimmons if he moved and renamed it)
1 Like
Nope. I haven’t moved it as I wasn’t sure as it’s just in custom_components. It still works, I just have this error.m which I don’t understand.
If I had to guess you have an automation that uses a sun trigger. Is that true? If so, then this “great migration” is more of a mess than I originally thought. If you look in the homeassistant install directory, you’ll find this file:
.../homeassistant/components/automation/sun.py
My guess is that the loader is trying to find the “custom” version of that. If so, argh!! 
You could try copying that file to:
custom_components/sun/automation.py
But that might not work either. You may also have to move/rename:
custom_components/sun.py
to:
custom_components/sun/__init__.py
I’m getting very close to giving up on new HA versions!
2 Likes
In case anyone else is having a similar issue with Sun related Automation this recommendation seems to have done the trick for me 
Wait. What fixed it? Just moving custom_components/sun.py to custom_components/sun/__init__.py, or also copying .../homeassistant/components/automation/sun.py to custom_componets/sun/automation.py?
for me it was just the section I quoted…so only had to sun.py to its own folder in custom_components and renamed to …/sun/__init __.py as per your post.
Automations stayed as they were before and are working (based off sunset anyway)
Well, FWIW, I just updated my development checkout of the homeassistant code to the latest dev version (0.89.0.dev0), and added my sun.py to <config>/custom_components/sun.py and restarted. It works fine. The only message is the warning about using a custom version of the component. I even added an automation that uses a sun trigger and restarted. Still no problem. So not sure why you would have to move it to custom_components/sun/__init__.py.
In another thread (I think; I’m getting a little confused after this 0.88 update!!) @DavidFW1960 also said categorically that he did nothing with his sun.py and everything is working fine.
Mine seems to be working with no changes too but I only upgraded a few hours ago…
That was this thread…
In response to @pnbruckner, I’ll have a look around and and try your suggestions. Maybe I’ll just remove it and start again.
I think I only have one sunset automation which turns on some lights at sunset. I’ll have a look.
Sorry!
It’s been a hectic day 
(it’s my only excuse…)
I just did some more testing, and this time I did see the message about sun.automation:
Unable to prepare setup for platform sun.automation: Platform not found.
3:18 PM setup.py (ERROR)
Unable to find platform sun. Search path was limited to path of component: custom_components
3:18 PM loader.py (ERROR)
Error loading custom_components.sun.automation. Make sure all dependencies are installed
3:18 PM loader.py (ERROR)```
It seems I could only get this to happen when I created an automation that used a sun trigger via the Automation Editor. After restarting I did not see the error again (even though the automation was in automations.yaml.)
At one point I even got a persistent notification related to it. But I don’t remember exactly how I got that to happen, and I couldn’t reproduce it.
Not sure what to make of all of this.
This for me as well. I do have sun based automations and as I already said I have not changed a thing. I asked Balloob about this change in the context of 0.88 and ‘the great migration’ and he told me that sun.py is ok and does not need to be moved. I also get a warning about using a custom component for sun but I have ALWAYS had that warning.
FWIW, my automation was created manually as the automations editor sucks when you are using multiple and/or conditions…
Ok, I have some strange behaviour which might be related to the sun component…
I have an automation which turns on a light when it is dark. The sensor* that decides if it is dark uses the sun component.
Every time I start HA the light comes on. The automation is very simple and I can see no other reason than something is at odds with sun and 0.88.1
- alias: Hall light on when dark
initial_state: on
trigger:
- platform: state
entity_id: binary_sensor.dark_hall
to: 'on'
- platform: homeassistant
event: start
condition:
# Check it is dark (for when triggered by HA restart)
- condition: state
entity_id: binary_sensor.dark_hall
state: 'on'
# Check it is after 8am
- condition: template
value_template: "{{ states('sensor.time') > '08:00' }}"
action:
- service: homeassistant.turn_on
entity_id: switch.hall_light
And here is the sensor
- platform: template
sensors:
brightness:
friendly_name: 'Outside Brightness'
value_template: >-
{%- set elevation = state_attr('sun.sun','elevation') | float %}
{%- set cloud_coverage = states('sensor.dark_sky_cloud_coverage') | float %}
{%- set cloud_factor = (1 - (0.75 * ( cloud_coverage / 100) ** 3 )) %}
{%- set min_elevation = -6 %} {# set this to official sun elevation for end of twighlight #}
{%- set max_elevation = 62 %} {# set this to the maximum noon sun elevation (minimum is 15 degrees) #}
{%- set adjusted_elevation = elevation - min_elevation %}
{%- set adjusted_elevation = [adjusted_elevation,0] | max %}
{%- set adjusted_elevation = [adjusted_elevation,max_elevation - min_elevation] | min %}
{%- set adjusted_elevation = adjusted_elevation / (max_elevation - min_elevation) %}
{%- set adjusted_elevation = adjusted_elevation * 100 %}
{%- set brightness = adjusted_elevation * cloud_factor %}
{{ brightness | round }}
unit_of_measurement: '%'
device_class: 'illuminance'
*sorry @pnbruckner this seemed to work better for me than your illuminance sensor. Possibly that is because it uses the DarkSky cloud coverage percentage value rather than your values mapped to the icon? Although it is true to say that there are times when DS reports 100% cloud coverage (possibly as some kind of default value) when it is clearly not. (And I miss your ramping of values around dawn and dusk).
Maybe I’ve misread your example but I don’t see where the template sensor is used in the automation.
The template sensor’s friendly_name is ‘Outside Brightness’ and its entity_id is sensor.brightness.
- platform: template
sensors:
brightness:
friendly_name: 'Outside Brightness'
The automation does not refer to sensor.brightness. I assume there must be a configuration for binary_sensor.dark_hall that uses sensor.brightness?
As for sensor.brightness, what if the sun component is not available at the time the calculation is performed? What happens here to this line?
{%- set elevation = state_attr('sun.sun','elevation') | float %}
- I believe it will set
elevationto zero which will cause the calculation to report a very low brightness. - A low brightness value will cause
binary_sensor.dark_hallto indicate it is dark. - If it is dark, and after 8:00 AM, the automation’s action will be executed (hall light turns on).
1 Like
Just about to make some of the same comments as @123. Specifically, how is binary_sensory.dark_hall defined? And have you looked in home-assistant.log to see what the values of that sensor, and sensor.brightness, are when the automation is triggered? (Look for the corresponding state_changed events just prior to the automation triggering.) And you could also see what the state of sun.sun is as well. All the details to answer your questions are probably sitting there for you to look at.
I suspect sun.sun will be initialized by the time this template sensor is processed. But this is a good point about other things that go into it, especially Dark Sky. One way to deal with this is to use a delayed homeassistant start event. I use this:
- alias: Delayed Startup
trigger:
- platform: homeassistant
event: start
action:
- delay: 15
- event: DELAYED_HOMEASSISTANT_START
Then I use that event instead of the homeassistant start event directly.
Additional comments (you didn’t ask for 
):
Why not change:
- condition: template
value_template: "{{ states('sensor.time') > '08:00' }}"
to:
- condition: time
after: '08:00:00'
Maybe this is why you asked for a new max_elevation attribute:
{%- set max_elevation = 62 %} {# set this to the maximum noon sun elevation (minimum is 15 degrees) #}
1 Like
Can you explain why this works?
"{{ states('sensor.time') > '08:00' }}"
There is something going on here that I don’t understand. How can sensor.time’s state be compared to a string? Is there some sort of implicit type conversion happening?