Because, like the states of all entities, sensor.time’s state is a string. However, I would never do this because it depends on string comparisons which can sometimes give unexpected results. In this particular case, it probably works ok though.
I wouldn’t be surprised. My sensor uses an algorithm that someone else came up with that I used on SmartThings before moving to HA. I’ve given up on it, too. First because WeatherUnderground’s API is going away (if it hasn’t already), and neither Dark Sky nor YR seem to be as accurate as WU. Second because I finally broke down and bought an Aeotec MultiSensor 6 which is way better for accurate, real time sensing of the outside light level (and the PIR sensor comes in handy, too.)
1 Like
Thanks!
That’s what I assumed was happening (string comparison) … which makes me wonder why one would use greater than to compare strings in this situation? It’s actually doing a lexical order comparison (i.e. where “b” is greater than “a”) which seems like a roundabout way to compare two time values!
One of those situations where “it won’t fail if you use it just right”. 
@123 (and to some extent @pnbruckner but you’ll get specific comments in a minute )
Yes, binary_sensor.dark_hall does use sensor.brightness, as do other binary_sensors for other rooms with each room having it’s own threshold above which it is considered dark.
Your explanation makes sense and may be the answer (notwithstanding @pnbruckner’s comment).
I only recently added the HA start trigger and as I mostly restart HA when it is dark the behaviour has always appeared to have been as I expected.
@pnbruckner This is an interesting idea, I might look into using this.
As for your un-asked for comments, consider there being a standing invitation for comments! The time condition must be throwback to some weird ideas I had when I first started with HA. I will be changing this immediately, and yes I think that might be why I asked but I am not now sure if a max elevation that changes during the year is appropriate for that sensor.
Thanks to both of you.
2 Likes
+1
I’ve been using two physical light sensors (not Aeotec but hard-wired sensors) for many years to calculate darkness (one is indoors and the other outdoors).
Many weeks ago, I discovered the illuminance sensor, based on Dark Sky values, and decided to give it a try. I compared the graph produced by the illuminance sensor to the graph from my outdoor light sensor. Conclusion: the illuminance sensor is better than nothing but not nearly as good as using a local, physical light sensor.
2 Likes
The use of
value_template: "{{ states('sensor.time') > '08:00' }}"
was a definite aberration of which I am slightly embarrassed but with Python still being a little alien to me I have to admit that I definitely struggle with dates and times.
I am guessing you would both also shudder at this, 
{% if states('sensor.time') > '12:00' %}
which is a form I have used quite a few times in my templates. Can you suggest a better alternative? Unless you particularly want to, an explanation isn’t necessary, given the right syntax I can go away and look it up.
Thanks 
{% 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 %}
1 Like
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”.
1 Like
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?! 
1 Like
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