Nomenclature confusion - on/off, true/false, detected/clear

Hi, I’m trying to move away from Device triggers to State triggers in automations and I’m somewhat confused by the various nomenclatures.

For example my Aqara motion sensor shows “detected” and “clear” when used in Device mode, true/false in State mode (and zigbee2mqtt log), and History shows On/Off… It’s kinda non-obvious what to use when, especially if there’s no definitive list of possible states. The absolutely weirdest case are IMHO the window sensors that are “off” when the window is closed.

What are the best strategies? I tried to look this up in the documentation but came up short. Thanks!

On a related note, I wasn’t able to use State triggers with this Aqara Motion Sensor. The entity is correct but no matter if I used “true”, “detected” or “on” as the value, it just wouldn’t trigger. It triggers fine in Device trigger mode. No such issue with my other stuff.

States for binary sensors are always 'on' or 'off' (or unknown). You can see this in Developer Tools → States. These are the states you must use in your automations. And 'on' or 'off' must be quoted (so they look like strings, not booleans).

The way these states are displayed in your dashboards can be changed using a device class. However the underlying state remains the same.

https://www.home-assistant.io/integrations/binary_sensor/#device-class

You can change the device class using the “Show As” option when editing an entity in the UI. Or by using Customize in YAML.

1 Like

Solid info right there, thank you!

It’s not limited to binary sensors though. For example, persons groups show as “Home” and “Away” in UI but in automations, the states are actually “home” and “not_home”. I think this leads to unnecessary confusion and should be solved in some way.

I disagree. I prefer that Lovelace makes the states appear nice.

Just look in Developer Tools / States when you need to know the exact state of an entity.

Don’t forget that HA is also used in languages other than english. This feature will localize the underlying data (like not_home, for example) and make it appear in the local language on the UI without affecting the lower level automations and logic, which will always remain the same regardless of display language.

The Development tools should include possible states. Some of them are in the documentation, but why isn’t this information available in the Dev tools? More complex things then require a lot of webpages open.

Good point about languages, @HeyImAlex