🎙️ The Homey Podcast | Megathread

[Doekse]

Isn’t this already possible? Set it up so that when the water level drops below X, then the pump activates.

[robertklep]

“wait until” can be very useful to implement timeouts (for which I use the HA-equivalent “wait for trigger” a lot).

For example, if I don’t lock my car when I come home, I get a notification asking if I want to lock it or leave it unlocked. If I don’t respond to that question within a certain time (“wait for trigger”), the car gets locked automatically.

Or: when we wake up, wait for the central heating to turn on and if it does (it’s colder than the target temperature), also turn set the the air conditioner to heating mode so it’ll warm up more quickly.

[Cuprum]

@robertklep

“wait until” can be very useful to implement timeouts (for which I use the HA-equivalent “wait for trigger” a lot).

Wait_until(trigger) may be useful, but for me personally it seems quite “overkill” in our current purely event orjented system. For me personally it seems the logics may be simpler, if there is just a quick event->response declarations and no need to think, that “something inside of event chain” may just be sleeping/waiting.
Again, this is my personal opinion, but … if there is such card, then it’s must be very complex and include lot of additional conditions - timeout to wait of course, but also possibility to check additionally all the previous chain. Here was the washing machine example - to stop chain and wait until door closed. But what, if the initial start condition changed during the waiting?

Actually, the “wait until” seems for me more like an additional flow’s internal timer Right now most of such tasks are handled by external apps, but those apps/timers are visible globally. May be benefit, may-be unneccessary expose. During “simple flow times” this was feature - possibility to use one multiple flows ( events actually ) to manage timer. With advanced flows, i think, it’s little bit better practice to use timer inside of one (advanced, multi trigger handling)flow.

So… actually, i think, this description may mostly cover also Robert’s idea…

• Activity "Wait ( seconds )
• Activity “Cancel wait(local?!? name )”
• Activity “Reset wait(local?!? name )”
• Activity “Right now(local?!? name )” ?!?

[robertklep]

@Cuprum

Again, this is my personal opinion, but … if there is such card, then it’s must be very complex and include lot of additional conditions - timeout to wait of course, but also possibility to check additionally all the previous chain.

It can be done much easier.

Take a card that has two inputs. One input is the trigger input that starts the internal timer. The second input needs to trigger before the internal timer runs out (the “wait until” part). If so, the card continues. If not, throw a timeout error.

You can implement this with one of the timer apps, but it would be an annoyingly large flow:

• WHEN trigger#1 THEN start timer
• WHEN timer expires THEN throw timeout error
• WHEN trigger#2 AND timer is running THEN stop timer and continue

And while we’re talking about it: the reason why the various timer apps exist is because Homey’s flow are simply lacking semi-advanced timer functionality that makes a lot of sense to provide out-of-the-box (something like only triggering a flow when a sensor has had a particular value for an X amount of time, so “WHEN the temperature has been >= 20°C for more than 5 minutes THEN…”)

[Cuprum]

@robertklep

And while we’re talking about it: the reason why the various timer apps exist is because Homey’s flow are simply lacking semi-advanced timer functionality that makes a lot of sense to provide out-of-the-box (something like only triggering a flow when a sensor has had a particular value for an X amount of time, so “WHEN the temperature has been >= 20°C for more than 5 minutes THEN…”)

Fully agree with reason for timer apps.
But the complecity i described ( my wildest dreams ) is exactly for Your example
To solve continously and is also now for temperature this is no sufficient to have timeout only. It’s requires also checking… Ok, i can imagine the logic for temperature with only card, You described, but does it seems simple also to Joe, the Average?

• Trigger 1 - if temperature >= 20
• Trigger 2 - if temperature <20
• Timeout 50
• “normal” exit to nothing
• “timeout” exit to action

For me seems little bit “upside down” - but may-be this is my personal problem. The direct actions to manage timer may little bit increase the use-cases. Hmm, for example “to keep the light on when someone is in room - motion-trigger”. Yes, also solvable with one action card, but quite hard to understand and little bit more hard to realize in flow if lot of events land into the one card…

Yes, i think, the Turing Machine is already there, and fully functional - right now we are talking about additional libraries for that - so, it’s a question of taste

[Peter_Kawa]

@robertklep

when a sensor has had a particular value for an X amount of time, so “WHEN the temperature has been >= 20°C for more than 5 minutes THEN…”

Just FYI (in case you didn’t know alr.), and to other readers:
This trigger card exists, and it should be a standard flowcard:

It can compare strings (text) as well.
And it has two modes:

1. Once: trigger once
2. Continously: trigger everytime the condition & duration are met

[robertklep]

@Cuprum

Ok, i can imagine the logic for temperature with only card, You described, but does it seems simple also to Joe, the Average?

• Trigger 1 - if temperature >= 20
• Trigger 2 - if temperature <20
• Timeout 50
• “normal” exit to nothing
• “timeout” exit to action

I don’t necessarily see why this would be difficult? Certainly not more difficult than having to use external apps for timers.

[robertklep]

@Peter_Kawa

This trigger card exists, and it should be a standard flowcard:

Agreed (or at least its functionality should be built-in, the card itself is perhaps a bit too elaborate).

[Cuprum]

@robertklep

I don’t necessarily see why this would be difficult?

Ok, sorry, it’s goes OT…
For me and for You - may-be not. But for Joe the Average may be little bit difficult to understand, why “Error Exit” is the normal process flow

[Waldo]

Nice to see a bunch of my questions have been brought up during the latest podcast episode!

[Rogier_Verheugen]

@Doekse, @Emile and @martijnpoppen

Big cheers to Martijn. Looked like you are doing podcast for a longer period.
Keep up the good work.

[Doekse]

Yeah, he’s a natural

[Peter_Kawa]

About Tuya recently retracting API access, crippling the ‘official’ Tuya app:

I wouldn’t recommend buying that stuff anyways

[robertklep]

I wouldn’t recommend buying that stuff anyways

Athom has strange ideas of what a “mutually beneficial partnership” is

[Sharkys]

I believe it was just attempt to “slap” after “slap”, yet it’s giant against a kid, unfortunately.
Still I understand this approach (even it’s not exactly diplomacy showcase) but we will probably never learn on legal background on who did what and who break what.

Still, probably there should be more shared on this (even I’m not fan of CN operated cloud located in US? (because of multiple aspects, including distance, operation, reliability, dependency, bottlenecks etc.) ), what are now the options, as they did not commit on any. And users might feel to be abandoned. But that belongs to the Tuya app thread.

[Sharkys]

@martijnpoppen thanks for being brave and showcasing another level of community support. Really, hats down, keep what you are doing, for the Community and for Athom.

@Doekse Abe I hope you will keep also this semi-developer podcasts (which are very useful for beginners like me) and that there will be some others great community developers joining you over time. I also like the dashboard news, because it forced me to add one more widget on ISS tracker and this is really nice (design and functionality wise) - kudos to @basvanderploeg

For the future, If I may repeat some “dreams” topic :

• Bluetooth - bridge/satellite and stability/reach wise, eg. also Wifi dependencies I shared with you already (that you probably know already yourself) etc.

[staeff]

@Doekse @Emile since you mentioned that “conditional” widgets are hard to do, you can take a look at how it works for HA dashboard cards. There it is on a widget/card level and not driven by an automation/flow.

I think you already have the buildings blocks with all the preexisting AND cards, they just would need to be checked every X seconds if the dashboard is visible.

But I would already be happy with the limited functionality of date, time and presence (and maybe device state) which i assume could happen even more realtime.

[Request] Conditionally show widgets (e.g. by time or user presence)

I have mentioned it a comment already, but for better visibility now also in a topic. Not all widgets are needed all the time. For example I don’t care about my camera when I’m at home, about my lights during the middle of the day, my office devices on a weekend or my AC in December. It would be great to have the ability to at least have basic control over the conditions under which certain widgets are displayed. Of course in edit mode they should all show up (maybe with some icon to indicate …

[Doekse]

Hi everyone,

The fifth episode of the Homey Podcast is now live!

In this final episode of 2024, @Emile and I reflect on an exciting year—revisiting the features we launched, the announcements we made, and the highlights that defined our journey. We also give you a sneak peek at what’s on the horizon for Homey in 2025.

Wishing you all a joyful holiday season and a fantastic start to the new year. See you in 2025!

P.S. Leave your questions for the next episode in the comments below—who knows, we might answer yours!

[Peter_Kawa]

About the increased ads activity.

Why can’t I dismiss this un-usable item banner, as (Pro 2019 user)? Or just when I happen to be not interested?
It’s just annoying.

I don’t want, and I’m not gonna buy Moods. Why can’t I dismiss this useless menu item?

[Benvo]

That’s great once that becomes available.

Will Aqara cameras also be supported then? Currently, they are not.