state automation unexpectedly triggering when not_to: unavailable | Home Assistant | Page 1

vivid summit Mar 11, 2026, 10:53 PM

#

I have an automation that opens/closes blinds when the brighness on a dimmer changes. Here is the trigger:

  id: dimmer_change
  entity_id: light.master_bedroom_blinds
  attribute: brightness
  not_from:
    - unavailable
  not_to:
    - unavailable
  for:
    milliseconds: 100```
Weirdly, this automation triggers when the state is becoming unavailabe.  Here is the to_state in a recent trace:
```to_state:
  entity_id: light.master_bedroom_blinds
  state: unavailable
  attributes:
    supported_color_modes:
      - brightness
    friendly_name: Master Bedroom Blinds
    supported_features: 32
  last_changed: '2026-03-11T19:29:57.592759+00:00'
  last_reported: '2026-03-11T19:29:57.592759+00:00'
  last_updated: '2026-03-11T19:29:57.592759+00:00'
  context:
    id: 01KKF615AR0DE6A0SPGD8S6YZV
    parent_id: null
    user_id: null```
Any idea why this is happening? Can I not mix and match all the different attrbutes of this trigger? Or is this a bug?

plush basin Mar 11, 2026, 11:52 PM

#

the value of brightness attribute is never unavailable

#

not_from/not_to apply to the attribute you have specified.

vivid summit Mar 12, 2026, 12:13 AM

#

ah, that makes sense

#

What would be the easiest way to do what I want here? My problem is that occasionally my dimmers go offline and become unavaliable. When that happens my shades are being told to close and then repopen (when the dimmer comes back online). So I'm trying to fix that.

plush basin Mar 12, 2026, 12:17 AM

#

hmm what comes to mind is maybe trigger on any brightness, and template condition that from_state/to_state are not unavailable.

vivid summit Mar 12, 2026, 12:25 AM

#

this is my current condition:

#

          - condition: trigger
            id:
              - dimmer_change
        sequence:
          - action: cover.set_cover_position
            target:
              entity_id: cover.master_bedroom_blinds
            data:
              position: >
                {% set brightness = state_attr('light.master_bedroom_blinds',
                'brightness') %} {% if brightness is not none %}
                  {{ (brightness / 255 * 100) | round }}
                {% else %}
                  0
                {% endif %}```

#

not sure how I would change it to do that ?

plush basin Mar 12, 2026, 12:29 AM

#

Something like this maybe:

condition: template
value_template: >-
  {{ trigger.to_state.state != "unavailable" and trigger.from_state.state != "unavailable" }}

vivid summit Mar 12, 2026, 12:29 AM

#

OK, I'll give something like that a shot.

#

FWIW if you are a HA dev (or if any other devs read this thread) I've found as a new(ish) HA user that dealing with unknown/unavailable states in automations is generally quite confusing. Really seems like they should be handled automatically better somehow.

plush basin Mar 12, 2026, 12:31 AM

#

we know 😅

vivid summit Mar 12, 2026, 12:31 AM

#

Something like a checkbox that says "just never trigger me if this was caused by something becoming unavailable for a bit" would be so helpful!

#

But glad you know! I'm sure someone will figure it out at some point! 🙂

#

Even something as simple as "when I press a button, do a thing" got me tripped up on this. 🙁

vivid summit Mar 12, 2026, 1:36 AM

#

putting a condition in the template worked. ty!

pine chasm Mar 12, 2026, 6:12 AM

#

If you're up for it, you could try turning on the "purpose specific triggers and conditions" labs feature @vivid summit. We're still working on expanding what triggers are available, but for your purpose in this post, we've already got a "light brightness changed" trigger. All these new triggers ignore "invalid" states such as unavailable and unknown by default

vivid summit Mar 12, 2026, 11:43 AM

#

@pine chasm Can I add a "for:" parameter to a PST ?

#

That's kinda unclear from the UI

pine chasm Mar 12, 2026, 11:44 AM

#

Not yet! Sorry, missed that in your original post. Now my suggestion is kind of useless 🙈

#

It's in the works though

vivid summit Mar 12, 2026, 11:44 AM

#

No big deal! It was a good suggestion anyways.

#

I've had PSTs on for a while, but didn't think to use one here.

#

I'll wait until y'all get "for:" working with them and then give it a shot.

#

I need it because of someone is adjusting the brightness of a dimmer I need to wait until they are done instead of triggering the automation a bunch of times while the brightness is changing.

pine chasm Mar 12, 2026, 11:45 AM

#

Ha, you read my mind, was about to ask why you needed it here

#

Got it!

vivid summit Mar 12, 2026, 11:45 AM

#

I really like PSTs btw! Thanks for working on them!

#

I'm also waiting until you get them working with matter buttons (which are kind of weirdly moddled as events)

pine chasm Mar 12, 2026, 11:58 AM

#

We're adding a generic event trigger to make working with event entities a bit easier, button-specific triggers require a bit more work unfortunately

vivid summit Mar 12, 2026, 11:59 AM

#

I'm just waiting for "press a button, do a thing" to be a trivial thing to make. Sounds like you're close!

pine chasm Mar 12, 2026, 12:05 PM

#

That's the goal, but buttons are "hard" in that there's no standardised way for them to communicate "I was pressed once" or "I was pressed twice" etc

#

The generic event trigger we're adding soon should at least solve this for individual devices (if your button reports "clicked", then you'll be able to use that event as an automation trigger)

#

Later, we'd like to expose triggers for "Button was pressed once (button.pressed in YAML)" etc

#

Just to give you some context on what's coming 🙂

vivid summit Mar 12, 2026, 1:07 PM

#

Sounds like a big improvement from the status quo!

vivid summit Apr 1, 2026, 2:50 PM

#

@pine chasm event based purpose specific triggers in this month's release. yay!

pine chasm Apr 1, 2026, 2:55 PM

#

Yesss

#state automation unexpectedly triggering when not_to: unavailable