Did you by any change had H.O.O.P. (Hope) - Homey Object Oriented Programming - Apps - Homey Community Forum before?
Nope, did not.
But a while ago there was a app handling resource lock, but it was not good enough.
Well, almost done, just a moment. Testing.
Lol, one more moment. Good thing i tested well…
Okay, ready, install the Advanced Triggers test version:
P.s. You can import the TEF through Device Capabilities.
I don’t think I have any good testflow for this anyway.
I created a quick flow where I call the same flow tree times in parallell with different number. The called flow sends a push notis. All arrives, but of course in different order for each run.
But the all get executed after each other right?
No way to not have it go that way, because if you trigger multiple actioncards at the same time, how do i / the system, knows which one you would prefer? (Since it could actually be triggered multiple times by the exact same flow(card), so another argument is not gonna help, unless we would have a CurrentRunningFlowID, but we don’t)
Sorry, my comment was created before you was ready with the advanced trigge code.
I did a test with Athoms Start-flow card.
I have not yet installed yor code, will have to do the test tonight as my work needs my attention.
How do I install the experimental version?
This example is a different one to yours.
I want all triggers to happen, in any order, but not at the same time. This where sequential execution is good.
I.e. if multiple flows wants to trigger my SendMessage() at the same time all should eventually go throu, the order is irrelevant, but all messages should be sent. But each call needs to wait for its turn to be handled or the SendMessage flow will/might corrupt the messages.
Yeah, that’s the one I was testing with alr., cards in parallel
With testing it got only unclearer to me while 2 cards returned very different results.
I don’t understand your descriptions, it is too much insider code ‘language’ to me…:
“Execute last one waiting after each [number of] ms.”
What is “last one”?
And does it not execute “at start”, like the other card? And why does it not / why does it? And if it does, why isn’t it mentioned?
“Execute at start, then allow execution after each [number of] ms.”
What card is executed at start, and the start of what card?
“Execute at start, then allow execution after each [number of] ms, finish with last one waiting”
Which last one, and what card is it going to wait for? And what card is going to wait?
Sorry for the inconvenience.
I’m going to try this example now:
1, 3 and 6
Why did 3 run? That should’ve been 4?
The wait time (3s) is correct though
1, 4, 5, and 6
Why did 5 run? And why is 6 fired 6s after 4, instead of 3s?
The wait time (3s) is correct again
I did use start flow (not test flow):
That should now be exactly how it works!
There is your difference
I’ll think of renaming once im done with DC/AVD/TFE/ETC.
when 4 was executed, 5 was not yet in the queue. When 5 was executed, 6 was in the queue, but the last one. So it stays there, until the next 3000ms is elapsed or another trigger is inserted in the queue (which would make 6 not-execute, but drop).
Think off it like a bouncing ball (thats the name )
Every 3000ms the ball bounces.
Now, the options deside if it triggers the first bounce(start), the second bounce (end first 3000ms) and what ahappends after the last bounce with the last in queue.
Why is that, Arie? It is equal to “start a flow” card, or start a flow manually, or from another flow. That seems to me the normal way flows can be triggered.
I did not use the start button itself, and ofc I did not test run the flow using this because the timing is completely unrealistic when using the test function.
Still ‘5’ was fired…
But timings will be different.
The lines themself also cost time in AF, but not when started normally.
I did, my responses and results where based on directly starting the AF from the startbutton, so timings of lines etc. become part of the resulting timers.
You really are quick in adding features. Thanks for serialization.
I haven’t start using this yet due to the tag labels have to be static/predefined, so you have to remember what the different tags is used for. I am currently using your JSON handler where you easy can trace what path is used for each tag. This makes it easier to keep track of what a flow is doing.
Would it be possible to add the possibility to pre-create events in the app setting and then add which tags (number/text/yes-no) and how many of each, and also set own labels for each tag? And the select the event in the cards (new card for predefined events).
The Sets app is doing something familiary; you create the Set with namned states, which then are accessable in the flow.
Maybe this is not possible for tags?