Automation - Until condition doesn't trigger

[tom_l]

Oh ukro did that.

I’ve seen other posts with weird ‘until’ condition behaviour. In one case it worked with one step value but not another.

[pcl (Peter Lucas)]

Correct… But if you do have some insight in why my ‘until’ condition doesn’t trigger : I’m open to suggestions.

I don’t have a clue why this doesn’t work. Simple automation, I see the condition fireing in the logs and still the until clause doesn’t trigger.

Clueless…

[tom_l]

It appears to have a bug:

0.113: Automations & Scripts, and even more performance!

Can anybody help me understand what’s causing such behaviour: This code works fine: sunrise: alias: Sunrise mode: single sequence: - repeat: sequence: - data: brightness_step: 2 entity_id: light.sonoff service: light.turn_on - delay: seconds: 1 until: - condition: template value_template: '{{ repeat.index >= 124 or states.light.sonoff.state == ''off''}}' And this one stops after one pass: sunrise: …

[pcl (Peter Lucas)]

Freck… just my luck… a bug…

[tom_l]

This is the only issue I could find and it appears to have been fixed on July 23 but the post I linked to above is after that (in August).

Script repeat action not defining repeat variable in while or until conditions

So a new issue wasn’t opened and thus no one is aware it needs to be fixed.

[Burningstone]

Once the automation has been triggered, does it start to correctly increase the brightness and then never stops increasing or does it increase once and then it stops?

I think even if you manage to get this to work, it’ll still not work as intended, because the brightness_step_pct part needs to read the current brightness before it adjusts the brightness and the next increase comes before the first increase has been finished, therefore HA is not able to read the correct current brightness. There’s an appdaemon app called Controller X that has a workaround for this issue.

[pcl (Peter Lucas)]

The automation work fine when it starts. It increases the brightness and keeps going. It just never stops. It does throw of all my other automations, no automation works once this one is triggered.

I’ll have a quick look at the appdaemon app. I tried to stay away from appdaemon but if that’s what it takes… so be it.

[pcl (Peter Lucas)]

Next to that : The mqtt topic ‘button_1_release’ is in the logfiles…

[ukro]

@pcl

          entity_id: sensor.wallswitch_attic_action
          state: button_1_release

hehe got it :>

[ukro]

If you go to developers and look the entity sensor.wallswitch_attic_action
what did it now show in state column?

[pcl (Peter Lucas)]

it’s momentary. So the moment I release the switch it’s ‘button_1_release’. Both in the action attribute as well as the state. Dev_tools ( see below ) gives me a correct true and false so it should work…

{{ is_state('sensor.wallswitch_attic_action', 'button_1_release' )}}
{{ is_state('sensor.wallswitch_attic_action', 'button_1_hold' )}}

{{ is_state_attr('sensor.wallswitch_attic_action','action','button_1_release') }}```

[ukro]

Try to look here, for me this is working and is stopping on until event:

- id: '1601810050556'
  alias: rolety_number_increase_test_4
  description: ''
  trigger: []
  condition: []
  action:
  - choose:
    - conditions:
      - condition: template
        value_template: '{{states.input_number.slider1.state!=states.input_number.slider2.state}}'
      sequence:
      - service: switch.turn_on
        data: {}
        entity_id: switch.rolety_channel_change
      - delay: 00:00:01
      - service: switch.turn_off
        data: {}
        entity_id: switch.rolety_channel_change
      - delay: 00:00:01
      - repeat:
          until:
          - condition: template
            value_template: '{{states.input_number.slider1.state==states.input_number.slider2.state}}'
          sequence:
          - service: switch.turn_on
            data: {}
            entity_id: switch.rolety_channel_change
          - delay: 00:00:01
          - service: switch.turn_off
            data: {}
            entity_id: switch.rolety_channel_change
          - service: input_number.increment
            data: {}
            entity_id: input_number.slider1
          - delay: 00:00:01
    default: []
  mode: single

[pcl (Peter Lucas)]

Nice code…

I’ll try to adapt it to my situation and give it a go. Not mqtt is it? Keep thinking there is something there that doesn’t work.

[ukro]

Put it inside the

choose:

[Burningstone]

@pcl

So the moment I release the switch it’s ‘button_1_release’.

Does the state stay at "button_1_release until you press the next button or does it change to “idle” or sonething similar after a few seconds?

And while you hold the button, is there any attribute thant changes during the time you hold the button? I could imagine that somehow an attribute changes state during the time you hold the button and triggers your automation again even though the state didn’t change. Do you get any warnings in the logs?

[ukro]

No mqtt but try to use the

choose

and let me know.

[Burningstone]

@pcl

Not mqtt is it? Keep thinking there is something there that doesn’t work.

Why do you think this? You say that the entity in HA correctly reflects the current button press, so everything should be fine on MQTT side.

[pcl (Peter Lucas)]

All the states are momentary. So the moment I long press the button it’s button_1_hold, than the state is empty. The moment I release the button it’s button_1_release.

Should trigger on the later one… but it doesn’t.

[pcl (Peter Lucas)]

Because the state change doesn’t seem to register in HA. This is what I see in the logbook :

.

I find that weird. The action doesn’t register in the logbook, but does in the logfiles.

[ukro]

Show us the developer tab when you press