Why isn’t this working?
Aren’t homey checking the flows if time is included?
Why isn’t this working?
The else part will never be executed. Obviously.
What are you trying to do with this flow?
Why is it obviously? Should think that a smarthome is smart enough to know that the clock is after 18.11
I want a light that is in a hallway ( to give a little light to my kids bedroom) to turn on 1900 and turn off at 0700
What @RoyWissenburg said
I know, but again its so stupid with two or more flows with everything.
Didn’t need this with smarthings.
In my opinion this is a huge drawback that homey is not smart enough to know that the flow contains a time frame.
But it is what it is
If you know it, why are you asking?
If you want something smarter, you can test this app:
I know that it work’s with two flows, but hoped that someone with more experience with homey could tell me a smarter way to build the function i want
Thanks for the tip
My list with “unnecessary” flows cares
I also use a very expensive solution for some lights.
Homey turns some lights on and my wife turns them of. The last option costs lots more than a Homey.
But it uses one flow.
So then you create a flow that mentions neither of these times but a random time in the middle, add a useless and clause and expect Homey to be smart enough to guess what you actually meant? I’m pretty sure that no smart device will get your intentions form the specs you gave Homey, or us for that matter.
If you really want to you can get this done in one flow (though I’d not advise to do so). But the way you started the topic is not a very inviting to jump in for help.
So why did you post, just to complain that you bought something that is not to your liking, or do you need help?
Why so serious tone?
Perhaps I misunderstood you know, but I guess you are referring to the yimesi have in the shared flow. I will guess that you understood that this was just a test flow so i didn’t have to wait until 0700 for the light to turn off😎
Thanks for the tip, but again im not impressed with how “smart” homey is.
I was hoping that it would know to turn the light off since the when part says 0700, but il guess im asking to much.
Also tried with a logic:
When light was " No"
And time was between xx-xx
Didn’t work either.
I will just use a timer, thanks
I think it is not a matter of device (homey or a smarter one)… you should first refine your approach to Logic. Hubs are stupid … They do what you ask them and in the way you do it.
Homey is designed differently, for two reasons:
- Simple flows are easier on beginning users;
- Homey can run more efficient this way.
To keep the Homey workload low, it is built purely event based: the trigger specifies when it a flow should be evaluated or executed. So every flow has an exact reason to activate, and until that happens, the flow is not evaluated.
The and clause in a flow is only to give additional tests to see if all the right conditions are met when the trigger happens. So that is checked only immediately after the trigger to see if the event is to be used or not.
So the best way to keep the system running smoothly is to use two flows, one that triggers at 19:00 to turn it on, and one that triggers at 7:00 to turn it off. That way you may have multiple flows, but little load on the system, because that doesn’t require Homey to keep track of timers. And each flow is small and has a single purpose. You can even have different and clauses for both.
Athom could have opted to use less flows with more complexity. That would result in Homey being able to actually do less things simultaniously, and less easy to understand for beginners.
It is a pity though that Athom does not allow for multiple triggers. That would reduce flows without sacrificing speed or much simplicity. But I expect that has to do with the fact that it might pose problems with local tags. If you allow multiple triggers with different local tags, tags can be undefined when a different trigger is happening than the one delivering the tag.
Thanks for the explanation👌
“It is a pity though that Athom does not allow for multiple triggers.”
In a way it does actually, you could trigger other flows through a flow, or change a variable from different flows that activates a specific flow. With that said i understand what you mean.
Yes, if your flow is complex and you need multiple triggers, the “start a flow” card can be used by the other triggers to avoid duplication. However, if six buttons turn the same light on, it doesn’t really help because it then adds complexity instead of reducing it. Combining them in one flow with multiple triggers would not violate the original design principles in a significant way.
hmmm wouldn’t you be able to group that with the < group > app? Never tried, just crossed my mind.