Friendly names for binary_sensor states?

Configuration
1

Hi All,

I’m on the current version, and am happy that I can see friendly names for sensor states! For example, for a flood detector, I see my “binary_sensor.flood_1_water_alarm_water_leak_detected” sensor says “Dry” with a water drop icon with a slash when there’s no water, and “Wet” with a water drop icon with no slash. This is great, thanks to everyone who made that happen!!

Now, to my real question: When I make an automation for this sensor, when the sensor is trigged on water, the automation will work if I say the state is “on”, not “Wet”.That’s OK, I can live with that. After all, it’s a binary sensor - on and off are the only states.

But to make parity between the UI and the automation, I’d expect there may be some way to trigger the automation when “Wet” or “Dry” is detected. Is this something that exists, or would require a change?

I’d imagine that this would be important with sensors with more states. If an alarm has states of “triggered”, “exitdelay”, “ready”, “armed”, “disarmed”, etc. looking up this numeric, or “primitive” state name would be more difficult than using whatever the UI has decided to call the states. I had this issue recently with the EV4 integration. All my alerts worked, but I couldn’t find out that the “when the alarm is ringing” state was called “triggered”. That was easy enough to look in the integration docs, but whatever the UI said wasn’t “triggered”.

So please let me know if there is some way to use “friendly” states in automations and the Supervisor.

Thanks,

-Ambi

2

No. The state values an entity reports in Developer Tools > States are the ones you must use.

The so-called ‘friendly’ state values you are referring to are exclusively for display in the UI and are typically governed by the entity’s device_class.

3

You could always create an additional template sensor to do what you want e.g. something like this:

- platform: template
  sensors:
    leak02:
      friendly_name: Leak Sensor with Friendly State
      value_template: >-
        {% if is_state('binary_sensor.leak01', 'on') %} Wet
        {% else %} Dry
        {% endif %}
1 Like
4

Technically speaking, the state values of the new entity you have created are still the only values accessible to an automation. The values may be ‘friendlier’ but they don’t represent the ‘friendly’ state values the OP referred to (effectively the aliases that are displayed as a result of specifying a device_class).

Having said that, it might be a workaround that is acceptable to the OP (provided they don’t mind effectively duplicating every entity that they want to make ‘friendlier’).

5

What you see in the UI are governed by translation in accordance with your preferred language. It is in the frontend code IIRC.

6

Yep. The “friendly” names for binary_sensors are completely handled on the frontend side, based upon the language and the device_class of the sensor.

HA core itself only knows “on” /“off”.

7

These files demonstrate https://github.com/home-assistant/frontend/tree/dev/translations/backend

8

No. So say we all.

1 Like
9

I’ve been scratching my head over this one for a bit. The answer outlined above seems pretty clear. Automations only have access to the core values.

But, automations do interact with the user directly and could certainly make good use of the frontend’s translations. The clearest example I can think of, and the one I am fighting with now, is sending a notification that contains the state of a binary sensor.

Sure, in its simplest form, it’s not a problem. A leak detector is either wet or dry, so just hard code ‘wet’ or ‘dry’ into the message based on the current state of the sensor. But in the more general case, it’s not so easy. For me, the goal is to send a nicely worded notification when any of the sensors in my perimeter group changes. This group is all binary sensors, but the device class can be almost anything.

Has anything changed in this area that I might have missed? If not, is it possible for a python script to get at the frontend translations?

1 Like
10

I am more often confused by these “friendly” names :frowning:
I would appreciate a method to temporary disable this, and see everywhere only real values. For example when I look into the logbook, I can see some strings and I can’t find out what to put in an automation … since in development mode I can see only the current state value, not a value which was, e.g.: yesterday.
So … again, question: Is there any way to temporary disable this “friendly” names ?