You can try with this one…
1 Like
Yeah I’ve adjusted it today with a variant of the script @Sharkys posted.
The TEF is also updated.
2 Likes
Thanks!
1 Like
Still fiddling around with my flows and AVD’s trying to ease system load.
Off course there are many roads that lead to Rome and for me it’s not always obvious which option comes with the least load, if there is any difference at all.
For example, is there any difference in how following scenario would play out?
‘regular’ sensor changes number capability > use Listen (watch) Card to get the new value > do some BLL-calculation within a flow card > store the altered value in a BLL-variable > use reflection to load the BLL-variable in an AVD
or
‘regular’ sensor changes number capability > use reflection to load the device-value in an AVD and alter it directly within the AVD with some BLL-calculation
Are there any fundamental technical differences between these two options? Will one of the two options result in significant higher system stress (adding up whenever the specific action will occur a lot of times)?
On a more practical level there are quite a few differences. For example, the latter does not require any flows making it somewhat leaner. On the other hand , the first stores a BLL-var as an intermediate step making it possible to retrieve that value for further processing even if the Device Capability is malfunctioning (though the app is needed to get it updated in above scenario).
No, the listen (watch) card is just as “heavy” as reflection.
However, normal flowcard triggers (from the devices themself) are less heavy, because they do not require an homey-api listener (which is what uses a load of resources).
I hope to put time in updating to the new homey-api next week, right now i have a holiday with the kids.
2 Likes
Thanks for responding! (Even on your vacation.)
Just wondering then, if ‘regular’ device trigger-cards are easier on Homey because they don’t need the homey-api listener, would the use of a flow with a set action-card to populate AVD-fields rather than using direct reflections be lighter then? For example, will the second option below use more system resources?
- ‘regular’ sensor changes number capability > use Set Card to store the value in an AVD-field
vs - ‘regular’ sensor changes number capability > use reflection to load the device-value directly in an AVD-field
How does the homey-api listener actually work when a flow gets executed? Will it get invoked only once (when needed) in a flow (even though multiple cards rely on it)? Or will the earlier example (see below) invoke the api twice, once for each card that rely on it? Resulting in a higher system load.
- ‘regular’ sensor changes number capability > use Listen (watch) Card to get the new value > do some BLL-calculation within a flow card > store the altered value in a BLL-variable > use reflection to load the BLL-variable in an AVD
Since apparently it is the homey-api listener that potentially stresses the system, it could be useful to have a list of flow-cards and device-properties that rely on the api as a reference. That way users could estimate and compare themselves the need and cost of using different options to get something done.
Related to above contemplation but somewhat off topic (because on a more general level) I have always been wondering at what point a flow actually begins using considerable amounts of system recourses (relatively speaking). For example;
-
Sometimes I have just some isolated when-cards (trigger) lying around in different flows. Those could be work in progress, deprecated or random clutter. Without than-cards (action) linked to them, nothing gets executed effectively. Should this be avoided nonetheless from a system-load point of view?
-
Similarly, when I have a flow with a specific and-card (condition) in order to decimate the number of triggers from a particular when-card before going to a ‘heavy’ action follow-up, is this good practice? Or could the sheer number of false triggers before the condition is met already stress the system considerably?
-
Should these scenarios play out differently when using the Listen (watch) Card as a trigger?
Sorry for digging deep in this matter. I am probably making it far too complicated. 
(If my H23 wouldn’t be stressed out so often, I probably wouldn’t care that much.)
In any case, don’t feel obligated to answer during your vacation.
When using the “When x is greater than for y minutes” card, it does not trigger if the value is specified as a number variable. If I replace the tag with its value, then it triggers.
This version works
No, tags cannot be used in this flowcard. I thought i had that written in the info of the card.
I have created a lot of AVD’s for all kinds of things and the memory use is reallly high for Device Capabilities.
Around 87 mb after a Homey restart but soon after the restart it is rising to 125 mb and higher.
I see a lot of restarts for the Device Capabilities app according to the red marks on my avd tiles.
Homey is crashing also and asking me to empty the cache.
I hope you can find the time to reduce the memory use for the app. 
6befa3b0-6554-442e-89f0-4f054f3013e1
Thanks.
At this moment i have a MQTT server that pushes messages.
I made this flow
There is difference between the MQTT message that are revieced on the MQTT server then that are displayed on the device. It looks like there is a delay and the delay is become bigger and bigger.
If i reset the MQTT client app the delay is gone for a few minuts.
So sounds rather as MQTT app issue, or?
This sound logic. But it worked fine for more than one year. Mqtt cliënt app is not changed and my flow is also not changed.
This app changed a lot and the firmware of the homey 2023 is changed.
The problem is now 2 weeks i think
Use a logger and see if the delay is also there. If it is, it’s in the mqtt app.
Added a new request on bitbucket 
A New “Flow And” card:
“And , is for
example:
the shower is on when there is water running and the motion sensor is on but only if the water wasnt running for more then 2 minutes.
When is on
And , is <10> for <2 Minutes>
Flip the switch.
Sorry, I don’t know how to open this verbose card editor. In my UI I don’t see this text. I see a tag icon, I can choose a tag and it is displayed correctly. Took me a while to understand why it wouldn’t trigger. Not a huge problem, although being able to use named constants would’ve been useful.
Anyway, this card simplifies my flows a lot!
Yeah i know, unfortunately, thats just not possible, because i would then get a token id, not the updating value. So the app would not be able to know what to compare the capability-value with.
Yeah, the earlier screenshot was from the standard flow editor (mobile Homey app), but in the Adv. flow editor, the same alert really is shown also:
I don’t know of any other flow UI’s.
App creators don’t have the possibility to hide the tag icon (and link).
While Arie explores the edges of Homey’s possibilities, this is one of the little ‘need to knows’
I’m curious which flow editor UI you use! I was under the impression these ‘helper’ texts, like Value - No tags! are not flow GUI specific
Okay, the update for DC is not done yet, and next week i have holidays.
I’ll continue in 2 weeks.
2 Likes
