1st of all, you are now using a brand new Homeyscript test version, Peter.
Just install the live HS app version if you want things “back to normal”.
Not sure if you should inform Arie already about this issue at this point.
You probably should be able to pinpoint the issue by reading the tut from Jeroen (Athom) and contact him about your findings and/or for support here, thx:
1st of all, no Peter, I am NOT using a test version. This version is live - for all. Thanks.
I have read the tutorials for sure, so let’s put some fact on the table here:
Your existing HomeyScripts will use the old version of the API.
When you create a brand new HomeyScript, the new homey-api will be used.
“apiPost” will no longer work, and there is no work-around mentioned in the migration info.
To the rest of you - I finally found a solution using runFlowCardAction(). The problem was that I tried to read and update the same Device Capabilities fields in the same script. This crashed the HomeyScript app. Solution? I put all the read and write calls in separate async functions - then it worked.
@Arie_J_Godschalk , i got a Device that always returns the “manufacturer of the Device” with the:
card. It think it is not a "manufacturer issue ", because i got several devices from that manufacturer and the other devices returns if i changed it from Web-app and so on, so i think it i is Device-issue from that manufacturer. But, what should i write as the issue (capability issue) to the manufacturer? To pinpoint what the issue is.
Anyone know why I get this blank screen when I try to edit a device? I have a bunch of them but since today I am getting this screen when you click ‘connect’ when creating a new one (repairing an existing one doesnt help as well). I tried rebooting the homey but that didn’t help
Arie, do you have an idea why we can’t use a var/tag in this trigger card?
I’m aware it’s a limitation of Homey firmware at the moment, but I don’t get why it wouldn’t read a variable’s value, when that value is the same as a manually entered value.
Maybe you once discussed this with Athom already?
It would be very nice when we can trigger flows by a timestamp for example:
This depends on the functions of the roller blinds, not on the Device Capabilities app and/or an Advanced Virtual Device. So if the roller blinds doesn’t have a function to stop, then it will also not work with an AVD.
Because i only get the token-reference, not it’s value, when i listen for a trigger.
Currently, everytime you save/change a flow containing this trigger, the app gets a notification that the use of that trigger has changed.
Then the app reinitializes the “watching” of ALL the flows containing that trigger.
(Ofc the app does it a bit smart and checks which triggeres have changed).
But if the app would get the real value, that would mean the notification and reinitialization would happen EVERYTIME a token-value changes.
In many cases, this would generate massive amounts of updating the watchers, i think resources would increase like crazy.
Personally i would want that!
What i would like i guess, is that a app (using the homey-api like DC) could watch for changes of a token.
Than, as developer, i could create a less resource-needed script to archive the same thing.
But unfortunately, even with the homey-api, you cannot listen for changes of tokens.