Trigger "platform: state" should be renamed into state_change

Feature Requests
1

I am in a HA forum and nearly every day people write about automation problems. The most common error: they think a trigger is running if an entity IS in a state. For example they think: if brightness is below 30 lx and the time is between 8 and 20:00, then turn on the light. They don’t know that triggers only run on state changes.
So my proposal is: change “platform: state” to “platform: state_change”. Same with numeric_state. The old variant can be kept for continuity.

One thing to clarify: I’m a 50 y.o. software engineer. I don’t need this feature request for me, so I won’t fight for it. If you don’t like it, I don’t care.

2

I agree that users are confused by this, but the header is trigger. The platform only describes on what the automation will be triggered.

Not sure how to clarify to users that HA is event-based, and that a trigger is, well, a trigger, but very likely not by just changing the platform name (the problem is exactly the same for “numeric_state” and “zone”, btw)

1 Like
3

In my opinion the word “state” is not correct. Because a state is sth. static. The trigger is fired when the state is left, when it changes.

4

Then “they” should read the documentation. Here’s the first line of the description for the State Trigger.

Fires when the state of any of given entities changes.

Over the past three years, I have helped hundreds of people and, based on personal experience, very few people have misunderstood how a State Trigger works, certainly not enough to justify a major change like renaming it.

What is a common mistake is the misinterpretation of how a Numeric State Trigger works. However, changing its name to Numeric State Change Trigger wouldn’t help resolve it because the mistake involves how the trigger uses its threshold value(s).

3 Likes
5

Yeah, I think the “to:” and “from:” in the state trigger is a pretty good give away that the state needs to change for a trigger to fire on that change.

Even the zone trigger has an implied state change since it uses “enter” and “leave” events as the trigger.

the “above:” and “below:” threshold for the numeric_state trigger is less obvious - even tho it is described in the docs.

6

Of course for geeks which read all the docs all this is very easy. But in reality there are many people that misunderstand the concept. They code

trigger: numeric state below 100
condition: time between 8 and 12
action: light on

and they think the light goes on at 8 o’clock when the sky is gray.

7

I’m not sure why someone would think a state was static?
When we use it in everyday language - we use it to talk about something dynamic - for example:

“Look at the state of your face, it’s covered in chocolate”
“Look at the state of your trousers”

We use it to talk about how something has changed, the face wasn’t ALWAYS covered in chocolate, that was a change.

In terms of an automation -
State change: face covered in chocolate
Action: Wipe face.

We don’t expect that we would just be wiping the face continuously, we only do it in response to a state change.

8

Why do you write “state change”?

9

Why do feel the need to describe people who read instructions as “geeks”? In this context it’s unflattering and dismissive of the people who make an effort to study and learn.

Then instead of posting a contrived example, you should be able to link to at least 5 real-world examples where someone misinterpreted the meaning of a State Trigger. You claim it happens frequently enough so it should be easy enough for you to find supporting evidence.

10

That’s not just a misunderstanding of how a state trigger works. It’s also a misunderstanding of how conditions work as well. basically they have the concepts reversed.

I doubt changing state to state_change would fix that since it’s such a fundamental misunderstanding of the terms.

11

Discussion aside, you forgot to vote for your own Feature Request…

Edit: but after reading I’d have to agree with @finity and @123

12

Let’s face it: Kids those day do not read docs, they look at videos.
IMO, a well done, illustrated, 1 minute video explaining the concepts of trigger/conditions/actions with a simple, real-world, abstraction would likely be far more beneficial that any name change.

Now:

  1. It"s not easy
  2. It’s not cheap
  3. Devs sucks at this

So hopefully, some HA fan who is also an illustrator will jump in, some day.

13

I’m a computer engineer and I don’t need this change.

14

because the state has changed -
FROM - “not covered in chocolate”
TO - “covered in chocolate”

15

Perhaps but that doesn’t address the author’s decision to disparage users who take time to learn basic concepts. It’s an unwelcome comment in a community forum meant for learning and helping one another without judgment.

The State Trigger has been platform: state for 8 years and employed by a user-base of tens of thousands of people. Frankly, nobody needs this change; the State Trigger is understandable to anyone who takes a moment to learn it.

16

Hey great, millions of people are using it for years, so lets stop working on it and freeze it as it is, it cannot be bad…hahaha…thats a great argument :slight_smile:

17

I’m quite willing to shout down a “because we’ve always done it that way” argument but still see no merit in your request.

from and to already makes the “change” implicit.

As was stated earlier it is usually the above and below of the numeric state trigger that causes misunderstanding.

18

It demonstrates the word “state” hasn’t been misunderstood by as many people as you claim.

Where’s your real-world evidence that it has? Please post links to several posts showing that users frequently make the claimed error.

Without at least some evidence, this FR is a non-starter.

19

I don’t care, you can immediatedly delete this feature feature request.
I started it for the millions of non-hackers and beginners which now get involved into home automation. If you say “–censored–” to these people its ok. They don’t pay me.

20

Please edit your post.