Sorry but I no longer understand the problem you’re attempting to describe because these two statements appear to be contradictory:
As I read it;
It works fine if the lights is already on. Gate opens → Light turns red. Gate closes → Light returns to prior state (White or warm or whatever, but still on.)
His problem appears to be that when the light’s starting state is off and the gate opens.
Gate opens → Light turns on and red
Gate closes → Light turns off but retains the red colour setting, meaning that the next time someone turns on the light, it turns on red.
I’m sorry if i haven’t made myself clear so i will try again.
-
somebody turns the light on by a button or whatever (no automation) and they are yellow like it was in
the previous state. -
somebody turns the light off (the previous state is stored, yellow)
-
gate opens and light becomes red
-
gate closes and light goes off.
-
next time somebody turns the light on by a button or whatever the light becomes red and that’s not
correct. It has to be yellow as captured with snapshot_entity.
Hope i made myself clear now 
That is exactly what i’m trying to say.
I have a similar automation for my fridge and freezer doors. When left open more than 5 minutes, an automation switches on my kitchen counter lights to red. When closed it returns them to white, but doesn’t switch them off, as I have a separate automation that turns those lights off after 30 minutes of no movement in the kitchen anyway. That might be one bodgy way to solve your problem, if you have any motion sensors. I’m sure there is a neater way to do it, Taras is usually able to steer people in the right direction for these things.
Thanks for the clarification.
That behavior is due to the light’s retention of its previous properties (like color, color temperature, brightness, etc). When turned on it restores its previous properties (this is a feature of the light’s firmware, not Home Assistant).
Example:
-
Light is off.
-
Home Assistant has no way of knowing what the light’s previously-used properties are (color, color temperature, etc) other than it’s currently off.
-
If you create a snapshot scene, the only property known to Home Assistant is that the light is off. That’s the only thing that will be restored when the snapshot scene is applied.
-
Gate opens, light is turned on and set to red.
-
The light retains ‘red’ as the color it will use when turned on the next time.
-
Gate closes, snapshot scene is applied and light is simply turned off. Its color isn’t changed from red to something else because the previous color was unknown to Home Assistant when the snapshot scene was created (because the light was off).
-
Someone turns on the light and it automatically uses its previous properties which means it displays red.
Correct but in the link i posted somebody found a solution.
So in my case:
- Gate opens
- Turn the light on for 250 ms in its previous state(let’s say yellow) and capture the state.
- Light becomes red after those 250 ms.
- Gate closes, light goes to previous state, off or yellow.
That works i think but i can’t get the script to work (i’m using HA just for a couple of months)
His script starts with:
alias: Front Light Siren
In that way the script doesn’t show up in the UI and i can’t turn it on.
I made a small test script and that shows up in the UI.
In Studio code server it starts with the name i gave it,Testscript:
and i can turn it on.
Thanks for your time both of you @Sidioussam and @123
Turn on the light (without specifying any other properties) before creating the snapshot scene. However, do this only if the light’s current state is off.
- id: '125'
alias: "Gate opened"
trigger:
- platform: state
entity_id: binary_sensor.797
from: "off"
to: "on"
condition: []
action:
- if: "{{ is_state('light.hue_go_1', 'off') }}"
then:
- service: light.turn_on
target:
entity_id: light.hue_go_1
- delay:
milliseconds: 250
- service: scene.create
data:
scene_id: before
snapshot_entities:
- light.hue_go_1
- service: light.turn_on
target:
entity_id: light.hue_go_1
data:
rgb_color:
- 255
- 0
- 0
brightness: 255
This does not turn the light off so i a couple lines of code but it doesn’t turn off either.
`- id: '125'
alias: "Gate opened"
trigger:
- platform: state
entity_id: binary_sensor.797
from: "off"
to: "on"
condition: []
action:
- if: "{{ is_state('light.hue_go_1', 'off') }}"
then:
- service: light.turn_on
target:
entity_id: light.hue_go_1
- delay:
milliseconds: 250
- service: scene.create
data:
scene_id: before
snapshot_entities:
- light.hue_go_1
else:
- service: scene.create
data:
scene_id: before
snapshot_entities:
- light.hue_go_1
- service: light.turn_on
target:
entity_id: light.hue_go_1
data:
rgb_color:
- 255
- 0
- 0
brightness: 255`
Correct. There’s more that needs to be done than what I provided in my previous example (which was only meant to demonstrate a portion of the technique you described from the other topic). My example only showed how to capture the properties of a light that was previously off.
What remains to be done is that after scene.before is applied, the light must also be turned off (otherwise it will be left on). However, this extra step of turning off the light must only be done if the light was previously off (obviously you don’t want to turn it off it was previously on).
The tricky part is knowing when to perform the extra step of turning off the light and when not to. One way to do this is to make the first automation turn on an Input Boolean whenever it encounters light.hue_go_1 is off. The second automation checks the state of the Input Boolean and, if it’s on, performs the extra step of turning off the light.
- id: '125'
alias: "Gate opened"
trigger:
- platform: state
entity_id: binary_sensor.797
from: "off"
to: "on"
condition: []
action:
- if: "{{ is_state('light.hue_go_1', 'off') }}"
then:
- service: input_boolean.turn_on
target:
entity_id: input_boolean.light_off
- service: light.turn_on
target:
entity_id: light.hue_go_1
- delay:
milliseconds: 250
- service: scene.create
data:
scene_id: before
snapshot_entities:
- light.hue_go_1
- service: light.turn_on
target:
entity_id: light.hue_go_1
data:
rgb_color:
- 255
- 0
- 0
brightness: 255
- id: '126'
alias: "Gate closed"
trigger:
- platform: state
entity_id: binary_sensor.797
from: "on"
to: "off"
condition: []
action:
- service: scene.turn_on
target:
entity_id: scene.before
- if: "{{ is_state('input_boolean.light_off', 'on') }}"
then:
- delay:
milliseconds: 250
- service: input_boolean.turn_off
target:
entity_id: input_boolean.light_off
- service: light.turn_off
target:
entity_id: light.hue_go_1
1 Like
Thank you so much for all your effort but the light stays on.
Update : I’m sorry but i forgot to create the helper input_boolean.light_off
And now…every works fine !!
Thank you sooooo much for your effort and time 
And not to forget, i learned a lot today.
I was thinking when the light is off, that state is also captured by the snapshot_entity.
1 Like
I ran into a little issue…
I was trying to make that automation for a lightgroup but i didn’t want to annoy my wife and kids with turning off and on the kitchenlights for hours.
So i tried it with one light in my office.
When you gave me the solution i changed the code back to the kitchenlights and guess what ?
It didn’t work anymore.
I had a suspicion that the 250 ms delay was not enough to capture the state of four lights instead of one.
And indeed, setting the delay to 500 ms made it work again 
Suddenly it didn’t work anymore.
I’m not giving up so i changed the code to one of the four kitchenlights instead of the group (the four kitchenlights).
Then something strange happened.
When i opened the gate all four of the lights became red.
For some reason the snapshot_entity is not updated or created again.
I removed all the code that creates the snapshot_entities.
In the automation that closes the gate i put an existing scene that was imported by the Hue-integration en that did the trick. (for now 
)
Using a native Hue scene is optimal because Home Assistant only needs to send one command and all four lights know what they need to do (because they know the details).
In contrast, a Home Assistant scene sends commands to each one of the four lights. There’s more communication involved therefore it takes longer for all four lights to receive and comply with the commands (and for Home Assistant to receive acknowledgement when all four lights have complied).
But we added a delay ?
I even tried it with four seconds.
It would appear that the results of your tests are demonstrating the fragility of the workaround proposed in the linked post.
Which wasn’t a reason to instantly remove the Solution tag. 
If the proposed solution works but later doesn’t then it means it simply needs refinement and/or more thorough testing.
If you want my continued assistance, I need to see the latest version of all modifications made to the automation or entities it references.
Correct ! When i used Fibaro Home center 2 i had to store all the values power, brightness… for each light in a json table but that worked fine.
In Home center 3 there was an integration to do this but that didn’t work.
I think the communication of the lights is very slow…
Anyway it’s ok now, the scene for the kitchenlights i call in the “Gate closed” automation now is almost always the one i use in the kitchen.
Have a nice day !!
Glad to hear it. Please consider restoring the Solution tag here so that it can help other users find answers to similar questions. Thank you.
Oh, i’m sorry that i removed it.
I thought i had to do that.
Restored now
Thanks again !!!
1 Like