Disable Individual Triggers Within a Flow

[Pepy]

This will be useful when you want to disable a trigger temporarily, whether it's because it is no longer supported due to permission changes or you don't have root access currently.

Without this, you'd usually have to go into a list of already present triggers and uncheck them and go back into the list and check them later when you want them to be included again. What I'm thinking instead is that you can open up the list of triggers currently active, long-press on it and select an option to temporarily disable it.

[Desmanto]

I would against this feature. It would make the flow very confusing and increase the risk of disabled/forgotten trigger.

Flow is meant to group several similar functioned trigger together. If some of the triggers require to be enabled/disabled depends on some condition, it is better to put them in separate flow. We don't want to put the whole triggers into single flow. If after put into separate flow, and you still require some action from the main flow, you can always use execute flows from the separated flow.

I always put the triggers that require on/off (enable/disable) on separate flow. Then control it from the main flow. My secure setting logger flow is one of the example : viewtopic.php?f=3&t=7931

[Pepy]

I suppose you're right. I know it may be a bad habit, but I do tend to try to fit everything into a single flow rather than separating them as they often may have similar functions (such as to enable and disable something). Another reason is because I find it unnecessary to have flows with only one or two elements in them. An exception for this however, is when I use triggers like User Present or any sensor based triggers are used as they can potentially drain the battery due to how often they are triggered.

However, I think this could still be pretty useful if you're working on a flow and testing out different triggers for it. Perhaps the temporarily disabled triggers could delete themselves after a specific amount of time.

[Desmanto]

I also hate one-trick pony flow. But sometimes we can't help it, have to separate out like that.

For testing multiple triggers, I have created another flowception to help me testing each trigger. I use Control UI to fetch all the triggers name, dump it into script and followed by another input dialog. I disabled the flow or use condition triggers == manual to filter out all the triggers. This way I can check the flow behaviour without waiting until the triggers triggered, which can take a long time especially with time trigger.

[Pepy]

I also hate one-trick pony flow. But sometimes we can't help it, have to separate out like that.

Yeah, it becomes a jumbled mess when you do that, but I probably would find keeping the amount of flows to a minimum more important than that honestly.

For testing multiple triggers, I have created another flowception to help me testing each trigger. I use Control UI to fetch all the triggers name, dump it into script and followed by another input dialog. I disabled the flow or use condition triggers == manual to filter out all the triggers. This way I can check the flow behaviour without waiting until the triggers triggered, which can take a long time especially with time trigger.

You're always so innovative when it comes to solving problems
In most cases, I'd just use a simple Notification on Screen action, a peek at the log file or the Debug Dialog condition.

For my testing flow, I do use a Expression condition for filtering out the triggers (specifically the System Setting Changed: Global/Secure/System) ones, but that's about it. But anyway, if I'm understanding you correctly, what you're doing here is gathering a list of the triggers being used in the flow, then showing an input dialog and then disabling or filtering out the ones not chosen (using the supplied trigger variable)?

[Desmanto]

Sometimes there will be trade-off between less flow count and tidier flow. I hate one-trick-pony flow, but when it is needed, then it can't be helped. I prefer tidier in most cases.


Yes, but my flowception "trigger tester" branch, really create the script and input dialog at there for further testing. So it takes the triggers name using Control UI, choose the trigger, then it waits for me to drag down to create new element, twice; one for script and another for input dialog. Later I have to connect the input dialog to each of the expression. A bit troublesome, and quite messy.

Your question makes me think about other method to do it. Why don't I just query the triggers, and instead of creating the script and input dialog, simply pop up input dialog and choose the triggers. Then use this to execute the flow with the {trigger} replaced by the chosen value. But the flow should be in enabled state. So if during testing, the flow is disabled, it should enabled first and disabled after testing. (for sensor based triggers, it can interfere the testing if it is enabled all the time). This is much cleaner and doesn't add extra 2 elements in the flow, just for testing. Thanks for the question.

[Pepy]

Sometimes there will be trade-off between less flow count and tidier flow. I hate one-trick-pony flow, but when it is needed, then it can't be helped. I prefer tidier in most cases.

Yeah, this is completely subjective. Other than for efficiency purposes (as little elements executed as possible) I would prefer not to have multiple flows with barely any elements in them, so it's pretty much the other way around for me (if it cant be helped, I'll have to create multiple flows)

Yes, but my flowception "trigger tester" branch, really create the script and input dialog at there for further testing. So it takes the triggers name using Control UI, choose the trigger, then it waits for me to drag down to create new element, twice; one for script and another for input dialog. Later I have to connect the input dialog to each of the expression. A bit troublesome, and quite messy.

Yeah, that sounds really confusing; I still don't understand what you're trying to achieve here. Does it basically let you create elements based on the trigger (eg. a Script action with a boolean expression to compare the trigger that executed the flow)?

Your question makes me think about other method to do it. Why don't I just query the triggers, and instead of creating the script and input dialog, simply pop up input dialog and choose the triggers. Then use this to execute the flow with the {trigger} replaced by the chosen value.

I would just re-arrange the trigger's connections to the part of the flow that I want to test and execute it manually and since you told me in another thread that you prefer creating multiple flows over a multi-purpose one, then why would you even need something like this?

Thanks for the question.

No problem. I'm learning a lot from just replying to your posts alone

[Desmanto]

Yeah, that sounds really confusing; I still don't understand what you're trying to achieve here. So basically it lets you create elements based on the trigger (eg. a Script action with a boolean expression to compare the trigger that executed the flow)?

Sort of it. The Control UI waits for me to drag the +, then create script with all the triggers names. Wait again to drag +, then create Input dialog with the preloaded list as the choices. Then I need to connect the trigger to the script, and input dialog to each of the branch of the expression. But it won't be like that anymore, since I have improvize after previous post.

I would just re-arrange the trigger's connections to the part of the flow that I want to test and execute it manually and since you told me in another thread that you prefer creating multiple flows over a multi-purpose one, then why would you even need something like this?

I still use multiple triggers with multiple expression to split the triggers. The one that I have to separate is when the triggers need to be enabled/disabled on certain time. Those one-trick-pony trigger should be separated to avoid mis-trigger or battery drain. Compared to the feature to disable individual trigger inside flow (so we combine those one-trick-pony flow to the main flow, but disable the trigger), this is much tidier in my opinion.