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
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
from: parameter, since in this case it would not be transitioning
from: not_home or
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 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
'on' will stay the string
Another area of concern are time strings, such as
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.