Don't automatically convert states to strings in automations

pascallj commented 4 years ago

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

Now that we can use the numeric state and state triggers/conditions on attributes as well (home-assistant/core#41261), the frontend shouldn't automatically convert the from, to, above, below and state fields to strings as attributes don't necessarily have to be strings.

This could be classified as either a bug or a feature request, but as the current implementation isn't intuitive, I chose bug.

Expected behavior

If and only if an attribute is selected:

The fields above and below should never be converted to strings as they are always numeric values
For every other field:
- The values true and false should not be converted to strings
- Numeric values should not be converted to strings

Steps to reproduce

Add a numeric state trigger on sun.sun attribute elevation to be below 1 degree. It should be entered in YAML as:

platform: numeric_state
entity_id: sun.sun
attribute: elevation
below: 1

Environment

Home Assistant release with the issue: 0.116.0b3
Last working Home Assistant release (if known): Feature only works since 0.116.0b3
Browser and browser version: Irrelevant
Operating system: Irrelevant

State of relevant entities

Problem-relevant configuration

Javascript errors shown in your browser console/inspector

Additional information

github-actions[bot] commented 3 years ago

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.

pascallj commented 3 years ago

Nope the automation editor still screws these kinds of automations up so if saved using the editor afterwards, the automations don't work anymore.

github-actions[bot] commented 3 years ago

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.

bramkragten commented 3 years ago

We will probably remove attribute support from the UI editor

pascallj commented 3 years ago

Why if I may ask? Is there a better alternative?

This was one of the most useful changes since a long time. Almost every automation I have uses attributes in one way or another. Implementing this in the UI editor made it a lot more user friendly.

bramkragten commented 3 years ago

Because it is an advanced option, and making a good working UI for it is hard.

The alternative would be to show it as an YAML field.

github-actions[bot] commented 3 years ago

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.

pascallj commented 3 years ago

The bug is still there and attribute support is still present. If attribute support is going to be removed, maybe it's better to label this and related issues as 'wontfix' and be done with it.

bramkragten commented 3 years ago

This should still be solved

chilicheech commented 3 years ago

How is this already solved? I have the latest hass and the issue is still present..

System Health

version	core-2021.7.4
installation_type	Home Assistant Container
dev	false
hassio	false
docker	true
virtualenv	false
python_version	3.9.5
os_name	Linux
os_version	5.11.0-25-generic
arch	x86_64
timezone	America/Los_Angeles

Home Assistant Community Store

AccuWeather

can_reach_server | ok -- | -- remaining_requests | 49

Lovelace

pascallj commented 3 years ago

It's not. This issue still open.

github-actions[bot] commented 3 years ago

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.

pascallj commented 3 years ago

Hello bot, you're not you when you're hungry, here have some activity :chocolate_bar:

emontnemery commented 2 years ago

Fixed by home-assistant/frontend#10811

pascallj commented 2 years ago

The 'number case' for above and below seems to be really solved, as in it now even works when the number is enclosed in single quotes. I don't think that is solved by #10811 though, as far as I can see.

However the from and to 'state case' is bypassed. It only solves the fact that the automation editor screws up the automation every time you want to edit it because that block is 'not supported'. I really appreciate this is bypassed now.

However it is still counter intuitive that if you want to make an automation trigger on the 'rising' attribute of the Sun entity, that if you just enter true or false in the editor, it doesn't work. Of course there is the Sun trigger type for this specific case, but for any other boolean attribute or an exact number in a from and to trigger, you still have to use YAML.

emontnemery commented 2 years ago

@pascallj There's some discussion around your concern in https://github.com/home-assistant/frontend/issues/7708

home-assistant / frontend