Announcement

Collapse
No announcement yet.

I struggle to understand how to use Triggers in HS4

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • alexbk66
    replied
    Please read docs https://homeseer.github.io/Plugin-SD...iggerType.html

    Also there's a sample plugin https://github.com/HomeSeer/Sample-Plugin-CS

    TriggerTrue() is "Called by HomeSeer when a trigger needs to be evaluated as a condition" - meaning that this is only called when there's some "main" trigger setup, then HS checks this trigger is used as condition (i.e. AND) and if its condition is met. But "bool isCondition" argument is confusing because my understanding is that it's only called for condition anyway.

    Leave a comment:


  • hembhagat
    replied
    alexbk66 Can you guide me on how to fire a trigger from the plugin? Because I am really confused with this.

    My requirement is, I have implemented the IsTriggerTrue method to check whether the Trigger should be fired. Now I want it to just fire when the condition is true. What do I need to do in the plugin to achieve this? I don't want any user interaction for firing the trigger. That is no Button/UI Control to fire the trigger. Whenever the IsTriggerTrue returns true I need the trigger to be fired.

    Leave a comment:


  • alexbk66
    replied
    Originally posted by hembhagat View Post
    Do I need to fire it manually from my plugin code?
    Yes, call hs.TriggerFire()

    Click image for larger version

Name:	Screenshot 2022-12-01 010357.png
Views:	81
Size:	24.8 KB
ID:	1577981

    Leave a comment:


  • hembhagat
    replied
    I implemented the AbstractTrigger class and also implemented the method IsTriggerTrue method. I am able to configure the trigger from the Events page. But the trigger is not fired. Do I need to fire it manually from my plugin code?

    Leave a comment:


  • rmasonjr
    replied
    Originally posted by Bernold View Post
    alexbk66: That issue on GitHub is closed, but it ends with you going to check. I wonder if the issue needs to be reopened. I'm relatively new to triggers, so I'm not sure it's just me. What I do know is that I avoided IsFullyConfigured(). I believe I used GetPrettyString() instead as a workaround, to lower the amount of calls. Which is madness. If anyone can confirm, the issue should just be reopened for better performance.

    Here is what I see when I add Console.WriteLine(DateTime.Now) to IsFullyConfigured() in the Sample Plugin CS as a test:
    - Create an event and pick Sample Trigger as a trigger: called 3 times within the same second
    - Pick any of its 4 subtriggers: 3 calls
    - Save the trigger: 4 calls(!)
    - Opening the Events page: 1 call(?)
    - Reopening the specific event: 3 calls
    Definitely go look at the github issues. The 'dips' into each plugin's actions/triggers is really more than I would have expected.

    Leave a comment:


  • Bernold
    replied
    Originally posted by alexbk66 View Post

    I don't think I tested - if it takes more than a year...
    Thanks for your reply. That makes sense. Think I'll give it another try though.

    Leave a comment:


  • alexbk66
    replied
    Originally posted by Bernold View Post
    alexbk66: That issue on GitHub is closed, but it ends with you going to check. I wonder if the issue needs to be reopened.
    I don't think I tested - if it takes more than a year...

    Leave a comment:


  • Bernold
    replied
    alexbk66: That issue on GitHub is closed, but it ends with you going to check. I wonder if the issue needs to be reopened. I'm relatively new to triggers, so I'm not sure it's just me. What I do know is that I avoided IsFullyConfigured(). I believe I used GetPrettyString() instead as a workaround, to lower the amount of calls. Which is madness. If anyone can confirm, the issue should just be reopened for better performance.

    Here is what I see when I add Console.WriteLine(DateTime.Now) to IsFullyConfigured() in the Sample Plugin CS as a test:
    - Create an event and pick Sample Trigger as a trigger: called 3 times within the same second
    - Pick any of its 4 subtriggers: 3 calls
    - Save the trigger: 4 calls(!)
    - Opening the Events page: 1 call(?)
    - Reopening the specific event: 3 calls

    Leave a comment:


  • alexbk66
    replied
    Originally posted by mrslother View Post
    Thanks, Alexbk66. That makes sense. The sheer volume of calls to the constructors concerns me if I am to perform some heavy weight processing. At one point I sat down and walked through various constructor calls for a simple creation of an HS Event via the web UI. It was something like 12 various constructor calls.
    This will (should) be fixed in 4.2.11.0 https://github.com/HomeSeer/Plugin-SDK/issues/132

    Leave a comment:


  • mrslother
    replied
    Thanks, Alexbk66. That makes sense. The sheer volume of calls to the constructors concerns me if I am to perform some heavy weight processing. At one point I sat down and walked through various constructor calls for a simple creation of an HS Event via the web UI. It was something like 12 various constructor calls.

    What I was hoping to find was some HsEvent() being fired when a user modifies an existing Event's action and/or trigger settings. I see events fired when someone changes the actual trigger (eg change manual trigger to a Sonos4 trigger). But just modification of existing trigger configs do not fire an event.

    The way I solved it was by checking the return value of my AbstracTriggerType's OnConfigItemUpdate(). If it is true then firing a generic event that my trigger listener monitors which then performs the heavy weighted processing. Since the true value has not yet been returned (therefore the new TrigActInfo not yet persisted) I queue it on the task threadpool and delay it by some short amount of time before firing the event.

    Ideally HsEvent() would receive a callback event Constants.HSEvent.CONFIG_CHANGE for any changes to an existing trigger or action. That would be much more reliable.

    Thanks for your help.

    Leave a comment:


  • alexbk66
    replied
    What do you mean by "How do I detect changes to Event Triggers and Event Actions"?

    I don't think HS provides any trigger if user changes trigger settings (if that's what you mean).

    When I need to check for changes, I overwrite all AbstractTrigger constructors:

    Click image for larger version

Name:	Screenshot 2022-03-22 152031.png
Views:	324
Size:	57.6 KB
ID:	1533028

    Leave a comment:


  • mrslother
    replied
    Thank you guys for this thread. Reading the docs and source is crazy making.

    Question: How do I detect changes to Event Triggers and Event Actions?
    My plugin needs to respond to changes in event changes (specifically trigger settings) (new ones, removing existing ones, changes to existing ones). I need to react to such changes by processing the changed TrigActInfo objects.

    I have tried reacting in my TriggerType class but the only place where it makes sense (I think) is GetPrettyString() because that is called once the new TrigActInfo object is created and persisted to my plugin's TriggerTypes collection. This seems really lame and profoundly bad. There has to be a better way.

    I have also tried using HsEvent (I registered for all events) but do not see any related to event trigger/action changes.

    What am I missing?

    Leave a comment:


  • alexbk66
    replied
    Originally posted by stefxx View Post
    HI. I have my triggers working now, but being able to trigger an event in the HSPI class, outside of the class is something I still don't quite understand and might come-in handy one day. I wouldn't mind an example on how you've accomplished that. Just as a learning experience for myself!
    It's actually handy to read docs (comments):

    /// <summary>
    /// The base implementation of a trigger type interface that facilitates communication between
    /// <see cref="AbstractTriggerType"/>s and the <see cref="AbstractPlugin"/> that owns them.
    /// <para>
    /// Extend this interface and have your <see cref="AbstractPlugin"/> implementation inherit it to make it
    /// accessible through the <see cref="AbstractTriggerType.TriggerListener"/> field.
    /// </para>
    /// </summary>
    public interface ITriggerTypeListener {}
    So you do
    Code:
    public interface IMyTriggerTypeListener ITriggerTypeListener
    {
        // Your methods [B]declarations [/B]here
    }
    
    public class HSPI : AbstractPlugin, IMyTriggerTypeListener
    {
       // Your IMyTriggerTypeListener [B]implementations [/B]here
    }
    Then inside your triggers (derived from AbstractTriggerType) you access it via TriggerListener member:

    public abstract class AbstractTriggerType {
    /// <summary>
    /// An interface reference to the plugin that owns this trigger type.
    /// <para>
    /// Define your own interface that inherits from <see cref="TriggerTypeCollection.ITriggerTypeListener"/>
    /// and then cast this as the type you defined to get a reference to your plugin that can handle any methods
    /// you wish to define.
    /// </para>
    /// </summary>
    public TriggerTypeCollection.ITriggerTypeListener TriggerListener { get; internal set; }
    }

    Leave a comment:


  • stefxx
    replied
    HI. I have my triggers working now, but being able to trigger an event in the HSPI class, outside of the class is something I still don't quite understand and might come-in handy one day. I wouldn't mind an example on how you've accomplished that. Just as a learning experience for myself!

    Leave a comment:


  • alexbk66
    replied
    I used it in my some plugins, if you stefxx need - I can dig it out

    Leave a comment:

Working...
X