No, i don’t see that posibility right now in AT.
Technicly it could be made, but placing variables in the Trigger, i am not sure that thats a very good idea, performance wise. I might look into it (some day/right now a bit).
But first let’s see if i have a better solution for you: The default Homey Alarms.
Perhaps it’s best you create 1 or 3 Alarms for this.
This gives you some excellent management options through the Homey app.
And, the only thing missing is a flow to set the times, but here is a HS i created for it yesterday
let alarms = await Homey.alarms.getAlarms();
let alarm = _.find(alarms, a=>a.name=='AlarmName');
await Homey.alarms.updateAlarm({id:alarm.id, alarm: {time:'20:19'}});
No, there a default flowcards for that.
HS is only needed to adjust the time of the alarms: the can only be set through HS or the Homey App, not through flowcards.
Well HS is perhaps also needed as a condition to check if a alarm is active, i don’t see any conditions.
Perhaps someone should ask @Emile or @Athom if a Set Alarm Time actioncard and a Is Alarm Running condition card could be added to the default flowcards.
I really have to say that this app is super.
I using it in more and more of my flows.
The possibility to have trigger in sequence for resource lock, and debounce for holding down the load on flows. So great.
Thanks @Arie_J_Godschalk!
await Homey.alarms.updateAlarm({id:alarmOff.id, alarm: {enabled:false}});
Wasn’t harder than that. I had no need for conditions when all was done inside the same HS.
I won’t spam this forum more with non-Advanced Triggers. Just wanted to say thanks for helping!
With the following flow I tried to block the multiple triggers my Klik-Aan-Klik-Uit doorbell is causing sometimes.
The triggers can happen a few milliseconds after each other, but the debounce is not preventing the final cards to fire.
When tested with timers, is works fine. But it looks like the debounce can not block rapid triggers of a few milliseconds.
Is this a limitation of Homey, or am I doing something wrong?
Hi @Arie_J_Godschalk Is this app still alive?
It could resolve one of my key issues with sometimes writing simultaneous messages to a log.
I cannot get it to trigger the second row.
I think you need to save the flow between adding the then card (to set the trigger name “TriggerDuration1var”). Then it will show up in the when card. As you already have saved your flow, try to re-add the trigger name in both cards. Did you select “create” when adding the trigger name in the first card?
Like you proposed, could you give me an example of how to use the debounce functionality to prevent a flow from running twice within a few seconds. I mean, not delaying the second flow request, but actually not executing it at all.
The upper card, if you set the Execution to “Execute on start, than execute every [x] ms”, than the first execution will be executed as soon as it is triggered (with the lower card).
I have set the ms to 1000 (1 second), thus, all further executions within the second after the first execution will be ignored.
With this execution mode, it will not finish with the last one waiting, it will just ignore all executions during the debounce ms time.
That would be no problem at all. I can also do a small write up to explain what has been done and why.
It will be mostly written in Jip&Janneke language, but that’s probably what you’re asking, Right?
