Unclear how to add trigger in conditions, not only as trigger

[wvuyk]

I am trying to get the trigger of my plugin to show in the conditions. Whatever I try, it will not work. I have set CanBeCondition to true:

 Public Overrides ReadOnly Property CanBeCondition As Boolean
        Get
            Return True
        End Get
End Property

This does not show the JowiHue trigger in the list of conditions. It does show in the list for triggers,

I am having doubts if I need the IsTriggerTrue as well. The documentation contradicts itself. In the description it says:

IsTriggerTrue(Boolean) Called by HomeSeer to determine if this trigger's conditions have been met.

English is not my first language, but I think this should be explained like "The plugin can now check if the triggertypes conditions are true and condition can fire.

But in the remarks of the documentation it says:

Remarks Always return TRUE if the trigger cannot be a condition and there is nothing to check when an event is manually executed by a user.

Am I now to understand I cannot use this to check on condition met or not?

In that case I was hoping that this might be the way to get the plugin's trigger in the condition list. But it does not matter what I return here, true or false, the trigger won't show in the conditions list.

What do I need to do to get my plugin's trigger in the selection list for conditions. And how should I explain this IsTriggerTrue's function? Do I even need it if it does not seem to do anything?

Wim

[dcorsus]

Hi Wim, I have a very similar question, I wrote a posting on the forum a while back (https://forums.homeseer.com/forum/developer-support/hs4-development-private/1329851-suggestion-for-device-conditions?p=1331444#post1331444) but I didn't get any reaction and I moved on but recently I picked this back up. My issue is that I want only triggers to show when an event is created and a trigger is selected and ONLY have conditions show when a condition is added. I also tried to play with CanBeConditions but it doesn't seem to do what I want.

@rjhdakota @jldubz

This is what I described on the forum, any help highly appreciated As far as I can tell, I can create an AbstractTriggerType and override the "CanBeCondition" and set it to true and now this object can be used as Trigger AND Condition. Is there an option to ONLY use it as a condition?

I have triggers such as: track changed, status changed .... and conditions such as isPlaying, hasTrack,

I tried to create two instances of AbstractTriggerType, one built around my triggers and the other around my conditions. The conditions now nicely show up when you select some condition BUT they still show when you are setting the initial trigger.

I had some users ask me in HS3 to fix this, and I think they suggested some trick. Is there a proper way to do this in HS4?

Thanks,

Dirk

[wvuyk]

Dirk,

It seems to me the CanBeCondition is working for you, I wonder then why it is not working for me? Whatever I seem to try the trigger is not shown as a condition. In HS3 this is working correctly, in HS4 it is sort of a guessing game.... Just hoping for a guidance here......

[dcorsus]

Well ...... A number of months ago I posted how I could have triggers only show triggers and as far as I recall, actually conditions showed properly. However, right now, I can't make the latter work at all. When I set CanBeCondition to false on my triggers, I actually see both triggers and conditions presented when I create an event and I select my trigger. When I add a condition, actually only triggers show and no conditions what so ever. Suspect something changed to the worse and I posted here to get some guidance as well. I'll post if I can influence the behavior but ironically enough, triggers show as conditions for me, but no condition is showing right now (as a condition) .....

[dcorsus]

Wim, I managed to get back to were I was a while back. Follow me here:

At init I have the following code ActionTypes.AddActionType(GetType(SonosActions)) TriggerTypes.AddTriggerType(GetType(SonosTriggers)) TriggerTypes.AddTriggerType(GetType(SonosConditions))

I hope this is straight forward as SonosAction is a class for action, SonosTriggers ONLY have triggers (with CanBeConditions = false) and SonosConditions ONLY have conditions with CanBeConditions = true.

If I select I trigger, I get presented with both options of triggers and conditions. This is what I would like to see fixed!

However, if I select a condition option, I get presented with TRIGGERS (!!) and not my conditions despite setting the CanBeCondition flag (urgghhh).

Somehow I had this idea to swap the following 2 statement from: TriggerTypes.AddTriggerType(GetType(SonosTriggers)) TriggerTypes.AddTriggerType(GetType(SonosConditions))

to TriggerTypes.AddTriggerType(GetType(SonosConditions)) TriggerTypes.AddTriggerType(GetType(SonosTriggers))

and boom, conditions now properly shows as conditions as opposed to triggers!

If you create multiple classes like I do, you may want to experiment swapping the sequence of calling AddTriggerType. Perhaps what we should have had is a AddConditionType!

[wvuyk]

Dirk,

Thanks for the insights! I am sure there is something funny going on. I am using only one triggertype class, where I am expecting both condition and trigger. I am using this in initialization, very familiar to your situation, except that I do not have separated the conditions:

ActionTypes.AddActionType(GetType(JowiHueActions)) TriggerTypes.AddTriggerType(GetType(AnyOnOffTrigger))

For trying I swapped the actions and trigger, but as expected this does not influence it. So by the looks of this it seems the pluginsdk is just assuming that the first registered triggertype is a trigger only that cannot be included as condition and the second one can have triggers and conditions? Sounds like a initialization issue to me? Should I now double my trigger class to get what I need?

@rjhdakota and @jldubz Can we please have some attention here to actually offer a solution?

[spudwebb]

There is a bug in SDK 1.0.8, TriggerCanBeCondition uses a 1-based index as if it was a 0-based index. It's likely to be the cause of your problem, It's fixed in SDK 1.0.8.1 available on Nuget

[spudwebb]

commit 1b9d77ee43cc5dabd48f515c9730ef8569ecc316

[wvuyk]

Spud,

Checked here and indeed, without modification the trigger is shown as condition as well now. Also existing events are now showing the conditional triggers as well. Thanks! I guess if @dcorsus confirms this as well, this can be closed

Now hoping to get the subaction's subtan number to work too.........

[dcorsus]

Thanks Spud! Wim, most likely I can only try tomorrow pm. I suspect I'll still have to figure out how to ONLY have my triggers show when an event is created and a trigger is being configured or do we think that setting CanBeCondition, when set to true, will NOT show conditions when a trigger is being configured?

I know some developers used some trick in HS3, perhaps use of subindex or something to present only triggers when needed and only conditions when needed. Wim or Spudd, how did you guys implement this?

To clarify, I have Sonos triggers like, "track change", "starts playing" ... , things that are really state changes or events that happen, hence they are triggers. In my mind they cannot be used as conditions, which are "isPlaying", "isStopped" ... which are static states and therefore I use them as conditions. In HS3 I believe both showed up as trigger selections and it confused users and they asked to improve on it. .... so that's what I'm trying to do with HS4, just haven't been able to do so yet.

Thoughts while I confirm the CanBeCondition flag now works but before we close this because not clear I achieved what I had set out for?

Spudd, any idea why changing the sequence of adding triggers made a difference in what shows up as a condition?

[dcorsus]

I just looked at the code changes, I guess my question on why the sequence of adding triggers matters is solved by this fix.

[spudwebb]

If I understand correctly, what you want is the possibility to add a "condition only" (which does not appear as a trigger). I have never found a good way to do this in HS3: in EasyTrigger for example I just display a warning message instead of the trigger name when a user tries to use a "condition only" as a trigger.

                    switch (subTriggerNumber)
                    {
                        case SUBTRIGGER_PLUGIN_RUNNING:
                            if (m_conditionFlagset)
                                return "This plugin IS running:";
                            else
                                return "Not available as a trigger (IF / OR IF) only as a condition (AND IF)";

I will log a feature request for this in HS4

[dcorsus]

I see, that would indeed be a solution. I might go hunt for the email or posting, where someone recommended a way they had done it, but very likely irrelevant to HS4. Having the option to specify that it is a trigger ONLY, or a condition ONLY or both could help the user friendliness. Moreover, in HS4, the HS team upon suggestion of (can't remember) made a change. When you create an event, the first thing you add is a trigger, then depending of whether you do an ORIF instead of ANDIF, the UI shows that you are adding a trigger in the case of ORIF and a condition in the case of ANDIF. Wouldn't it be proper that the right selections would show :-)

[rjhelmke]

I have not been following this closely so there may be a good reason for this, but I would think it would be easier to use devices for things like track changes and such. Then the user can use the HS built in triggers and conditions and simplify your work. Is there a reason you cannot use devices?

[dcorsus]

I could use devices, good point, but I already have 20 or so, and people asked me for even more conditions. To use devices to do changes, some triggers get pretty involved for example, it allows a user to trigger on when a track changes and they can navigate artist->album->track to define the track or whatever item they want to trigger on. Bit hard(er) to do that with just (more) devices. In all fairness, I would think you guys created triggers and conditions for a purpose ....

[dcorsus]

I can confirm that the fix now have conditions show for triggers and conditions and no triggers when conditions are selected. I guess that's how it should have worked except my ask was slightly different. Spudd thanks for the fix. Wim thanks for reporting this.

[jldubz]

@dcorsus thank you for verifying this fix in v1.0.8.1.

Closing this issue.