Hello, yes you're correct in your understanding of the limit (although it was recently increased from 3 to 6).  This was originally implemented to prevent spam, but I could look at changing this to be a limit per sequence per hour for example so that it would be less likely to impact your particular scenario.

How many times do you think it would need to retry before the whole process was kicked off again by IFTTT?  Perhaps you can have a longer sequence with multiple checks and pauses so you're not relying on one sequence triggering another.  For example:

• Sequence A which is triggered by IFTTT
• This checks the temperature then pauses if condition not met
• Build out the sequence to do this check multiple times
• Duplicate Sequence A so you have a second one with the same number of steps
• At the end of A have it trigger B

I know this is a bit cumbersome to set up, but should enable you to get a higher number of checks.

In the meantime I can also look at modifying the limit on the number of sequences which can be called.

Hi Derek, thank you!

How many times do you think it would need to retry before the whole process was kicked off again by IFTTT? 

It will be at most once per hour, because the AC run time is at least 90 minutes (thermostat set to low), and the pause (thermostat set to high to reduce AC run) is as short as 20 minutes (longer if outdoor temp is cooler).

The increased limit of 6 is definitely much better for my scenario. I will follow your suggestion about a longer sequence. 

Hello Derek, another question, is the sequence counting based on depth, or just any sequence being called by the main thread?

A -> B -> C -> D counts as 3 sequence calls

what about:

A -> B
A -> C
A -> B
A -> D

In the second case, B, C and D are convenience functions to make A more readable.

Thanks

So I got the sequence log from half of the day so far, and it's working beautifully! Turns out I didn't have to expand sequence A at all.

A -> B -> C counts as 2 sequences
A -> B -> A actually starts A in its own thread, stopping the first A.

Sequence log details

[AC] 1. Start when Temperature Rises was triggered on Tue 4 May at 10:47:06.

Triggered by the IFTTT webhook ecobee_ifttt_start
The value of the variable temperature_high_today was 86 (not below 79 - condition failed) 
Triggered the sequence Send 'get_temperature' to IFFFT (sub-sequences: 1)
The value of the variable temperature was 73 (not below 73 - condition failed) 
Triggered the sequence Send 'ecobe_ift_active' to IFTTT (sub-sequences: 1)
Triggered the sequence Set Run Time (while AC is on) (sub-sequences: 2)
Paused for 1 hour
Triggered the sequence Send 'ecobee_ift_standby' to IFTTT (sub-sequences: 1)
Triggered the sequence Set Rest Time (while AC is off) (sub-sequences: 2)
Paused for 45 minutes
Triggered the sequence Send 'get_temperature' to IFFFT (sub-sequences: 1)
The value of the variable temperature was 81 (above 72 - condition passed)
Triggered the sequence [AC] 2. Repeat Start-Sequence if Temperature is Still High (sub-sequences: 2)

"[AC] 2" sequence calls the second "[AC] 1" just before ending this "[AC] 1". The second "[AC] 1" started its own, separate run.

In the first run above, the thermostat was set to low for 1 hour (the first pause, effectively turning the AC ON), then it was set to a higher temp for 45 minutes (effectively turning the AC OFF, which could still go on should the room sensors reaches the higher temp setting).

It repeats the cycle adjusting the 'active' and the 'standby' time depending on outdoor temperature. The house gets a little warmer during the standby time but still comfortable (and saving energy). The cycling keeps the house from getting too warm which would be uncomfortable and harder to cool down again.

This is a much better way for controlling the AC then the Ecobee 'dumb' thermostat schedule!

Excellent!  Glad you managed to get it working.