Scope of on the fly scenes

Configuration
1

Hello there,

I’m wondering what is the scope of an on the fly scene.
If I have this in a script:

keep_tradfri_connected:
  alias: ''
  sequence:
  - service: scene.create
    data:
      scene_id: before
      snapshot_entities: '{{ entite }}'
  - service: light.turn_on
    data:
      brightness: >
        {% set curr = state_attr(entite, ''brightness'') | int(0) %}
        {{ iif(curr > 1, curr - 1, curr + 1) }}
    target:
      entity_id: '{{ entite }}'
  - delay:
      milliseconds: 100
  - service: scene.turn_on
    data:
      entity_id: scene.before
  mode: parallel
  max: 10

It might be possible for 2 instances of that script to run in //.
Therefore, they will both create the scene named “before” and activate it at the end.
What will happen?

1 Like
2

Then you’ll have a surprise.

  1. (a) before created
  2. (a) Light turned on to new values
  3. (b) before re-created
  4. (b) Light turned on to the same “new” value
  5. (a) before restored (no visual change)
  6. (b) before restored (no visual change)
1 Like
3

(a) & (b) will not be about the same entity but as (b) is recreating the scene, there is no way for (a) to restore the status of the light that was changed.

Then, how is it possible to “store” the value of the brightness before changing it and use it after? (without creating as much input_number as I have lights)

Let me explain the purpose of the script (even if its name is a big hint)

Sometimes, people in the house or guests, are switching off (electrically) a smart light.
Unfortunately, if you do that a few times in a row, the light will be factory reset (i.e. not connected anymore to my zigbee gateway).
Then, I have to put a CR232 in a stupid remote, get close to the light bulb and pair it again.

To avoid that, I noticed that if I do any zigbee activity on the light bulb in between 2 switch on/off, the reset counter will be restart from 0.

I have a “watchdog” automation for all my lights, when one is changing state to “on”, the script fires to take the control of the bulb back.

Why do I have to change brightness? Because, HA or Ikea is too smart and if the data to send to the light are the current values, the light is not getting any command.

But, by changing the brightness of the light from 1/255th (up or down), I’d like to restore what was initially chosen (even if it seems unnoticeable with naked eyes)

P.S.: If you’re wondering how I plan to do a factory reset if needed, on one hand, I wish I’ll never ever have to do it and on the other hand, I can always deactivate the watchdog the hard way.

4

Why not decrement the brightness by one, and then increment it by one?

No need for a scene, no race conditions, no complexity.

5

If the brightness is already 255, I can’t increment (reason of the template in the script)
Then, why not do -1 +1, because if the brightness is 1, it will go to 0.

I’ll change the script to do a big if >1 then -1 +1 else +1 -1, I’m sad :slight_smile: it was so elegant.

6

If you’re making the scene and then restoring it within the same automation/script the simple solution is to throw a timestamp on the scene ID and store it in a variable. Like this:

keep_tradfri_connected:
  alias: ''
  variables:
    scene_id: "before_{{ now().timestamp() | int }}"
  sequence:
  - service: scene.create
    data:
      scene_id: "{{ scene_id }}"
      snapshot_entities: '{{ entite }}'
  - service: light.turn_on
    data:
      brightness: >
        {% set curr = state_attr(entite, ''brightness'') | int(0) %}
        {{ iif(curr > 1, curr - 1, curr + 1) }}
    target:
      entity_id: '{{ entite }}'
  - delay:
      milliseconds: 100
  - service: scene.turn_on
    data:
      entity_id: "scene.{{ scene_id }}"
  mode: parallel
  max: 10

Now this script can be fired many times in parallel. Each will make its own unique scene and then restore it.

Of course the downside is these scenes will build up over time. If you know there’s a point when definitely none of these scripts are running (maybe the middle of the night?) add an automation to call scene.reload at that time. Reloading the scene integration (or restarting HA but reloading scenes is less destructive) will remove all scenes created by scene.create since they are not persistent.

2 Likes
7

Nice! So many new information that will be priceless in my smart home journey.
I can use the variable to store the current brightness as well.
Too bad it is 10.30pm, I’ll try all that tomorrow.

8

The alternative would be to mangle the entity into the scene name, so that if you happened to get two triggering in the same second it’d handle that cleanly.