{% if now().hour >= 12 %}
Not exactly the same, but close enough. Or you could do:
{% set n = now() %}
{% if n.hour > 12 or n.hour == 12 and (n.minute or n.second or n.microsecond) %}
Also, the usual warnings about automatic entity extraction.
EDIT: Actually to be closest to what you had:
{% set n = now() %}
{% if n.hour > 12 or n.hour == 12 and n.minute %}
It works the way you are using it … but it is working for reasons that are not exactly what they appear to be.
This statement:
{% if states('sensor.time') > '12:00' %}
is not really comparing one time to another or even one number to another. It’s comparing one string to another. So it’s like this:
{% if 'rat' > 'cat' %}
That example seems to make less sense yet it is valid and will evaluate to true. Why? Because the letter r is higher in the alphabet than the letter c (specifically, its character-code is higher). You can prove it to yourself using the Template Editor:
{% if 'rat' > 'cat' %}
YES
{% else %}
NO
{% endif %}
Change ‘rat’ to ‘bat’ and the result will be NO.
This is what’s really happening when you’re comparing sensor.time's state to '12:00'. It works but only because the data happens to be “just right”. 
which is a very nice solution.
doing this myself:
- condition: numeric_state
entity_id: sensor.ha_uptime_minutes
above: 1
and yes, I recognize the need for this when using binary_sensors as triggers, that fire upon startup…
Using an uptime sensor can definitely be useful in certain situations.
However, your example is a condition, not a trigger. The discussion was about delaying the triggering of an automation that you want to trigger right after startup. Of course, you could do it with an uptime sensor, too, like this:
trigger:
- platform: numeric_state
entity_id: sensor.ha_uptime_minutes
above: 0
Which would trigger one minute after HA starts.
The thing about this is that this trigger will be evaluated every minute, (i.e., whenever sensor.ha_uptime_minutes changes) from the time HA starts to doomsday, whereas a delayed start event will only be processed once, when the event happens. Still, what’s a few CPU cycles between friends?! 
Back to the original subject for a moment…
I used to get one of these messages for the sun component; now I am not…
You are using a custom component for life360.device_tracker which has not been tested by Home Assistant.
Yes, I’m just noticing that myself. (I have a checkout of the dev branch I’ve been testing this on. Also discussing this in another forum topic.)
It’s looking like this is the right thing to do…
Assuming you have my sun.py component in custom_components, then try this:
cd custom_components
sudo -u homeassistant mkdir sun
sudo -u homeassistant mv sun.py sun/__init__.py
sudo -u homeassistant ln -s /srv/homeassistant/lib/python3.5/site-packages/homeassistant/components/automation/sun.py sun/automation.py
Then restart. Also note that you may need to adjust these instructions depending on how you installed HA and what version of Python you’re using.
The idea is to turn the sun.py module into a package, and then to make the automation’s sun platform part of this package. (I do it here via a symbolic link, which should automatically “pick up” new versions. But you could also do it by copying the file.)
If you try this, please let me know how it works for you.
I’m on hassio so I can’t do that last line.
I can do the rest manually…
And what are the implications of not doing this?
It all seems to be working (apart from not getting the warning message).
Fwiw, I’ve recently learned the automation isn’t set to be triggered if a condition isn’t met and the action isn’t called because of that…
So theoretically you are absolutely right, but there won’t be an attribute last_triggered if the condition part is evaluated False.
Can you copy the file? If not, can you get it from github?
I haven’t thoroughly investigated yet, but the new loading system seems to be having trouble with automation’s sun platform (i.e., <homeassistant>/components/automation/sun.py) when there is a custom version of the sun component. It wants the custom sun component to be a “complete package”, including automation’s sun platform. Without it there are errors and/or automations with sun triggers might be silently turned off.
Sorry, not following you. Triggers and conditions are two different things. Triggers control when the automation action(s) should run, whereas conditions control if the action(s) will run when one of the triggers fires. The last_triggered attribute just records the last time the action(s) were run, whether due to trigger/condition processing, or by the automation being manually triggered (via the automation.trigger service.)
Exactly! Last_triggered doesn’t record the last time the automation was triggered, but the last time actions were run.
I had an automation with a condition the last_triggered of that automation needed to be >120. Since that condition was never met, the attribute last_triggered was never set. And the automation never ran. Catch22
Moving all conditions to the action part solved the issue, and now all runs perfectly well.
So the attribute last_triggerd should really be called last_action_ran…
I always expected the attribute to be set on triggering of the automation…
see Find the error in: automation last_triggered with now() or timestamp templates - #29 by Mariusthvdb for the exact issue I had solved finally.
this solution has another great advantage: one can check the conditions upon manually triggering. With the condition in the condition part of the automation, manually triggering would jump over the conditions to the action part immediately. Moving these conditions to the action part, evaluates these conditions too, so one can see if the automation works as designed…
Ah, ok. I understand. Yes, this isn’t the only place where terms are overloaded in HA. “State” and “trigger” are definitely two terms that have multiple meanings depending on how they are used. “Attribute” is another one.
Sorry Linux isn’t my area of expertise…
I looked up ln and I am guessing that in lieu of creating a link you want me to take a copy of the HA file sun.py from GitHub and put it into my local custom_components/sun folder?
So, yeah, I can do all that. The concern I have is how I will know when/if I can put it all back to how it is ‘supposed’ to be. And if I can’t what happens if the core sun.py component is ever updated?
Something seems to me to be not quite right with all this…
(And I don’t mean your custom component.)
one more thing about this, then Ill leave this thread to the topic… sorry @klogg
would that be done by using this trigger then?:
trigger:
- platform: homeassistant
event: delayed_homeassistant_start
Yes, get a copy of https://raw.githubusercontent.com/home-assistant/home-assistant/0.88.1/homeassistant/components/automation/sun.py (adjust the link if you’re using a different version of HA) and put it in custom_components/sun, renaming it from sun.py to automation.py.
For custom components, this is now how it’s “supposed to be.” They purposely decided to make using custom components more complicated. They thought it was a good idea, but I suspect they didn’t realize how much of an effect this would have. But, it is what it is, and hopefully it will be better in the long run (which I’m sure was the thinking.)
First, I tried to update the standard sun component, but it was rejected. They don’t want to update it anymore. They want to replace it, but nobody has signed up to do that AFAIK. (Look back in this topic and you’ll see what I’m talking about.)
But, if you ever want to go back to the standard sun component, simply delete the custom_components/sun folder and restart. Presto magico, you’re back to the standard sun component!
I know this isn’t a great situation, but it’s due to the “great migration”, and there’s not much I can do about it, other than try to figure out how to deal with it.
It’s case sensitive I believe, and you need to use an event trigger, not a homeassistant trigger:
trigger:
- platform: event
event_type: DELAYED_HOMEASSISTANT_START
If you want to use it lower case, then change it in both places.
Sorry to labour the point but if it is important which version of HA I am on, what will happen when I next upgrade (he says, wondering if it is sometimes a misnomer 
)?
Don’t worry, it’s been interesting!
thanks for your understanding 
I’ve learned a lot in this thread, one of them being I won’t update to 0.88 just yet…
Well, if you used a symbolic link…
The funny (“funny” as in “sad”) part of this is the automation sun platform doesn’t actually use the sun component! Both the sun component, and the automation sun platform, use the sun helper (homeassistant/helpers/sun.py). So this is all “make work” for no good reason.