Why does this condition keep giving me errors?

Thank you, it made it through the config check.

good to hear.

I think it treats the quotes in groups from left to right so all it saw was, "{{ trigger.topic.split("

I have found it useful to always use double quotes on the outside of the {{ }} and singles for anything inside the {{ }} .

3 Likes

Yah, a word of advice, don’t use a generic text editor. Use something like notepad++ to view your configurations. quote manipulation will stand out. For example take a look at what you wrote using the markdown on this forum:

value_template: "{{ trigger.topic.split("/")[3] == 'device_class' }}"

Notice how you have 2 red sections separated by a black slash? That essentially shows you what the parser sees. 2 strings with a non-string in between.

Now take a look at @silvrr solution.

value_template: "{{ trigger.topic.split('/')[3] == 'device_class' }}"

One large string!

Text editors easily point this stuff out visually. Always good to use something that understands yaml.

2 Likes

Next to that, I’d suggest to take it a little further and use the multi-line notation, to prevent errors with those quotes in the first place. Make life easy (as possible…):

value_template: >
  {{ trigger.topic.split('/')[3] == 'device_class' }}

Yep, because it helps even more by splitting up your code when using something that displays markdown:

value_template: >
  {{ trigger.topic.split('/')[3] == 'device_class' }}

See how numbers, strings, and objects/methods are all different colors?

I never understand why you show colors and I don’t…:frowning: though I use the <> and have colors in my editor?

Thats why!

using ` x3 (top left most button on keyboard below escape, typically also has the ~ button on it)

# this will markdown like python, remove word python to just use general markdown
print('hello world')

not on a MacBook air it is :wink:

value_template: >
  {{ trigger.topic.split('/')[3] == 'device_class' }}

bingo!
cool, thanks!

1 Like

image

2 Likes

now that I have you here on templates… please allow this distantly related question:

using this:

    laundry_schedule_night:
      friendly_name: Laundry schedule night
      value_template: >
        {{states('sensor.laundry_schedule')[1:-13]}}
    laundry_schedule_day:
      friendly_name: Laundry schedule day
      value_template: >
        {{states('sensor.laundry_schedule')[11:-3]}}

gives me:

13

based on:

would there be a better way to template these times out of the mother sensor. Using .split or some other jinja technique? I can split at the / but then I would still need to cut the last :00 and starting T…

or maybe even one step extra back: these mother sensors are created with this:

- platform: command_line
  name: Laundry schedule
  command: curl -X GET http://192.168.1.212/api/API/rules/93
  value_template: >
    {{ value_json.conditions[0].value }}

so maybe change the value_template?

hop over to Hue motion sensors + remotes: custom component for the full thread…

I mean, if the mother sensor never changes it’s format, then no reason to change it.

Otherwise you could do:

{{ states('sensor.laundry_schedule').split('\\')[0][4:] }}

and

{{ states('sensor.laundry_schedule').split('\\')[1][4:] }}

not really:

changed your second template cause that results in

Error rendering template: UndefinedError: list object has no element 1

There is a forward slash (’/’), not a backslash (’\’) in there, you might want to change split('\\') to split('/') :wink:

Yah, used wrong slash

sorry for that…

but, had to change anyway:

{ states('sensor.laundry_schedule').split('/')[0][1:-3] }}

{{ states('sensor.laundry_schedule').split('/')[1][1:-3] }}

{{states('sensor.laundry_schedule')[1:-13]}}

{{states('sensor.laundry_schedule')[11:-3]}}

57

is this just a formatting thing, or would you prefer one fo these above the other, and if so why?

if the data changes shape, then you’d want to go with the method I posted. If it’s always the same, either works fine and it’s up to you.

a yes, of course! clever… Don’t think it will ever change, how could it in fact, but will change to your setup anyhow. Like the rationale behind it. intelligence vs brute force.cool.

1 Like

I got my project working, thanks again.

I’ve just lost a few hours searching for a solution to the same problem. Even an example on the Home Assistant documentation has it wrong (https://www.home-assistant.io/docs/automation/condition/):

      - condition: template
        value_template: '{{ state_attr('sun.sun', 'elevation') < 4 }}'

I would like to modify the documentation, but I’m not familiar at al with github :frowning:
PS: http://www.yamllint.com/ is also a good place to check your yaml

I put it in https://github.com/home-assistant/home-assistant.io/pull/11688