Zones & "Not Home", also single quotation marks

Configuration
1

So I’ve recently started using zones, so instead of just home and not home, there are now an array of different options for where I might be. I’m wondering how I need to adapt my config for that. For example, if Life360 doesn’t notice I’ve left home until I’m already in the zone for work (skipping the ‘not home’ state) how will home Assistant deal with that? Does it still apply “not home” logic to a named zone, or does being in a named zone overrule “not home” ?

Also,I’m a bit confused about single quotation marks. Should it be

  - alias: 'Router location backup Mary'
    trigger:
      platform: state
      entity_id: device_tracker.maryphone
      to: 'home'

or

  - alias: 'Router location backup Mary'
    trigger:
      platform: state
      entity_id: device_tracker.maryphone
      to: home

thanks!

2

if you are in a zone you can still use not_home in automations. And you can use both ‘home’ and home. Or ‘not_home’ an not_home.

3

Are you sure about that?

I thought you always had to enclose all strings in quotation marks but didn’t use them when using numbers.

4

I’m sure. I use home and not_home in my automations without quotes. But for more consistency you could use quotes if you want.

5

well I guess I’m confused too.

Thanks :wink:

6

Something really weird is happening. It seems to be since the power cut I had earlier in the week (but I might be making links where there are none). Basically presence detection has been really, really weird this morning. I have a group each for me and my wife (two device trackers in each, life360 and monitor). Basically monitor seems to be reporting correctly in the background using the confidence value, but the sensor which confidence informs ISN’T updating to Home/Not Home…however, the group is behaving as if it IS updating. Anybody come across anything like this before? I’m really confused as to where to go from here…

7

I don’t know, i don’t use life360 or monitor. Do you have any errors in your log? Did you update HA? What version are you on?

8

dont confuse the trigger to: with the conditions in templates, where quotes are required though.

{{is_state('device_tracker.life360_phone', home)}} will always be False…

      - condition: template
        value_template: >
          {% set zones = states.zone | map(attribute='name')|list %}
          {{trigger.to_state.state in ['home','not_home'] or
            trigger.from_state.state in ['home','not_home'] or
            trigger.to_state.state in zones or 
            trigger.from_state.state in zones}}

would help you using zones :wink:

9

I’m SLIGHTLY now wondering if it’s got something to do with the way after the power cut when my Pi booted up again, all my automations were off. I then used a service call to turn them all on again at once. I wonder if that service call malfunctioned in some way. Because looking at the automations, they are showing last_triggered: null even though they are nominally ‘on’ and worked without fault before

10

the last_triggered attribute is only set when the action part of the automation has been fired. It has nothing to do with the automation being ‘on’. (well, of course the action isn’t fired when an automation is ‘off’… )

11

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

12

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

13

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
14

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.

15

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.

16

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.

17

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.

18

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'
19

I’ll add my “2 cents” here… :slight_smile:

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. :wink:) 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
20

You think that was only worth 2 cents?

1 Like