I will add the advanced triggers where I need serialization, but then most likely send the arguments as a JSON in “Text1” and use your parser.
Use an Advanced Virtual Device, create fields as you like and select create tag for each field.
This avd would be your set.
Avd is from device capability.
Can you use this device as an event and send it with advanced triggers, or is it more like an advanced variable?
Well it can be made either way.
Please explain in more detail what you would like (to achive)?
I have some temperature sensors I want to check whether the temp is ok/high/low.
Before I found out that advaced flows could parse JSON I clone the temperature check flow for each sensor.
With JSON I could make one generic check flow and send the new temperatur value, high and low threshold and sensor name. But as Homeys built in JSON parser cretes tags named “Result” I got an unreadable flow with “if(Result < Result)”. It worked but looked terrible.
Then I found your JSON parser and at least now I have “if(Number1 < Number2)” and it is easy to take a quick look in the parser card to understand what they mean.
With your Advanced triggers I would still have “if(number1 < number2)” but I would need to remember what “Number1” was as there is no explaining label for it. And when starting the event I would need to check the called flow to set correct arguments. So, a bit back to Homeys JSON parsing.
This is where it would be nice to have tags with own labels, and I could have “if(temperature < thresholdLow)”.
I could achive this with Homeyscript but I like to have the flow grafically if possible.
Well, yeah, dynamic tagnames are possible, linked to a device or app.
For instance, you could create an AVD with fields with the disired tagnames.
Issues is, thaat it will not be scoped: executed the flow where you use that AVDs tags twice at the same time, and you will get straigns results.
Afaik, there is way that i could create scoped tags/variables that have a tagname that can be set dynamicly.
What i mean is:
- If i create dynamic tagnames through App or a device, those are scoped to the device/app, not the flow. So you cannot run the flow twice at once or the results are “random”.
- If i create flow-scoped-tags or variables, i can only do that through flowcards which have pre-install-defined-tagnames.
I could for instance create a actioncard that retrieves scoped values/tags from the background (when you give an extra FlowExecutionID, just like Retunr cards), but then you are back at tags like Text1, Text2, etc.
How? Or do you mean, i could write it in code and in the code it would be more readable because of beter in-code-variables? There is no way you can use HS to create beter (scoped) tags, right?
Sounds like there is no perfect solution for this.
I could use AVD and create my tagnames and then use “Advanced triggers” to serialize the calls to the flow. That would protect the AVD.
I mean that if I use HomeyScript instead I would do all calculation in code.
I do not know node.js (yet, will learn soon) but something like:
int temperature = json.parse(“temp”, arg);
int thresholdLow = json.parse(“threshold”, arg);
if(temperature < thresholdLow)
More readable. But not graphical coding.
Indeed, a solution could be created to easily parse an AVD(s values) as JSON to use in HS.
But i don’t see a (card/tag) solution for Advanced Flows.
No, seems not to be easy.
I, and many more, have allready, in various ways, asked Athom for “scoped variables” or something simular.
And perhaps it might come some day.
And than at least you could create scoped-variables and set them at the start of a flow with the arguments, so the rest of the flow becomes very readable.
But as long as i/developers have no control over the values retrieved directly by tags (so we could scope them), the solution lays with Athom alone.
I started to use the Adv.trigger now.
What is “Flow execution ID” in some of the cards?
“Return Triggername(Flow Execution ID) with (Text 1, Number 1, Yes/No 1)”
I see that some of the cards has “Tag” instead??
Start Triggername/Tag with (Text 1, Number 1, Yes/No 1) and Set Wait to…
Those are two different things:
- The alternative TAG after a triggername, is just a way of entering a name through text or a token, instead of a pre-picked autocomplete-list.
This makes it easier to start flows dynamicly; You dont need to duplicate different start-a-flow-cards, just dynamicly create the names.
Now, about the Return Cards and there needed Flow Execution ID.
You can have a big advanced flow started with an advanced trigger and then have that flow return something to the startflow card.
When you execute the top-left card it will run the bottom row (not in de editor ofc.) and that row will return the values as tokens to the first(!) top-left flowcard. Now you have the response from the scoped bottom line!
This example for instance, will write "This is the response if false! into the SimpleLog.
If you switch the Logic Card around to 1 equals 1 (and save the flow) and execute the top-left card again, it will now have a different response in its tokens.
The flow executionID is needed to make sure the return value belongs to the right flow execution.
TEF can be imported through App Settings in Device Capabilities App
These Return cards make it possible to create Flows like Programming Methods, it’s a partial replacement for HOOP.
Ok, I think I understand. Or no…
The Return-card is used for exiting the flow with arguments, so should be last card in the flow (but doesn’t have to) as it will let the caller flow continue if it is waiting?
And if you returns a Execution ID you may use it when the flow is started to know which flow is starting it?
Where is the Execution ID created? Automatically when flow is started?
But how do you use the Execution ID in the flow? I see that you returns it but I do not see your flow using it for anything.
What would happen if I do not enter any Execution ID?
Indeed, the Callercard will wait for all triggered flows to be completly finished with the whole flow (so don’t put waits with more then 30 seconds in it, it will timeout), and then it will get the tokens from the first executed Returncard (there could be (by mistake) multiple returncards executed because you can trigger multiple flows or have multiple return cards)
Well, yeah, i guess so, the ExecutionID is generated at the Start-A-Flow(Then)-card and all triggered (When)flowcards will have the same ExecutionID, see the example below.
I think you have the thought here, the other way around: The Returncard has no idea which flow it is in, when a flowcard is executed (like the return card) the App only knows it’s given arguments, i do not know which trigger it belongs to or which execution.
The lines you see in the editor; the app has no idea about those lines and there is completly no way, hacky or not, to know those lines (since you can have duplicated cards with the exact same arguments, and those are the only ones to start the search from with certainty).
So, it is the Returncard that needs to know which trigger it belongs to.
Now, i could make the ExecutionID completly unique, but since the return card is ment to give a returning value to the actioncard (Callercard) i use the same executionID for all triggered flows with the same name. This is on purpose but could be change or when needed a Unique Execution ID might be added.
Perhaps i should call the current one ReturnID instead of ExecutionID?
The exact same thing that always happens when you use a Start-a-flow-card: It will execute the flow and, if selected, wait to finish, and then its finished: the tags will be empty.
The return card will be waisted.
These logs will write the same-as-each-other executionID everytime you execute it.
Come to think of it: The Eventname within the Returncard is absolutly useless, i don’t know why i included that
Might be because i started off differently.
I’m improving the cards right now to make stuff more clear.
I think I understand now.
The Execution ID (think the naming is ok) is used to connect the returning-arguments to the correct caller. So if a flow is triggered by more than one Adv.trigger you need to select the correct Execution ID (from the correct trigger card) that you want to send the return-arguments to?!
I think the Execution-ID-field in the return card should be mandatory then (maybe it allready is).
Ok, so only the first return-arguments are received by the then-start-card, even if more than one flow is triggered and having return-card. Good to know.
Maybe “Trigger card ID” is a better name? As it is for connecting to correct trigger-card, if I have understood everything.
I am changing it tho, because i am changing the cards (just in names, everything will keep working) and it is better this way i think. Also, there might come a real ExecutionID some day, so beter to be clear on it now.
Here is what the version that is in test now, looks like:
When I use your example with delay blocks for the 2th and the next ones it works, but when from 2+ flows got triggered at the same time it is not doing anything. Setting trigger mode to standaard, all 3 texts are coming out but not sequential offcourse.
Feature request would be to know when the last queue trigger is finished to trigger music again on my chromecast.
I’ll fix it and add a card the know when a queue gets cleared.
I do have some business to attend to first this week and when i have time for the Apps, i’ll first by busy updating BetterLogic to SDk3.
After that, i’ll pick up the support/feature-request list again.