Excessive Calls to OnNewTrigger/OnInstantiateTrigger for AbstractTriggerType and AbstractTriggerType2

[hem-bhagat-tark]

Environment

HomeSeer

OS

Windows

HS Version

v4.2.21.0

Development

PSDK Version

v1.4.3.0, v1.4.4.0 and v1.5.0.0

Language

C#

IDE

VS2022

Dev OS

Windows

Problem

Excessive Calls to OnNewTrigger/OnInstantiateTrigger for AbstractTriggerType and AbstractTriggerType2

Description

I've observed a strange and potentially problematic behavior with AbstractTriggerType and AbstractTriggerType2. The OnNewTrigger and OnInstantiateTrigger methods are being called an unusually high number of times during plugin initialization and when interacting with the Events page—for example, when configuring or viewing event actions.

To find number of calls at the time of plugin initialization, I logged the number of times OnInstantiateTrigger was invoked and consistently found it being called 844 times, regardless of how many times I restarted. This number appear to correlate with the number of devices + features in my system which is also 844.

For AbstractTriggerType, this excessive invocation only seems to occur when the trigger’s ConfigPage does not include any input elements. Or at least that is what I can deduce because, I had a ConfigPage with only a LabelView and the excessive invocation was consistent. However, as soon as I added an InputView, the excessive invocation stopped. With AbstractTriggerType2, the problem occurs unconditionally, regardless of the content in the config page.

To rule out interference from other parts of my plugin, I created a minimal version that includes only the trigger definitions, and the issue still persists. This behavior is particularly problematic for AbstractTriggerType2 because it requires rendering the entire configuration page with each call to OnInstantiateTrigger, which involves making multiple DB and HomeSeerSystem calls. As a result, the repeated calls introduce significant overhead and make AbstractTriggerType2 difficult to use in practical scenarios.

While I’ve also noticed a similar pattern with AbstractActionType, I haven’t explored it in detail yet, so this report focuses specifically on the triggers. Based on these findings, I believe this is likely a bug and would appreciate it if the team could investigate further.

Screenshots

AbstractTriggerType - With only LabelView

AbstractTriggerType - With an InputView

AbstractTriggerType2

Device Count

Expected Behavior

The methods should not be called soo many times.

Steps to Reproduce

1. Create a fresh plugin with two triggers, one which implements AbstractTriggerType and one which implements AbstractTriggerType2. In the ConfigPage of triggers keep only a LabelView with simple text.
2. Start remote debugging for the plugin, go the Events page and create two events using each of the triggers.
3. Once configured, add debugger or a console log to the AbstractTriggerType's OnNewTrigger method and AbstractTriggerType2's OnInstantiateTrigger method.
4. Restart the remote debugging for the plugin and you will see the debugger will hit continuously or many console logs being printed for both the triggers.
5. Now, deleted the configured events and remove the debugger/console log. Instead of having a simple LabelView in the ConfigPage, add an InputView to the ConfigPage for both of the Triggers.
6. Restart remote debugging for the plugin to reflect the changes, again configure two events as done previously and add debugger/console log as per previous steps.
7. Restart remote debugging again. You will see that the debugger will not hit/console log will not be printed for AbstractTriggerType but for the AbstractTriggerType2 it will same behavior as previous one.

Logs

Not Applicable

[hem-bhagat-tark]

I created a repository containing the plugin code I used for producing this issue. https://github.com/hem-bhagat-tark/TriggerDemoHS4Plugin

[spudwebb]

I believe you see all these calls because when the plugin starts, HS4 is testing for each device and feature if the the trigger references it by calling ReferencesDeviceOrFeature(int devOrFeatRef)

I agree this is not ideal, and at the very least we should have a mechanism so that you can build the ConfigPage only when it is really needed, and not when calling methods such as ReferencesDeviceOrFeature, or IsFullyConfigured. There is a proposed solution for this problem in #342

[hem-bhagat-tark]

@spudwebb Thanks for pointing out a potential solution — I’ll definitely give it a try and update if it works as expected.

In the meantime, I wanted to share an observation I made while reproducing the issue. As you mentioned, the trigger should be calling ReferencesDeviceOrFeature(int devOrFeatRef), and I do see those calls.

However, I noticed something specific related to how AbstractTriggerType behaves depending on the ConfigPage setup. When the page includes an InputView, only the constructor and ReferencesDeviceOrFeature are invoked. But when the page has only a LabelView, the OnNewTrigger method is called before the constructor, followed by the constructor and ReferencesDeviceOrFeature.

On the other hand, with AbstractTriggerType2, the behavior is consistent regardless of the ConfigPage layout. Every time, the OnInstantiateTrigger method is called first, followed by the constructor and then ReferencesDeviceOrFeature.

Also, I confirmed that no other constructors are being called apart from the one with the signature:

protected AbstractTriggerType(int id, int eventRef, int selectedSubTriggerIndex, byte[] dataIn, TriggerTypeCollection.ITriggerTypeListener listener, bool logDebug = false)

This behavior is a bit confusing — especially how OnNewTrigger/OnInstantiateTrigger is being called before the constructor. To investigate further, I implemented all constructors from AbstractTriggerType in my trigger class, but still observed this sequence.

[hem-bhagat-tark]

@spudwebb Based on what I’ve observed from decompiled code of the Plugin SDK in Visual Studio 2022, the behavior in AbstractTriggerType might be explained by the InflateTriggerFromData method. Here's the relevant implementation:

If ProcessData is somehow skipping LabelView elements, the resulting array could be empty. Which would trigger a call to OnNewTrigger. Alternatively, an exception during processing could also lead to OnNewTrigger being invoked. Since InflateTriggerFromData is called in all parameterized constructors, this flow seems plausible.

That said, I’m not entirely sure. Just sharing my perspective here, so please don’t take it otherwise.

Similarly, in the case of AbstractTriggerType2, I believe the observed behavior is driven by the ProcessData method. Here's its implementation:

In this case, ProcessData explicitly calls OnInstantiateTrigger, and since ProcessData might be executed on every trigger instantiation, this explains why OnInstantiateTrigger is always called. It also makes sense in context because, ReferencesDeviceOrFeature may depend on the ConfigPage, andOnInstantiateTrigger ensures the necessary configuration is in place beforehand.

However, as discussed in the issue description, this has obvious drawbacks. One possible improvement could be to change the ReferencesDeviceOrFeature pattern. Instead of checking each device or feature individually, HomeSeer could consider introducing a method like:

protected List<int> DevicesOrFeaturesReferenced()

This would allow HS4 to retrieve all referenced devices/features in one go, once per registered trigger/action, potentially reducing overhead and improving performance.

[spudwebb]

OnNewTrigger is supposed to be called only when a new trigger is being created, not when an existing configured trigger is loaded. So this is a bug. That being said a trigger with only one LabelView does not make any sense as the user can't configure anything in a LabelView. Does OnNewTrigger is also called if your trigger contains a LabelView and an InputView ?

I agree a DevicesOrFeaturesReferenced() method like you suggested would be better.

[hem-bhagat-tark]

Does OnNewTrigger is also called if your trigger contains a LabelView and an InputView ?

No. It is not being called excessively in that case.