Hello, is there a way to repeatedly toggle a light or toggle an outlet during alarm, either for a period of time or until disarm occurs? I did not find a way to do it, so maybe this could be considered a feature request instead? If toggling a smart RGB bulb, would be cool if we could change the color too, for example to red before toggling it… “red alert”. Thanks…
Yes you can do it with a scene:
- turn on the light
- Wait 1s
- turn off the light
- wait 1s
- …
I know it’s a bit painful, but it works 
You can also change the color in a scene 
I guess (not tested) the pain can be relieved a little bit.
TRIGGER: Alarm is armed
ACTION 1: get device value of fx. motion sensor
ACTION 2: only continue if motion sensor shows motion
ACTION 3-6: turn on the light - wait x milliseconds - turn of the light - wait x milliseconds
ACTION 7: if alarm is in mode armed
ACTION 8: start this scene again
That’s faster than programming ACTION 3-6 ad libitum.
No it doesn’t work, because we don’t allow a scene to start itself (to avoid infinite loop blocking Gladys)
Even if you start another scene that start the original scene, it won’t work, we detect circular dependencies
That makes sense for most usecases.
But I can imagine @jason asking for flashing lights as soon as his alarm is triggered. I think for that case a new “repeat sequence until”-action is useful.
I think that’s a feature request. Unfortunately most skilled dev’s are in de french forum (so that’s the place to post a request), while my french is quite poor (thanks to Google Translate I’m able to read that forum).
Yes definitely!
I’m the lead maintainer and spend time on both, so don’t hesitate to create feature requests here too!
The goal is to get both forums to be alive 
1 Like
@alpha-rd what a great job you did writing that feature request - thank you! and kudos, it is a very clear and concise functional spec.
2 Likes
@alpha-rd Thanks for submitting a feature request! I’m not sure this is exactly what we need here.
For the lights, I think it’s better if we implement a “Flash light” action in scene instead of forcing the user to program it manually.
The action could be :
- Devices: list of lights to flash
- Flash interval: 500ms/1s, …
- Flash duration: ?
What do you think ?
And what if a light is connected to a socket? The action should also allow connected sockets devices I think.
But great idea for the other actions.
Hi @pierre-gilles, thanks for your reply.
In general I think it is good to have actions that are as multifunctional as possible. So not implementing a flash light action because Gladys has an alarm, but impementing an action that also can be used in an alarm scene.
That brings me to the question: where can animated lights be used?
- alarm
- christmas lights
- routing
- childrens disco-room
- urgent wake up-scene
- …
In those cases mainly the flash pattern will differ. I think of it as a drum score. In some cases we want long-short-long-long-short-very long. In other cases just short-short-short. That’s why I was thinking of the manual programming as being more multi usecase proof.
Next to that: most of the use cases will need a situational switch off, instead of a timed length. When the danger is over, when it’s bed time or when the disco is finished.
If it is in one action, this could maybe be:
- devices
- time before start (to achieve a syncopic start, fx: 50% of the devices start at 0s, 50% at 500ms)
- flash pattern (either something dynamic as explained above or some predefined patterns)
- switch off signal
Like @lmilcent says: it should also go for other devices than lights, like sockets, sirens et cetera.
Just a quick idea for predefined patterns: maybe some inspiration can be drawn from maritime lights, like famous french light houses.
Explanation of the abbreviations and basic patterns
@alpha-rd sure why not, but one advice I would give: the more complicated a feature request is, the less likely it’ll be developed
Members in the community are all working on Gladys on their free time, and if the feature is very complicated, it tends to discourage developers from helping.
So it’s best to start with a “MVP” of the feature, and then improve in the future in case some new usages are requested We try to do everything with this philosophy.
It is also an effective way to prevent Gladys from becoming bloated software with complicated options
I just tried this, works fine:
- scene with scheduled trigger 2 seconds interval
- get device value (I’m using a motion sendor)
- only continue if variable motion(binary) different 0
- turn switch on
- wait 1s
- turn switch off
2 Likes
Indeed !! Nice find
Ah, that’s even better!
1 Like
But how does this work in an alarm scene?
Hi Jason,
This should be your flow. I didn’t test it, but am pretty sure it works. The “If the alarm is in mode”-action is quite new. So that’s the only part where eventually, but unlikely, something could go wrong.
Please report back if you got your alarm working this way. That will help others
- TRIGGER: Scheduled trigger interval 2 seconds
- ACTION: If the alarm is in mode Armed
- ACTION: Get device value Motion/Presence sensor
- ACTION: Only continue if motion/presence detected
- ACTION: Set device value lights on
- ACTION: Wait 1 second
- ACTION: Set device value lights off
This scene is fired every 2 seconds (point 1)
Points 2-4 check if the alarm has to do something or not:
It checks if the alarm is armed. If not, it stops.
If the alarm is armed, it checks if there is motion detected. If not, it stops.
Point 5-7 tell your house what to do if the alarm is triggered:
If the alarm is armed and motion is detected, it let’s the lights go on, keep it on for one second and turn it back of. This flikker has a total duration of 1 second.
Since the scene is fired every 2 seconds, it restarts only 1 second after the lights turned off. This way, as long as the alarm is armed and motion is sensed, the lights will keep blinking in a 1 second on, 1 second off pattern.
I can try when I am home later today - however - does this logic mean that the scene runs every 2 seconds all the time?
Yes. Of course you can set a longer interval, and adjust something in the duration of the flashes or add some extra flashes.
I think most alarms work that way: constantly checking if something happens. Only in an integrated system where the sensor pushes it’s data to the system this polling isn’t necessary.
By the way: the scene is in the first action immediately killed if the alarm is disarmed. So the load on the processor should most of the time be pretty low. But I guess @pierre-gilles can tell more about processorload.