Are homey flows "stupid"

You can probably also cross a railroad without checking for trains every day for a year if the track is not used frequently. Until one day it hits you… (pun intended). I don’t recommend it to anyone.

What is also weird about your implementation is that it’s kind of a “Computer says No” implementation: Let’s say it’s a rainy day and it’s dark. You can try to turn the light back on during the day but Homey will keep turning it off. That would decrease the WAF close to zero in my home. Automation should never overrule the user IMO, unless it’s for safety.

2 Likes

Struts said: “you could trigger other flows through a flow”

I use this approach. It has caused me no end of frustration that home automation systems (not only Homey) use triggers to evaluate function execution instead of cyclic condition check like you find in industrial plc systems. Simple OR conditions are not available, it all relies on triggers. As I struggled with increasing flow complexity I was forced to rethink my approach. Now I have one flow folder where inputs are read, these flows only trigger other flows. Then I have one folder for each room or zone where logic is performed, these flows also only trigger other flows. And finally one folder for outputs where flows are triggered by the logic flows. Not quite industrial plc level, but less confined than the simple trigger approach. FlowComments also makes it easy to backtrack flows.

Cheers

1 Like

So basically you created your own triggers? :stuck_out_tongue_winking_eye:

My Flow Event Bus app was created to implement a similar idea: inputs emit events, and events trigger other flows. It adds an additional layer of abstraction compared to your setup (where inputs trigger other flows) to implement even more loose coupling.

Your app sounds interesting, I will have a look :slightly_smiling_face:

1 Like

Sounds interesting. Could you post an basic sample?

1 Like

They should take a look at smartthings app. You can order the rooms in the app, and you can set automations and flows separately.
That is perfect.
Please athom do it

Hi Christer!

I get your frustration here!
I found the best solution for this specific problem to be an app called «timer». It lets you (if i remember correctly) have a certain light on for a predefined amount of time before it turnes it of, using only one flow.

Hope this is helpful!

// Cheggen

Let them know! I don’t expect they read the forum.

1 Like

@cortinaman Looks like you’re ready for H.O.O.P.
Create flows how you like it / need it. Just released.
(And no, I don’t get money for this. Just a happy user)

Use as trigger:
IF: Every 1 minute
AND: time between: x and x (AND light is OFF as extra)
THEN: TURN light on
ELSE: Turn light off

This should do the trick you intented with 1 flow

Thank you.

With the “every min” part, does it makes homey.app work harder?

not really, only when it actually does something every minute.

In your case it only checks every minute if it meets the set params, only when these are met (it is between x and x) then it switches it on.
Outside the x and x it will set the light OFF, this also only wil be executed if the light is actually on, homey only changes the state of the device if it has a different state as it is curruntly set.

I have many crons running (crons are time triggers) every X min do that etc
These crons are not a lot of load for Homey…

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