Repeat a certain check

[rge]

Nice, it seems a shame they removed it in HS4.

(In HS4) I thought maybe I could put in a step at the end to run the event again after a delay, but you can't - "run another event" actually is "run a different event", you can't run the same one again although you can run a second event which then runs the first...

Script commands don't help either because TriggerEvent doesn't have an option to check the conditions (which is a huge gap IMO).

So even though events support these delayed actions and waits and the ability to call other events, looks like in HS4 a timer or at least two events is required, which sucks which you've just shown me a neat solution.

[jmaddox]

You can still do this in 1 event

A recurring trigger happens (set this to 5 min)
and if window open
and if virtual switch on
then announcement

[rge]

You can still do this in 1 event

A recurring trigger happens (set this to 5 min)
and if window open
and if virtual switch on
then announcement

Yes I do that sort of thing for scripts that do a bunch of complex checks and then an action (like mow if it's in time range X but not if it rained in the last four hours or we mowed in the last 18 hours, but then do it at some point later if it's not raining, finally if it's been a few days do it even if raining etc, oh and also check if the mower is on its base, and maybe we need to edge mow).

But your example doesn't work as required - it will announce somewhere between zero and five minutes after the conditions are true, not straight away. This will work better:

A recurring trigger happens (set this to 1 min)
and if window open
and if virtual switch on
then announcement
event cannot repeat for 5 minutes

I still hate this model - events should be triggered by actions, not polling, it always becomes a compromise between responsiveness and useless processing, but it's better than nothing.

Also it made me think about the "at least condition" for delayed triggering - they removed "has been for at least" in HS4 to avoid runaway triggering, but if it's not the main condition then that's not a problem.

And bingo - you can still use "has been for at least" in an AND clause, so we can do this if we want the first announcement after five(ish) minutes:

A recurring trigger happens (set this to 1 min)
and if window open
and if virtual switch has been on for at least 5 minutes
then announcement
event cannot repeat for 5 minutes

[Uncle Michael]

This will work better:

A recurring trigger happens (set this to 1 min)
and if window open
and if virtual switch on
then announcement
event cannot repeat for 5 minutes

I still hate this model - events should be triggered by actions, not polling, it always becomes a compromise between responsiveness and useless processing, but it's better than nothing.

Also it made me think about the "at least condition" for delayed triggering - they removed "has been for at least" in HS4 to avoid runaway triggering, but if it's not the main condition then that's not a problem.

And bingo - you can still use "has been for at least" in an AND clause, so we can do this if we want the first announcement after five(ish) minutes:

A recurring trigger happens (set this to 1 min)
and if window open
and if virtual switch has been on for at least 5 minutes
then announcement
event cannot repeat for 5 minutes

Keep in mind that <has been for at least> is not an action. It's a condition. That's why it cannot act as a trigger.

I'm not sure what you mean by "useless processing", but the <has been for at least> "trigger" in HS3 is, in practice, a combination of the <has been for at least> condition and a hidden recurring trigger that was basically free running. That's why it could lead to runaways.

Also, a recurring trigger with unsatisfied conditions does not appear to consume measurable resources. I suspect the event engine is quite efficient at combining conditions and triggers to minimize overhead. Aside from OCD considerations, it's probably not an issue.

That said, you could make the event even more responsive by shortening the recurring trigger even further. (Making it 1 second would pretty closely replicate the performance of the HS3 "trigger".)

[mterry63]

I agree, checking "if time is X" is likely no more effort for the event engine than checking "if device is X". Time is just a hidden device.

[rge]

Keep in mind that <has been for at least> is not an action. It's a condition. That's why it cannot act as a trigger.

I'm not sure what you mean by "useless processing", but the <has been for at least> "trigger" in HS3 is, in practice, a combination of the <has been for at least> condition and a hidden recurring trigger that was basically free running. That's why it could lead to runaways.

Also, a recurring trigger with unsatisfied conditions does not appear to consume measurable resources. I suspect the event engine is quite efficient at combining conditions and triggers to minimize overhead. Aside from OCD considerations, it's probably not an issue.

That said, you could make the event even more responsive by shortening the recurring trigger even further. (Making it 1 second would pretty closely replicate the performance of the HS3 "trigger".)

True, it just isn't aesthetically / architecturally pleasing, maybe that is a bit OCD!

It would also really help if they added "trigger every X minutes starting at Y minutes in the hour".

At the moment the option is to run at the top of the hour, so everything runs at the same time, or not specifying the start time which in practice means the same after the first restart.

It isn't just because of the controller but also the Z-Wave network, which isn't so happy if a lot of devices are changed at the same time. And logging/monitoring is much easier if everything doesn't happen at the same time.

[Uncle Michael]

It would also really help if they added "trigger every X minutes starting at Y minutes in the hour".

At the moment the option is to run at the top of the hour, so everything runs at the same time, or not specifying the start time which in practice means the same after the first restart.

I was under the impression the timing was more random than that, and I haven't seen any obvious behavior quirks that might accompany that sort of coordination. How did you determine that they are all synchronous?