Cannot match on Boolean values when creating an automation in the Frontend

[ZuluWhiskey]

Checklist

• [x] I have updated to the latest available Home Assistant version.
• [x] I have cleared the cache of my browser.
• [x] I have tried a different browser to see if it is related to my browser.

The problem

When creating an automation in the frontend for an entity which has a Boolean value as its state, the UI adds quotes around the value. Even when editing the YAML (via the frontend) it then adds quotes when you save the automation.

Expected behavior

Expected that the frontend would allow for strings and Boolean values for entity states.

Steps to reproduce

1. Create a new automation.
2. Using an entity which has a Boolean value as its state, set the trigger as (for example) to: True.
3. Select "Edit as YAML"
4. The UI has added quotes
5. Remove the quotes
6. Save the automation
7. Go back into the automation
8. Select "Edit as YAML" again
9. The quotes are around the Boolean value again

Environment

• Home Assistant release with the issue: 0.117.6
• Last working Home Assistant release (if known): Unknown
• Browser and browser version: Safari, Chrome
• Operating system: iOS, Windows

State of relevant entities

Problem-relevant configuration

Javascript errors shown in your browser console/inspector

Additional information

[frenck]

A state is a string, always. Our state engine works only with strings. If you set another type for a state value, it will be converted to a string. Even when using pure YAML.

[ZuluWhiskey]

A state is a string, always. Our state engine works only with strings. If you set another type for a state value, it will be converted to a string. Even when using pure YAML.

Apologies as I definitely wasn’t clear / completely omitted the fact that this was a state attribute. I should’ve provided my example...

I have a Phillips Hue motion sensor connected via DeCONZ and this exposes an entity for the light level of said sensor. The light level entity has an attribute called dark which shows as either true or false. I tried to create a condition within an automation in the UI for this state attribute being true, however it did not work. After some troubleshooting I discovered that even though the Dev Tools —> States showed the attribute as true (lower case) when I used Dev Tools —> Template to extract the state it was showing as True (uppercase T indicating a Boolean value). If I then did {{is_state_attr('sensor.lightlevel','dark','true')}} this returned False. If I instead did {{is_state_attr('sensor.lightlevel','dark',True)}} this returned True, this confirmed this state attribute was indeed a Boolean value.

So I then attempted to follow the steps to reproduce (above) for this state attribute in the UI and got the error I described.

So is this an error with the DeCONZ integration perhaps? Or are state attributes (not the states themselves) able to be Boolean values rather than strings when they should not be?

Apologies again for my lack of description ‘ clarity.

[frenck]

States are strings, but state attributes are type aware.

Could you share an example YAML we can use for re-producing your issue?

[ZuluWhiskey]

States are strings, but state attributes are type aware.

Could you share an example YAML we can use for re-producing your issue?

Unfortunately it's not really something I can share to replicate via YAML as such, I can share a video of me setting up the automation and the addition of the quotes around the value perhaps? Technically if you paste the below into an automation trigger in the UI (using the "Edit as YAML" option):

platform: state
entity_id: sensor.hallway_lightlevel
attribute: dark
to: True

And then change back to "Edit with UI" and then change back to "Edit at YAML" again, it will then look like this (note that there are now quotes around True):

platform: state
entity_id: sensor.hallway_lightlevel
attribute: dark
to: 'True'

It is therefore assuming the entity attribute is a string and not anything else (in this case a Boolean value). This trigger will therefore never fire when dark changes to True as it isn't a string but a Boolean value.

This can be easily circumvented by using a Template Trigger {{is_state_attr('sensor.lightlevel','dark',True)}} but this means that the (recently) new functionality of being able to trigger on attributes of an entity doesn't fully work from the UI as a user would expect.

Personally, I can deal with this issue as I'm now aware but anyone who isn't aware of this would have a real problem if they went to set up an automation trigger or condition using the UI as it would never trigger the automation or return as True in the case of a condition.

[meros]

I encountered this as well...

[ZuluWhiskey]

I found a similar issue again recently. I have the Tautulli component and wanted to trigger when the WAN bandwidth changed to 0 (ie. no one is watching content remotely) but Home Assistant saw the 0 as being False and not an integer/string so I had to create a template for the trigger instead rather than just being able to use the State trigger.

When the bandwidth goes above 0 then it is recognised as an integer.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[ZuluWhiskey]

Still an issue unfortunately, can only use templates for a number of my automations that look at state attributes.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[ZuluWhiskey]

Still an issue in 2021.8.3 unfortunately 👎

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[ZuluWhiskey]

Still an issue with HA 2021.10

[jak119]

Came looking to see that there was an issue open about this as it trips me up every few months when I inevitably forget about this. I can also confirm that as of 2021.10.3 this is still an issue.

Steps to reproduce

1. Create a new automation using the GUI

2. Add a condition looking for a specific state that's a boolean (see below for example)

3. Save the automation

4. Observe the created YAML now includes 'false', for the block in the screenshot specifically

condition:
  - condition: state
    entity_id: calendar.xx
    state: 'false'
    attribute: all_day

Expected Result

I think that @ZuluWhiskey has covered that pretty thoroughly, but I'd expect that the resulting YAML be

condition:
  - condition: state
    entity_id: calendar.xx
    state: false
    attribute: all_day

My thoughts on a fix

As @frenck mentioned above

States are strings, but state attributes are type aware.

Since that's the case I'd expect / suggest one of these three methods to help the frontend accommodate that

• A way to specify the type
• Have true and false be assumed to be booleans
• Some extra logic to check the type of the attribute and use that to inform the frontend how to generate the YAML

If true and false are assumed to be booleans then perhaps an escape character could be used to indicate to the frontend that they're literal strings.

[jak119]

I did a little more digging in this repo's and it seems that this is the same, or similar, to what's described in #9753 and #9362

[ndrwstn]

As of 2021.11.5 this is still an issue. Trying to use a conditional as an action and match an entity's brightness attribute to a value, the value is wrapped in single quotes and therefore doesn't match (numeric vs. string, I assume). Screenshot from a trace below:

Troubleshooting with help from the discord, I tried to edit the yaml via UI which resulted in the same single quote issue. I needed to edit the automations.yaml file directly to resolve.

I think this is also related to #9144 (script editor) and is identical to #8029 (which was closed as stale).

[dgtal1]

This is still an issue in 2021.12😔 This must be at least stressed out in the docs as it's very confusing and fresh HA users will struggle. Shame the frontend automation editor is not type aware.

[dgtal1]

To be clear: it's not only relevant to boolean attributes, but to all attribute types. In my case my automation didn't trigger because I have an int state attribute and I had to switch to YAML editor to fix this and remove the quotes around my value

[emontnemery]

This has been fixed in 2021.12 by #10811, setting a to- or from-state to a non string in yaml prevents opening the visual editor for that section of the script:

@dgtal1 can you provide a step-by-step description of the problem you see in 2021.12?

[ZuluWhiskey]

This has been fixed in 2021.12 by #10811, setting a to- or from-state to a non string in yaml prevents opening the visual editor for that section of the script:

@dgtal1 can you provide a step-by-step description of the problem you see in 2021.12?

I've just checked and it is indeed fixed, however I would say that it isn't too intuitive - From the UI you would type in True, then you have to switch to YAML mode, then remove the quotes around True that the UI added automatically and then you'll get an error saying you can't edit the value via the UI. Or am I missing something here?

EDIT: For clarity, I'm fine with this as I now know the workaround described above but for someone new to HA it isn't user friendly

[dgtal1]

@emontnemery I actually meant that the UI editor is still adding quotes around non-string attributes making the trigger useless as it will never fire in this case. The workaround @ZuluWhiskey mentioned is only...a workaround. And I fully agree - it's not intuitive. Especially for new HA users. They won't know what the type of an attribute is and will probably assume all of them are strings. Automations created this way from the UI won't fire until they remove the quotes from the attribute value.

I suggest to issue a warning already at the time user picks an attribute in the UI editor - then check the type and issue a warning if it's not string or switch to YAML mode immediately for this automation section.

Aditionally I think adding some short explanatory text (or at least a link to some docs) at the top of the UI automations editor about the current constaints is a must to make people aware of this issue.

Hopefully one day the attribute types will be supported by the frontend editor.

[emontnemery]

I suggest to issue a warning already at the time user picks an attribute in the UI editor

That's maybe reasonable

then check the type and issue a warning if it's not string or switch to YAML mode immediately for this automation section

I think the user experience will be very poor, and we can't expect that a non-programmer user understands the difference between True and "True" or between "123" and 123. To make things worse, YAML is the language from hell which silently stringifies user input meaning abc will be parsed as "abc", while it also has a rich flora of boolean synonyms: on, ON, On are all parsed as true.

Maybe it would be better to do either of:

• Simply not allow referencing attributes in the visual editor for state triggers
• Revert https://github.com/home-assistant/core/pull/41261, that's the backend change which is the root of all this
• Add a new state trigger option "attribute_as_string" or similar, which stringifies the state attribute

[dgtal1]

Maybe it would be better to do either of:

• Simply not allow referencing attributes in the visual editor for state triggers

No, I think that this should still be supported. Any help/aid from the UI editor is an aid and speeds up automation creation without a need of opening multiple HA windows and checking states, their exact attribute names etc. That should stay in my opinion, but its constraints should be clearly highlighted (warning text with some link to docs about this), so people knew what is and what is not supported here. Removing quotes is still easier that checking the exact entity state attributes' list and names.

• Revert Allow any value when triggering on state attribute core#41261, that's the backend change which is the root of all this

I think this adds a lot of flexibility to automations and in my opinion it should stay.

• Add a new state trigger option "attribute_as_string" or similar, which stringifies the state attribute

Yeah, maybe this one, but I also don't like it. It's more a workaround than a real solution. I know a proper fix for this issue is complicated. But it's usually like this - making complex things easy&user-friendly is most challenging.

I think for now the right thing is to add a warning when the UI editor detects an unsupported situation or if that's already too complex - add a clear short description with a link to docs in automations editor stating the current constraints, so people could avoid issues (triggers not firing, conditions not met) when defining automations based on state attributes.

[emontnemery]

add a clear short description with a link to docs in automations editor stating the current constraints, so people could avoid issues (triggers not firing, conditions not met) when defining automations based on state attributes

Maybe we could try to detect when the user's input could be parsed as a number or bool, and warn then 🤷

[emontnemery]

I discussed this with @bramkragten a bit, another option would be to show the for + to fields as yaml inputs when you select an attribute

[dgtal1]

I discussed this with @bramkragten a bit, another option would be to show the for + to fields as yaml inputs when you select an attribute

Yeah, that actually sounds pretty good. Good idea - it leverages current features and keeping the UI user friendly.

[dgtal1]

I'd keep the current warning, though and maybe adapt it a bit to reflect this better.

[emontnemery]

The attribute picker is already aware of entity attribute names meaning it needs to somehow read entity state, so why is it a problem to check their types and put the right value in YAML in line with its type? At least for a basic, most common set of possible types e.g. int, float, maybe timestamp

It's a good idea, but an entity's attributes are not always there, so if editing the automation when the attribute is missing the editor would not have the right information. If an entity is in "unavailable" or "unknown" state, for example, most attributes are not there. Similarly, a light which is turned off does not have color related attributes in its state.

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[dlakelan]

I just hit this issue in trying to trigger on whether the sun was rising or setting. See related topic on the forum:

https://community.home-assistant.io/t/automation-based-on-sun-angle-not-triggering/402895

I found this highly unintuitive. Even when I was building the automation, I didn't know what to put in the box: true, on, yes? how do you do a boolean and not a string? is there even a difference in interpretation between a boolean and a string? I suspected there would be, but couldn't find any documentation that discusses it. Eventually the community helped me figure it out, but there should be some docs on how to match a boolean vs a string vs an integer vs a float etc, that's super obvious to be able to find via google

[github-actions[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.