Feedback Request: Conditional Actions

[drhtmal]

Be patient. A change like this can take hours to code.

Don't forget the testing phase. Testing consumes a significant amount of time. I hope HomeSeer spends more than a few hours on this seemingly simple change. Heaven forbid HomeSeer rush this change in and risk causing thousands and thousands of HomeSeer users with potentially hundreds of thousands of events to end up with corrupt events that don't work.

Give Rich and the boys a break and have patience as they implement this *simple* feature that can affect thousands of people.

[HSAccord]

Don't forget the testing phase. Testing consumes a significant amount of time. I hope HomeSeer spends more than a few hours on this seemingly simple change. Heaven forbid HomeSeer rush this change in and risk causing thousands and thousands of HomeSeer users with potentially hundreds of thousands of events to end up with corrupt events that don't work.

Give Rich and the boys a break and have patience as they implement this *simple* feature that can affect thousands of people.

Pretty sure upstatemike was being facetious.

[Bradkw]

changing from IF to WHEN is ridiculous and potentially exposes some disappointing truths about the masters of the universe.

Thank you! But then let’s take it a bit further… maybe we should change from “If” to “Once upon a time”.

But seriously I do not understand the need to change the first “If” to “When” just to differentiate the “master trigger”. The “When” idea was discussed just after the idea of putting the action before the condition. Thankfully changing the order didn’t stick but the “When” idea did. The master condition is just the first “If”. Is it really that hard to keep track of? If so, just maybe “Once upon a time” has some merit.

[upstatemike]

Maybe we should just get rid of the trigger entirely so you don't have to worry about "the first if". In my Stargate all conditions in an event are evaluated many times per second and once all conditions are true then the event fires. There is no need to assign one of the conditions as the trigger. This makes the logic very intuitive and cuts down on coding since you don't need separate events for each possible combination of trigger plus conditions. Also it eliminates the risk of missed triggers because the conditions will get evaluated again within a few hundred milliseconds and and the system will self correct.

[claude]

... In my Stargate all conditions in an event are evaluated many times per second and once all conditions are true then the event fires...

Doesn't that chew up cycles ?

[randy]

Doesn't that chew up cycles ?

It can. Essentially that is the way earlier versions of HS worked, In HS3 or HS4 a 1s recurring trigger will do the same thing. It won't eat cycles if the Event is properly designed such that a device controlled by the Event is also used as a Condition.

[upstatemike]

Doesn't that chew up cycles ?

Not sure why I need to care about that? Modern hardware is many magnitudes faster than what the Stargate has. It should be able to handle every IoT device you can throw at it without breaking a sweat.

[scorp508]

I only read page 1 of 13 pages, so my question's answer may be buried in pages 2-12 somewhere.

Would the multiple condition/action groups within a single event be processed serially or in parallel? If serially, is there going to be a method that allows "Cancel processing remaining conditions" within the event if you have a particular condition whose logic renders the rest irrelevant?

Similar to these...

[ksum]

scorp508 take a look at Post 94 in this thread and a few other posts following such on that page.

[randy]

11

I only read page 1 of 13 pages, so my question's answer may be buried in pages 2-12 somewhere.

Would the multiple condition/action groups within a single event be processed serially or in parallel? If serially, is there going to be a method that allows "Cancel processing remaining conditions" within the event if you have a particular condition whose logic renders the rest irrelevant?

Similar to these...

Those will only work on Delayed Device Actions, Delayed Events or when an Event is in a Wait state. Cancelling a running Event has to be in Wait. Currently there is no way to cancel standard Actions or to stop a running Event.

[scorp508]

scorp508 take a look at Post 94 in this thread and a few other posts following such on that page.

Thank you for the pointer. Yes, a break/end is exactly what I was looking for, so it is nice to see it already came up in discussion. It looks like serial is the other answer to my question.

[macromark]

So... got my hands on a test version earlier this week and the bulk of the coding and UI work is done. It looks goods and (so far) functions as expected. This feature will be included in version 4.2.18. We do have an in-between release (4.2.17*) dropping on Feb 7th and that will need to be released before we can do a beta build of 4.2.18. Anyway, I'll post a screen shot next week when the UI is finalized... still a couple tweaks needed.

*4.2.17 includes PSDK changes. If you're a plugin developer, you should have already received an email alert about that. If you didn't check the blog article here: https://homeseer.com/plugin-alert/

[macromark]

As promised, a screenshot of the working feature:



This particular event is fairly simple and just changes the status of a virtual device to match the moon phase every day at midnight. I currently use 8 separate events to do the same thing as this one event. The "End This Event" action is technically not needed in the event but is included in the screen shot so you can see it!

[upstatemike]

I like this. Easy to read and understand.

[TC1]

This particular event is fairly simple and just changes the status of a virtual device to match the moon phase every day at midnight. I currently use 8 separate events to do the same thing as this one event. The "End This Event" action is technically not needed in the event but is included in the screen shot so you can see it!

IMO, that's going to be a HUGE win for folks like myself that can now consolidate multiple events and called events into one easy to understand flow.
As long as the Then actions within a single event can be configured to run synchronously if needed, then all should be good!