This is just a short notice on an update how Logicblocks manage pending actions.
How were pending actions cleared before?
Before, pending actions were only removed from the queue if the first action of an action chain had not yet been started. This typically happened when the first action has a delay or if the Logicblock was configured to use a alternative execution mode.
So when an action chain had started with some scheduled actions and the Logicblock was re-evaluated, then the pending actions were not cancelled.
How were pending actions cleared now?
The new default is:
Whenever a Logicblock is evaluated, the pending actions of THAT logicblock are cleared in any case unless the evaluation result is the same as last time and the Logicblock is configured to not re-execute in those cases (this can be set under the advanced options on the Logicblock).
Upon user request we added an option to keep the old behaviour so that running action chains are left untouched even when the same Logicblock is evaluated again.
Ugh. This completely broke my use case. I have multiple conditions that can evaluate true for the logic block (e.g., one of several doors open or a motion detector detects motion) and the actions increment a counter, then turn a light on (may already be on from an earlier event), then wait for 15 minutes, decrement the counter and evaluate whether the light should be commanded off (counter reaches zero).
The idea was to have the most recent triggers"reset" the 15 minute delay by queuing up a list of pending actions, each with a 15 minute timer. Only the most recent pending action will result in turning off the light as it will see the counter decremented to zero.
Now with the clearing of pending actions for this logic block, the decrementing never happens and the light is never commanded off. Any chance of allowing the old logic of queuing up pending actions for a logic block to happen optionally regardless of the evaluation outcome?
I think you can implement that use case in a much simpler way.
You can get rid of using a counter variable by implementing this:
A boolean variable (“motion_event”) which is set to TRUE by any of your events (motion, door opening, etc.)
A condition (“motion_event_in_last_15mins”) with is linked to (motion_event = TRUE). Make it a trigger condition and set a timeout setting of 15 minutes
Hi @wwmiller3,
adding an option to retain the old behaviour could be an option - we’re open to enable such a feature.
As @teknofilo pointed out, there might be another solution thanks to some extensions we have developed.
If you can give us a little bit context and a non-tech description of what you want to achieve we might be able to figure out an easier setup. If @teknofilo’s answer hasn’t done that already
Thank you. I did get @teknofilo’s suggestion to work and will stick with that. I am still trying to get used to all of the changes (and I find conditions evaluating differently than the value of a the variable to track weird as they are with the timeout feature). I do like the reduced complexity in the new approach!
Thank you. I tried this out and it works great (as well as reduces complexity on the Apilio and IFTTT sides). I thought about using the new condition-based features to make my use case work, but I didn’t quite figure it out. It does not seem intuitive to me to have conditions evaluate to something that is contrary to the variable value they are acting upon.
Yes I completely agree thinking in the negative is difficult. I have been badgering to implement NOT and NOR logic and know @teknofilo would also find that helpful!
to implement NOT and NOR logic and know