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.
What is your use case?
Perhaps there is another solution for it.
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.
Well, unless you create a complicated and resource-hungry full-access app, this is currently not possible.
Sorry 
