When I set the text argument of my TriggerCard to a Variable and run await myTriggerCard.getArgumentValues() I get something like this back: { myArg: '[[homey:manager:logic|86669477-a2a8-41e3-a811-d49d8753b5e5]]' }.
How can I get the real value of the token in such cases? And also how do I now in turn subscribe to this token getting changed?
On a different note, is it possible to disable the input of tokens for arguments and only have the user type in text?
Afaik:
That could only be done with the homey-api and the required full-access permission. There is no way to read those values in a app with default permissions.
Afaik:
You cannot.
Again, afaik: you cannot. Users will always be able to include a token/tag into the text field.
Thanks for your answer. I get that the second and third might not be possible. But that the only way to get the value of variable/token in an argument of a flow would be through having full access seems very ridiculous. Wouldn’t then basically every app which is not just simple zigbee devices need full access?
Well, if a token/tag is used in a argument, and the card is triggered/fired, you will get the value of the tag in the argument, instead of the tag-reference.
However, using getArgumentValues, you will get the reference instead of the value.
So you indeed cannot use argument with tags in it to listen to changes or anything.
I myself could also think of some use cases, like having a trigger based on a argument containing a variable.
Unfortunantly, its just not how the homey SDK is build.
I have multiple flowcards that are “tracked” and usually write in the note for thst card, that tags are not allowed.
My usecase is that I configure the schedule which is used to fire the trigger through arguments. When the arguments change I need to reschedule when it’s fired. I think for me personally it’s enough to do it with just text and not tokens/variables. But a user reported that schedules don’t fire when you do use tokens/variables, because the actual values are not resolved.
Your explanation makes sense. But the design of that part of the SDK feels a bit broken in this case.
I’m building a new app for Homey (my first, so get ready for a potential stupid question).
I’m facing a similar challenge in my code, but maybe not entirely the same.
I have a trigger card that sets a number of tokens.
Next to that I have a number of action cards that need those token-values.
I know I can expose arguments in my action card, that accept these tokens and via the flow UI they can be passed from the trigger card to the action card.
But… (for convenience) I want to use the token values from the trigger card directly into to code of my action cards. The names are always known and are always the same, and the trigger and action cards should be used together.
Is it possible to use tokens from a trigger card inside the code of an condition/action card without passing them as arguments? I only need the value of the tokens I’ve set myself in the trigger card.
Well, not really. Because you could never match the actual flow that is executed.
You cannot know which triggercard is connected to (and more important actually executed the) which action card. In the background, you get no information on which flow-“execution” is running, so there is no save way to pass information in the background.
No, that has nothing to do with it, that’s just to validate which trigger should really run. But that could still be multiple and you still wouldn’t be able to ID the actual running flow(cards).
Believe me, if tried many ways to achieve this, but unless a Flow-run-id is given by Homey/athom, you would only be able to “guess" which trigger belongs to which actioncard.
You could minimize it for the user to use 1 token.
Give the trigger a RunIdToken (with a random or incrementing number) which the user needs to supply to the actioncard. Then with that number you can internally connect the trigger to the action and thus have the needed variables available in the code behind the actioncard.
I kinda do this with Advanced Triggers for the return cards.
But there is no way around to at least have the user connect one token from trigger to action card for you to connect those 2 in the background.