Adv. flow doesn't honor delay for managing tado thermostat

[thobu]

I need your help. The set up is the following:

• one flow sets a variable to YES once the target temperature is set manually
  

  

• 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).
  

  

The goal is to delay the setting of the temp variable (SZ Früh/Abend) for the duration of the delay.
Any idea: maybe I’m missing something fundamental

[Peter_Kawa]

I’d suggest you add logcards (f.i. Timeline notifications) to every flow action, with a description which makes sense to you.
That way you can “see” what’s happening, and when, and what not.

[DirkG]

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.

[APP][Pro] Chronograph - Adds precise timer, stopwatch and transition functionality to Homey

Chronograph Adds precise timer- and stopwatch functionality to Homey. Features Create timers and stopwatches directly from flow cards, no need for a prior configuration, Start timers with a duration in milliseconds (fractional seconds), seconds, minutes, hours or days, Start stopwatches without a predefined end time, Trigger flows at exact timer- or stopwatch durations with millisecond (fractional seconds) precision, Self-explanatory flow cards for easy integration of timers and stopwatch…

[thobu]

I had the same problem with the default delay, I was only checking it against other apps… so I think it’s not related to the delay, I think …

[thobu]

I have some timeline notifications … but only those that reflect the currently set temperature. Do you suggest to create one of for each and every step…

[Peter_Kawa]

@thobu

Do you suggest to create one of for each and every step…

No, sorry, not in this case. Only for the parts that don’t do what you expect them to do.

Hey, I didn’t know about this Chronograph card yet

but I remembered this from the “Wait and Switch” app:
running flows get timed out after 89 s.
As one might expect, that is not the case when you use the in-house delay card.

Here’s a test flow and the results which show this behaviour.

.
Result: Only part #2 action cards got fired

.

When you want to use Chronograph, use these two cards:

Result:

[thobu]

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

[Peter_Kawa]

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:

[thobu]

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.

[DirkG]

I did also some simple tests.

First test with 45 s delay

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)

Second test with 90 s delay (because you said that there will be a timeout after 89 s)

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)

Third test with 120 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)

Conclusion:
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.

[thobu]

@DirkG

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.

Thanks for the research. Once I’m ambitious again I’ll revisit this topic and try out the Timer approach.

[thobu]

would this make any sense

[DirkG]

My problem is that I don’t understand exactly what you are trying to achieve with the flow.

The first flow is easier for me to understand, so I have modified this one (in your “style”):

[thobu]

nice
my goal is to check ~ once per min

1. If a window is open / closed. If closed stick with a certain temperature. If open switch off the thermostat
2. One should be able to change the target temp directly on the thermostat, for a certain period of time, afterwards it should turn back to a certain default temperature.

[DirkG]

Of course, it depends on which smart devices you use, but to check the state of different devices every minute is imo wrong.

1. Check the state of the window itself (with zone activity or the window sensor):
   

   

2. Check changes in the target temperature:
   

   

Of course, you can still add necessary condition cards (presence, times,…) and action cards. I just want to show the principles.

[Peter_Kawa]

@DirkG

Second test with 90 s delay (because you said that there will be a timeout after 89 s)

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.

@Peter_Kawa

running flows get timed out after 89 s.
As one might expect, that is not the case when you use the in-house delay card.

[thobu]

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?

[DirkG]

Sorry @Peter_Kawa, I had overlooked that or misunderstood it.

@thobu

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

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.

@thobu

Do you think frequent checks hava a negative impact on Homey?

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.

[thobu]

@DirkG

This should also not be a problem at all. Just add a “The contact alarm is on” or “This zone is active” card.

I see but these cards are no When cards, would and AND card like this work?

[DirkG]

No, condition cards like The contact alarm is on can’t be used as trigger, of course not. This zone became active however, is a trigger card.

You said:

@thobu

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

What is the trigger? The changing (on/off/temperature) of the thermostat, while the window is open:

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”?