Do not capitalize states in the more info dialog

Feature Requests
1

I’m a new (but enthusiastic) Home Assistant user. I’m currently trying to create my first automations.

The first thing I do when I create an automation is try to figure out how to trigger it. Which means I need to find an entity and determine what states it might be in. It seems that there isn’t much (or any) documentation about what states an entity could be in, so I have to resort to experimentation.

The most obvious way to experiment is to click on a entity (such as a sensor) and bring up the “more info” dialog. This dialog will tell you what state it is currently in, what states it has been in in the past, and what attributes are currently associated with the entity. As far as I can tell, this is also the only place in the lovelace UI where you can consistently and easily see what states something has been in in the past.

For example, if I bring up this dialog for my “sensor.zone_001” (a door sensor for my Elk alarm system), I learn that the current state is “Normal”. To figure out what happens to the state when the door is opened, I try it and find the new state is “Violated”. Cool. I go and write an automation triggered by the door going to state “Violated” and it works.

I then try writing an automation triggered by my alarm being armed. I bring up the dialog for “alarm_control_panel.area_001”. It tells me that the state is currently “Disarmed”. I arm the alarm, and it transitions to “Armed away”. So I write an automation triggered by the transition to “Armed away”. And it doesn’t work.

Why not? I resort to turning on debug logging and going through the logs. I find out that the state is not called “Armed away”, it is called “armed away”. The “more info” dialog lied to me. And triggers are case sensitive. So it doesn’t work.

So my feature request is to do one of:

  1. Standardize naming of events. They should be all lower-case, or all start with a capital letter, or follow some standard. If a single component (the Elk integration) is not consistent on this, then I don’t see how we can expect cross-component consistency.
  2. Don’t capitalize events when displaying them in the “more info” dialog. It may be pretty, but it is pretty confusing too.
  3. Don’t make triggers do a case-sensitive match to event states. Is there a strong benefit to this match being case sensitive? Do we expect any device to ever emit two events whose state differs only in case?

If folks can tell me which solution is best, I’m happy to implement this and send off the PR myself. (I suspect the answer is 2 or 3, as 1 seems crazy to implement and enforce.) But as a new user, I really don’t know.

Thanks!

Chris

2
  1. Don’t use the more info dialogue box to determine entity states. Use the Developer Tools / States menu.
3

I agree: the Developer Tools/States menu doesn’t capitalize them.

But it also doesn’t show you prior states. So there is no reasonable way of figuring out what states something like a momentary contact switch goes into when pressed using that approach.

1 Like
4

It does seem odd that trigger recognition would be case-sensitive, yet it is.

Does anyone know if there’s a reason it needs to be so?

5

It’s a Linux and Python based system. Both are case sensitive.

Not only that but in Home Assistant there is a difference between off and 'off'. The first one is a boolean value (which equates to false) the second one is the string “off”, and states are always strings. So make sure to quote ‘on’ and ‘off’ if using YAML (I think the frontend GUI editors take care of this for you but don’t really know as I don’t use them).

6

The OS and language don’t compel case-sensitive comparisons. The comparison is usually done via a library function call in whatever language one is using.
There are string-comparison library functions that offer case-insensitive compares, and case-sensitive compares.
Which one is used is a choice the programmer makes/made.

7

Yeah and the devs chose the default, which based on the language is case sensitive. Feel free to submit a PR to change this behaviour but I doubt very much that it would be approved.

8

Why do you predict it wouldn’t be approved? i.e. is there a clear and useful benefit to differentiating ‘On’ from ‘on’ in the case of states?

That they didn’t code it to be case-insensitive seems to violate the software-quality Principle of Least Astonishment (attributed to Steve Jobs).
Perhaps this is a good item for next year’s Month of WTH.

9

This is more of an issue of translation than it is of capitalization.

Those words which you say are “capitalized” are not simply capitalized but they are translated to the users language.

So arguing about whether or not they should be capitalized or exactly equal the backend state is only relevant for English users, for everyone else these displayed words are already nothing like the backend state. And I assume that is very intentional and not going to be reversed.