Triggers and Conditions

[sooty]

I've worked with triggers in my plug-ins but never (until today) had cause to use HasConditions making a trigger selectable as a condition.

I added a new trigger (2) and for that trigger number set HasConditions to true and in BuildTriggerUI I've formatted my drop down selections accordingly by trigger number.
This works as expected and trigger(2) shows when adding a second item to an event (AND IF) and trigger(1) does not show.

Due to the nature of the conditions, they are not ideally suited to being used as initial triggers however I can't see a way to prevent trigger(2) from displaying in the IF dropdown (1st item in an event).

The only plug-in that I have on my live system that supports triggers being a condition is Sonos which exhibits this same behaviour in that a condition can be selected as the 1st item in an event. (See attached screenshot).

I suppose this event would work OK but not ideal if HS3 has to constantly evaluate if the Hallway Sonos device Is Playing in order to fire the event.

Just wondered if there is a way to make a trigger "condition only" and I'm just being thick an not able to see it.

Paul..

[randy]

I've worked with triggers in my plug-ins but never (until today) had cause to use HasConditions making a trigger selectable as a condition.

I added a new trigger (2) and for that trigger number set HasConditions to true and in BuildTriggerUI I've formatted my drop down selections accordingly by trigger number.
This works as expected and trigger(2) shows when adding a second item to an event (AND IF) and trigger(1) does not show.

Due to the nature of the conditions, they are not ideally suited to being used as initial triggers however I can't see a way to prevent trigger(2) from displaying in the IF dropdown (1st item in an event).

The only plug-in that I have on my live system that supports triggers being a condition is Sonos which exhibits this same behaviour in that a condition can be selected as the 1st item in an event. (See attached screenshot).

I suppose this event would work OK but not ideal if HS3 has to constantly evaluate if the Hallway Sonos device Is Playing in order to fire the event.

Just wondered if there is a way to make a trigger "condition only" and I'm just being thick an not able to see it.

Paul..

Is there a chance while you were testing this event that you might have deleted the original Trigger, causing the Condition to move up to the trigger position? This is a widely reported bug in the event management. The Sonos Triggers are



And the Conditions are



Somehow you have a Condition as a Trigger.

[sooty]

Randy,

I've spent far too long today pi**ing about with triggers and conditions. I reckon I've aged 5 years just this afternoon.

This thread that you linked in your email seems to suggest using sub triggers is the way to go so tomorrow I'll have a look at that route.

Paul..

[dcorsus]

Randy,

I've spent far too long today pi**ing about with triggers and conditions. I reckon I've aged 5 years just this afternoon.

This thread that you linked in your email seems to suggest using sub triggers is the way to go so tomorrow I'll have a look at that route.

Paul..

Hi Paul and Randy, let me chime in ...

The Sonos event you show, I'm sure isn't doing anything. It all starts with the PI author who decides which state-transitions could be important for users to kick off HS3 event actions. I decided that things like changing player state, volume state, on-line state etc. were important enough events to "trigger" something. Trigger is an active event for your PI in that you coded it up because you inform HS3 about this event and start querying the event DB for a matching trigger. Conditions are passive to a PI, it is just a query by HS3 to be used in addition to an already active trigger to confirm whether the event should run or not.

The event that is shown above, the reason it doesn't do anything is because my PI doesn't do periodic checks whether it is playing, then check HS3 whether someone had created an event and then do something. This would be a huge processing burden, triggers are for state-changes, conditions are to be attached to a check when a trigger happened in the first place.

Clear as mud?

Dirk

[randy]

Dirk;

I surmised, in exchanging messages with Paul, that the reason you chose to offer separate Sonos Triggers vs Sonos Conditions is for the reason you state. You are expecting users to realize a Sonos Condition will not work as a Trigger, despite the fact that they can choose one.

What Paul, Spud and others are trying to figure out is how a Trigger can be exclusive to Triggers and a Condition be exclusive to Conditions. The example Spud gave of the Condition "The Moon Phase is..." is an example of a Condition that is not available as a trigger. Unfortunately, it is not clear how this can be done for a plug-in based Condition where there is not an associated device. For your plug-in it would be great to only be able to choose Sonos Triggers from the Trigger dropdown and only Sonos Conditions from the Conditions drop down.

On Spud's Easy Trigger plug-in he is able to only offer Triggers in the Trigger section, with one exception "A Plugin is...". This one Condition is not shared with an equivalent Trigger "A Plugin became...", but he found it had to be listed under Triggers but with no choices available.

What Paul is trying to do is create a Trigger based on a state-transition where a user has entered or left a location and a complimentary Condition where a user is at or not at a location. While a user is represented by a HomeSeer Device, the location will not have one.

More mud?

[sooty]

Hi Paul and Randy, let me chime in ...

The Sonos event you show, I'm sure isn't doing anything. It all starts with the PI author who decides which state-transitions could be important for users to kick off HS3 event actions. I decided that things like changing player state, volume state, on-line state etc. were important enough events to "trigger" something. Trigger is an active event for your PI in that you coded it up because you inform HS3 about this event and start querying the event DB for a matching trigger. Conditions are passive to a PI, it is just a query by HS3 to be used in addition to an already active trigger to confirm whether the event should run or not.

The event that is shown above, the reason it doesn't do anything is because my PI doesn't do periodic checks whether it is playing, then check HS3 whether someone had created an event and then do something. This would be a huge processing burden, triggers are for state-changes, conditions are to be attached to a check when a trigger happened in the first place.

Clear as mud?

Dirk

Thanks for the input Dirk,

I understand the difference between a trigger and a condition. I used your plug-in as an example because it is the only one I have that supports conditions.

In a similar way to your Sonos PI, I have state change events within my PI (perhaps like Player starts playing in Sonos) that are presented to the user as triggers when they are working with a trigger (IF / OR IF) event line. These are "triggers" therefore are not presented to the user when they are working with a condition (AND IF) event line.

I also have some "conditions" that are (perhaps like Is Playing in Sonos) that cannot be used in a trigger (IF / OR IF) event line because (as you mention) there is nothing in my PI constantly monitoring the state of each item that can be a condition and evaluating any HS events that may contain that condition.

My issue is with the GUI. In the case of the Sonos PI, when constructing a trigger (IF / OR IF) event line it presents the user with both "Sonos Triggers" and "Sonos Conditions" when I suspect it should only present the "Sonos Triggers". When working with a condition (AND IF) event line it shows only "Sonos Conditions" which I expect is correct.

To reduce confusion and / or support requests, inn my plug-in I only want to present the user with "Triggers" when they have selected (IF/ OR IF) and "Conditions" when they have selected (AND IF) in the same way that the standard HS3 Moon Phase "Condition" works.

I need to do more testing tomorrow but I think I have come up with a solution now.

Thanks again

Paul..

[dcorsus]

My issue is with the GUI. In the case of the Sonos PI, when constructing a trigger (IF / OR IF) event line it presents the user with both "Sonos Triggers" and "Sonos Conditions" when I suspect it should only present the "Sonos Triggers". When working with a condition (AND IF) event line it shows only "Sonos Conditions" which I expect is correct.

... I see, sorry for misunderstanding. I coded it so many moons ago and I suspect I added the "trigger" and "condition" suffix to it to clarify what was what, including the "isXXXX" to indicate a condition.

[sooty]

... I see, sorry for misunderstanding. I coded it so many moons ago and I suspect I added the "trigger" and "condition" suffix to it to clarify what was what, including the "isXXXX" to indicate a condition.

Not sure if you want to change the Sonos plug-in so that it doesn't show the conditions when the user is working with a trigger but it is possible to achieve as I have found through trial and error.

The [Condition] property is set True if the user is working with a condition (AND IF) and False if they are working with a trigger (IF / OR IF).
Use this to set a flag which you can then use in [TriggerBuildUI] to populate your dropdowns etc with whatever is appropriate.

Paul..

[randy]

And it works well. Only the correct choices for Triggers and Conditions are offered.