Are homey flows "stupid"

So it does?

But is DOES do something every minute, especially between the given times it will send useless off commands though the mesh. Do this a lot, and the responsiveness of the devices will suffer.

And this only because you like to have less flows. De design principle of Homey is not to have few flows, but to only check a flow when it is useful (i.e. the trigger happens). So you introduce 24*60-1=1439 useless triggers just to turn a light off once, all to save a flow?

Would you rather check your clock every minute to see if it is time to get out of bed, or do you set an alarm?

i agree that it is not the perfect flow, but the question was if it is possible to do it in 1.
And i only showed it is possible it can be done in 1 flow.

Also the load this flow is causing is almost nothing, time checks run always in the background, these flows only lift on already running processes.
It does not matter you do something every X time, this does not increase any load on homey…

That there are 1439 useless triggers is no problem for Homey, as (php) developer i agree that it absolutely not beautiful or optical code but that that was not the question to make perfect code.

@Rocodamelshekima
It checks its internal database (logic value) for the state of the light, it does not check the light state of the bulb itself, the states are updated by automated internal processes, not by triggers.
Checking logic values (database) are very low usage processes and are very quick, so no problem here.

Again, the flow is not the most optimal of beautiful flow but it works and is save to do.

Run in the background does not equal no load, and it’s not like Homey has 8 cores. Phone apps designed like this are the ones that eat your battery in no time.

I have close to 400 flows, so you’re defending it is possible to cut this in half at the cost of 280.000 useless triggers a day. If you agree it’s not good code then at least add a disclaimer: “don’t try this at home”.

By saying it is doable and at no cost, you’re teaching people bad habits that may very well bite them, and when it does they will have too many flows to fix it.

And mind you, you assume state checks are free, but that depends on the app’s implementation. and more often tan not the then is triggered way more than intended causing heavy load.

This will not be evident immediately, but accumulate over time as more badly designed flows are added. And when you notice Homes is sluggish or unresponsive, Good luck then trying to figure out why your Homey load is 400% all of a sudden.

4 Likes

But what about cards like “The light/temperature/consumption has changed”?
This is an actual screenshot from a Xiaomi Light Sensor. The lux value changes every second sometimes. And with every change the flow is started. These are clearly more triggers than 1440 per day.

I know:
– There is a “new” card “X becomes more than / less than…”, but you can’t use this card for all flows.
– It’s possible to adjust the interval of data/measurement values in the device settings, especially for Z-Wave devices, but it’s not possible with the Xiaomi Light Sensor for example.

This is just a question of an impartial interested person.

I have the same sensor. I haven’t seen it report every second though, but it will send values faster if the value changes significantly. And it is battery operated, so it is designed to only send data when it is actually needed.
You are right in that these will also trigger flows a lot if ill designed. With these that is unavoidable and needed, so there the things @B3rt mentioned for protection are right:

  • Make sure you test the for the desired range a.s.a.p to make sure the flow is stopped when the value is outside the range you want to react on.
  • Make use of booleans, or device states or even better turn flows off that are not supposed to work at that time
  • If present, favour “value becomes greater/less over the above bullet(s) as they will trigger way way less.

So an efficient flow set could be:

  1. If the luminance changes and the value is lower than 100 then turn the light on, enable flow 2 and disable flow 1
  2. If the luminance changes and the value is higher than 200 then turn the light off, enable flow 1 and disable flow 2

Alternatively, equally efficient and way less complex:

  1. If luminance changes to less than 100 turn light on
  2. If luminance changes to higher than 200 turn light off

As you know the above is triggering very little too as it reacts on change from higher to lower or vice versa which happens very little.

These strategies are reducing the commands to turn lights on/off by the thousands. You can/should also test device states as @b3rt rightfully suggested. But I didn’t need to in the above examples so I avoided the risk that also triggers more work than expected/needed. Logic on local variables is faster and disabling flows is the most obvious load reduction.

As an added bonus to the above performance boost, the first strategy will also avoid the before mentioned “computer says no” behaviour:

Suppose the brightness gets higher and Homey turns the light off, but you need more light and turn the light on manually. Without turning flows on and off Homey will turn it off again, disobeying your manual override. The above stategies will allow for manual override (or other flows that also have reasons to manipulate the same light).

i propose a new title: “Let’s make flows smart again”. :wink:

1 Like

Thank you for the informative answer. I think there is nothing more to say.

You could use H.O.O.P. (Hope) - Homey Object Oriented Programming - Apps - Homey Community Forum (athom.com)

If you use it like this, you only need one flow:


Gedeelde Flow | Homey

1 Like