Thanks - I know - the point I’m making is these automations SHOULD have fired, they normally fire - but since the power cut they haven’t been
Add this line to all automations and reboot;
initial_state: true
This will make sure the automation is on after reboot.
Check if it fixes your issue
please note, that the triggering if the automation (one of the triggers is true) doesn’t immediately set the last_triggered of the automation. If the condition section of the automation is evaluated to False, it won’t of course fire the action section, and the last_triggered attributes won’t be set…
it is a confusingly named attributed.
And @Pippyn is right, if you want 100% certainty use initial_state. I don’t like that at all, and previously relied on restore_state. But since that has been changed to rely on the .storage, things have gone astray, and restore_state as we knew it has become unreliable for automations…
1 Like
I always thought they were required in both places since both were evaluating strings. Apparently I was wrong.
I really don’t see the difference in the requirement. If the quotes are required in one spot they should be required in both or not required in either. It seems the goal of “consistency” even at this basic level is lacking.
I think the difference is due to what is interpreting the strings. In one case it’s the YAML parser and in the other case it’s the Jinja2 interpreter.
egad. Consider my world rocked. It’s a shame no errors are thrown for this anywhere! About 20% of my automations lacked quotation marks for conditions, which I now gather are 100% necessary? Thought some of this select group of automations have worked without them but maybe not.
Don’t conflate the needs of Jinja2, within the value_template, with the needs of other aspects of conditions. The YAML parser handles conditions whereas the Jinja2 interpreter handles templates. So be sure to quote strings within templates.
As for the YAML parser there is one exception I know of where quoting the string makes a difference. Home Assistant has key words that hold special meaning. The key words have synonyms. For example, false, False, and off mean the same thing. Here’s an example from the configuration of my climate component:
modes:
- auto
- heat
- cool
- 'off'
The YAML parser interprets that as an array of strings. Delimiting the words with quotes is optional … except for off. The quotes ensure off is interpreted to be a string and not as a key word with special meaning.
If you’re concerned you might make a mistake then feel free to delimit all strings in YAML with quotes. However, it’s not 100% necessary. In Jinja2 (i.e. in templates) it is.
quite. And to add to that, using unquoted off here won’t lead to an error, but simply an unexpected result… it would show as False probably and not do what you want it to do. So no configuration checker would choke on that, not even the built-in checker in Hassio, which is the most reliable checker I suppose.
btw, just to not miss it: if you need special characters in Yaml, or even a quote itself, you do need quotes
something like this won’t work:
perc_outdoors_brightness:
icon: mdi:spotlight-beam
max: 100
min: 0
name: % Outdoors brightness
and would need to be:
perc_outdoors_brightness:
icon: mdi:spotlight-beam
max: 100
min: 0
name: '% Outdoors brightness'
I’ll add my “2 cents” here… 
If a state trigger has only to: home (as in the example in your OP), then zones don’t matter for that particular trigger (well, other than zone.home of course) since you didn’t specify from:, and therefore, it doesn’t matter what the previous state was (i.e., not_home or a zone name.) To put that another way, it doesn’t matter if the state changes from not_home to home, or from a zone name to home, because you only qualified the state transition with to: home, which is true in either case.
Where the scenario you described might affect an automation’s triggers is if you specified not_home in either the to: or from: parameter, since in this case it would not be transitioning from: not_home or to: not_home.
Does that make any sense?
BTW, whether or not a value should be quoted is actually a bit complicated. It depends on the YAML parser (which, I’ve heard rumor of, is changing), possibly Jinja processing (if you’re using a template), and lastly the schema in the code that can convert between types, which depends on the exact use case.
But in general, the biggest issue has been YAML converting certain unquoted strings to boolean, such as true, false, on, off, yes and no, including the all lower, all upper or title cases of these words. (E.g., on, ON and On will all get changed to the boolean value true, but oN will stay a string.) So if you need to use one of these words and you want the value to stay a string – e.g., in a state trigger for a binary_sensor – then you need to quote it. Otherwise YAML will convert it to a boolean value, and then the schema will convert that boolean value to a string. So, on will ultimately get changed to 'true', whereas 'on' will stay the string 'on'.
Another area of concern are time strings, such as HH:MM or HH:MM:SS. In some cases these will be rejected if not quoted, but I’m not sure of the details. It’s just easier to always quote these.
Lastly, if you’re thinking, heck, I’ll just always quote everything, not so fast pardner! There are some cases where this can bite you in the butt. E.g., some things need a number, not a string representation of a number. (This can be especially bad when trying to use a template, because templates can only return strings.) So sometimes xyz: 123 will work where xyz: '123' won’t. But in general, schemas usually properly handle this and convert string representations of numbers to actual numbers. (IMHO, if they don’t, then that’s a bug.) But, again, you have to be careful, because if something wants an integer (as opposed to a float), even when the schema “coerces” the value into an int, you can still get into trouble. E.g., in this case xyz: 123, and xyz: '123', and xyz: 1.23 will work, but xyz: '1.23' won’t! This is ultimately because the Python int() function can take ints, floats, and string representations of ints, but not string representations of floats.
Clear as mud?!
Don’t get too discouraged (or outraged. 
) In general the code is designed with a lot of slack and things will generally “just work.” Again, the biggest issues are usually the YAML conversion of certain strings to boolean, and time values.
2 Likes
You think that was only worth 2 cents?
1 Like
1 cent?
I THINK I’ve just come across an automation which hasn’t been working because of single quotations.
- alias: Mark Steve as at work
trigger:
- platform: state
entity_id: device_tracker.life360_steve
to: 'PepsiCo'
for:
minutes: 30
condition:
- condition: time
after: '07:00:00'
before: '09:00:00'
action:
- condition: state
entity_id: input_boolean.stevework
state: 'on'
hasn’t been firing. Going to update to “PepsiCo” rather than ‘PepsiCo’ and see if that does the trick. And yes, if I go to my developer tools>states, I did indeed change to PepsiCo at 08:35
I’d be surprised if switching from single to double-quotes makes a difference for delimiting a simple string like PepsiCo.
Are you using 0.89? Life360 is a custom component and requires adaptation for 0.89.
Nope - 0.87.1 - as I say, the component itself is working fine.
OK, let us know if changing to double-quotes makes it work … but I doubt that’s the cause of the automation’s failure.
In most cases, simple text to the right of to: is treated as a string (even without quotes) provided the simple text is not a key word. The addition of either single or double quotes is to ensure it is evaluated as a string.
no action defined?..
1 Like
The issue here is not quoting. In this case (as others have already pointed out) PepsiCo can be quoted with single quotes, or double quotes, or no quotes at all.
The issue is the state changed to PepsiCo at 08:35, but you have for: minutes: 30 and conditions that the time must be between 7 & 9. But 30 minutes after 08:35 is 09:05, which is not between 7 & 9!
When you use for: on a trigger, the trigger event doesn’t happen until the for: period has been satisfied. That’s the time the conditions need to be true, not when the state first changed.
1 Like
thanks and thanks also to @Mariusthvdb
I’ve amended BOTH my time condition AND my action!!
- alias: Mark Steve as at work
trigger:
- platform: state
entity_id: device_tracker.life360_steve
to: "PepsiCo"
for:
minutes: 30
condition:
- condition: time
after: '07:00:00'
before: '09:30:00'
action:
- service: input_boolean.turn_on
data:
entity_id: input_boolean.steveworkWell, hell, I thought the OP just chose to not show the balance of the action (because the focus was on quotes in trigger. But yeah, the action as shown is … no action at all!
@daneboom
This example’s failure has absolutely nothing to do with single/double/no quotes.
Now that you’ve added a valid action, and understand how for interacts with the condition's time-frame, revert "PepsiCo" to 'PepsiCo', or even just PepsiCo to prove to yourself that quotes had nothing to do with your automation’s failure.
Quote are only required in YAML when you need to clear up ambiguities. For example keywords like true, false, on, off where you need to differentiate between an actual boolean and a string or if you use certain special characters in the beginning/end of the string. Jinja templates are an entirely
different “language” with it’s own requirements.
None of these requirements has anything to do with Home Assistant, they are the result of the underlying architecture.
Some basic info on this page. http://www.thomasloven.com/blog/2018/08/YAML-For-Nonprogrammers/
1 Like