How to trigger automation when state changes to same value

I have a device (a select input for presence checks, since I like to manually control this).

When the input_select is set to Sleeping or Home some automations trigger. If the devices current state is already Sleeping and I set it to Sleeping again, nothing is triggered.

I want it to trigger the automation even when the state is changed to the same value. How can I do this?

How are you checking the state change now? Can u post the yaml of that automation?

One of the two automations currently looks like this. It works as long as there was an actual state change, like for Sleeping to Awake. The Automation gets triggered by any state change of the input_select and then has some logic to decide what should happen, using the value_template.

alias: tim_status_after_sunset
description: ""
trigger:
  - platform: state
    entity_id:
      - input_select.tim_home_status
condition:
  - condition: sun
    after: sunset
    before: sunrise
action:
  - choose:
      - conditions:
          - condition: template
            value_template: "{{ trigger.to_state.state == \"Zuhause\" }}"
        sequence:
          - service: scene.turn_on
            target:
              entity_id: scene.alle_tim_home_sundown
            metadata: {}
        alias: if new state is "Zuhause"
      - conditions:
          - condition: template
            value_template: "{{ trigger.to_state.state == \"Schlafen\" }}"
        sequence:
          - service: scene.turn_on
            target:
              entity_id: scene.alle_tim_sleep_lights
            metadata: {}
          - service: climate.set_temperature
            target:
              device_id:
                - 89a37f3f414064c9a0d8e4b50f95b263
                - c0556c523c769081aa822cf37e9ae53a
                - c8011feb23fea7909b57dbfff5ddac6e
            data:
              temperature: 4
        alias: if new state is "Schlafen"
mode: single

The yaml you posted has some quotation problems, but i dont know if thats from the copy paste. But you cannout have "" inside "" That should be:

value_template: "{{ trigger.to_state.state == 'Zuhause' }}"

But that wont fix your issue anyway, so the state trigger will only trigger on change. What u want would be an event, for example the service call input_select.select_option is something you might want as trigger.

trigger:
  - platform: event
    event_type: call_service
    event_data:
      domain: input_select
condition:
  - condition: template
    value_template: "{{states('input_select.tim_home_status') == 'Zuhause'}}"

I supposed that’s why its using \ to escape the inner ". The automation was created via UI and copied from there.

Anyway it doesn’t make a difference.

Can you explain how you are doing that?

Specifically, how are you “setting” the Input Select to the same state it currently has. It cannot be done via the UI without first changing it to another value so I am interested to know how you’re setting the same state. Perhaps via a service call?

I created a helper “button” that is triggered by an Alexa command and, in turn, triggers an automation to set the input_select to the respective state.

It sounds like you need to have an additional “mode” so you have something to switch from and to. I have a fairly elaborate system for this that drives a LOT of my automations (i.e., don’t send TTS messages if not awake, etc). Even something like “Still Sleeping” that automation changes immediately to “Sleeping”.

For me I have states like:

  • Sleeping
  • Awake
  • One Awake (one of is up, the other is not)
  • Napping
  • DND

Can you explain the reasoning behind wanting to set your sleep mode to sleeping when it’s already sleeping? That might inspire some suggestions on how you could improve upon it.

So, via service call input_select.select_option in a separate automation.

Why not simply modify your automation (the one posted above) to monitor the Button’s state (in a State Trigger)?

When it triggers, your automation should handle it like if the Input Select had been set to Sleeping. This can be easily achieved by enhancing the choose’s second condition (the one handling Schlafen) .

trigger:
  - platform: state
    entity_id:
      - input_select.tim_home_status
      - button.your_button
      - conditions:
          - condition: template
            value_template: "{{ trigger.domain == 'button' or trigger.to_state.state == \"Schlafen\" }}"
        sequence:

Mostly out of convenience. Say you set the state to sleep, but get up again and change a few lights by voice command or Hue remote, and get back to bed, I like to just say my sleep command again to trigger the automations instead of manually setting each device back to the “sleep” state.

I just moved from Fhem to HA, and this is how it worked there. I am fairly new to HA, so maybe I will create an automation-script that will do the logic (similiar to what you described) and just call that upon button press.

I think just adding a bit more logic to the automation that listens for the Alexa-helper button and adding an “intermediate” state for the input_select, which gets briefly selected and changed back if the desired state is already set, should do the trick for now.

That’s a good example of using your “sleep mode” (as I call it on mine) to control lights. You say when you are awake then perhaps those lights stay on 15 minutes, but when the mode is sleeping it stays on for 3 minutes. Even get extra fancy with it and say if I detect motion a second time then make it stay on 10 minutes.

You can make your smart home pretty smart with HA, you just have to think about what you need to achieve. I try to work on the “90% rule” that says I build a system for 90% of the needs with 10% being the out-of-the-ordinary stuff I’ll handle as I need to. Do you get up a lot after going to bed (I do)? If so then build automation that supports that in, again, a “90% of the time when I get up after going to bed I need this to happen” approach.

Yes, if you’re turning on lights, that should kick it out of Sleep. Then you can easily set it again.

If you use what I suggested, that weird “trick” isn’t needed (and you reduce the number of automations needed).

1 Like