then I got this flow here, which manages a few of these thermostats in a certain period of time. Now, while testing it shows the delay working but in reality the variable is set back after 55 seconds (that’s the default interval I set for checking but which should not be executed while a delay is at word) to the default value (SZ Früh/Abend).
What happens if you use the AF delay function card?
Btw, the chronograph app was redesigned for SDK3 and taken over by @Arie_J_Godschalk.
After the release of the new app, a few cards no longer worked as they should. So it’s quite possible that this is a bug.
So I recommend posting the problem in the relevant thread or contacting Arie.
I tried also w/ the AF Delay card with the same problems, also, Homey timed out (disconnected) during testing. Maybe the 55 seconds interval check of several flows is too much to deal with or this is an underlying problem with the Delay card. I got several notifications, from a notifications card which should fire only after the delay has finished, w/ out a running delay.
I guess, for the time being I’ll go back to Tado for managing the heating, it’s not bad just not as flexible …but stable
Note, I get the strangest phenomenons when I use “test flow” or “Start flow from here”. Including rate limited timeline, time-outs / disconnections like you describe, sometimes Homey is offline for 5 minutes.
I think the best test scenario is something like this:
You can change te variables manually to see what happens.
First temporary change the 30 minutes delays to 90 seconds to see if the temperatures gets set without waiting for half an hour.
Oh, and the target temperature can also change when the thermostat is in auto mode I expect, f.i. when a new time block with an other target temperature is started by the scheduler
Maybe this condition should be added, when you want to filter manual changes:
the ambiguity of the scheduled temperature vs manually set temperature occurred to me as well … I’ll check your proposal later. I’m a bit exhausted, I think I spent like 10+hours trying to solve this for 2 homes.
First start of this flow: 09:50:00 → Timeline notification: 09:50:45 (= 45 s delay)
Second start of this flow: 09:50:30 → Timeline notification: 09:51:15 (= 45 s delay)
Third start of this flow: 09:51:00 → Timeline notification: 09:51:45 (= 45 s delay)
First start of this flow: 09:54:00 → Timeline notification: 09:55:30 (= 90 s delay)
Second start of this flow: 09:54:30 → Timeline notification: 09:56:00 (= 90 s delay)
Third start of this flow: 09:55:00 → Timeline notification: 09:56:30 (= 90 s delay)
First start of this flow: 10:13:00 → Timeline notification: 10:15:00 (= 120 s delay)
Second start of this flow: 10:13:30 → Timeline notification: 10:15:30 (= 120 s delay)
Third start of this flow: 10:14:00 → Timeline notification: 10:16:00 (= 120 s delay)
For me the internal AF delay card works as expected, also with 90 and 120 s delay, there was no timeout. But the combination with a trigger card “Every x s/min/h” and a delay card with a longer delay than the trigger interval doesn’t work as it might have been intended.
For this case you need to use a timer app and a condition card “Timer is running/not running” to prevent, that the flow will be executed several times.
Hey Dirk, I tried to explain, the delay card which comes with Adv.Flow, does not have the time-out issue.
But, the single Chronograph delay card, and the HomeyScript ‘Wait’ command kill the flow when the set delay time is over 89s.
I had this before but I think I had to add “check the current status of the window” in order to prevent switching on the thermostat while the window is already open (yes, some guests are doing it). And, I concluded I can kill the open windows issue with the frequent checking of the status.
Do you think frequent checks hava a negative impact on Homey?
Sorry @Peter_Kawa, I had overlooked that or misunderstood it.
This should also not be a problem at all. Just add a “The contact alarm is on” or “This zone is active” card.
But I know that the better you want to make automation and eliminate every possible problem, the more complicated it all gets.
I don’t think you can give a general answer to that. As with many things, quantity matters. But if you can avoid that kind of flow, then I would do that. Based on the information so far, I am firmly convinced that this is not necessary for your use cases.
Btw, you use the Zone becomes active and Zone is active cards. Do you know how this card works? Are you aware of which devices can activate a zone? Do you know that you can exclude devices from “zone checking”?