spud
I'm not sure if there is a better place to raise this, but I assume you are working on coding for a HS4 version of Easy Trigger and wanted to raise a few issues with the current version that I'm hoping you might be able to address in the HS4 version.
The purpose here is not to call for new features, but rather to address a few issues I've run into with current operation where there are a number of non-obvious "errata" that seem like they would be hard for new users to identify / diagnose.
They relate to the following subjects (which are detailed below):
1. Startup Initialization Delays
2. Handling of Global Variables (etDeviceName, etDeviceStatus, etDeviceLocation1, etDeviceLocation2, etDeviceRef, etDeviceValue)
3. Better recognition of Devices in Easy Trigger Groups when using the Events page "Referencing Device(s)" Events Drop-Down.
I'm assuming that a number of the issues may exist due to limitations in the HS3 plugin API, but as HS4 is still unreleased, maybe there's an opportunity to influence it and the plugin API to improve the operations.
Here are my thoughts:
1. Startup Initialization Delays.
In HS3, I have the startup script set to automatically runs an event on startup. That startup event includes actions that make use of Easy Trigger dynamic groups. I've found that the Easy Trigger groups will occasionally result in a Warning that the group is missing. I believe this is due to the fact that Easy Trigger is still initializing. While this can be handled by inserting a large delay at the start of the startup event, it would be better if the end-user didn't have to experiment and figure out the root cause in order to address this.
With this in mind, it seems useful to have HomeSeer wait until plugins finish initializing before running events.
I was thinking of something along the following lines might be a way to address the issue of events running before plugins are ready:
(i). Adding Plugin SDK calls where the plugin (a) informs HS that it should wait until the plugin finishes initialization before HS runs events, and also specifies a maximum wait time - say 3 minutes; (b) and another call where the plugin can report that it has completed initialization.
(ii). HS should delay running events until all plugins that have requested that HS wait for initialization have reported initialization is complete. HS should have a "safety" timeout just in case a plugin fails to report completion - i.e., it should have a maximum initialization wait time of, e.g., 5 minutes, after which HS4 will no longer wait but will, instead, log an excessive initialization time error.
2. Handling of Global Variables
Currently, as I understand the way that Easy Trigger global variables work, if you have an Event that triggers based on an Easy Trigger trigger, and that event takes a while to execute (for example, it has "wait" actions or slow actions), it is possible for the etGlobal variables to be overwritten by another triggering event before your first event is done processing them. What I suggest is that when an Easy Trigger event triggers, the event makes a local copy of the variables which live for the scope of the event and which are used for subsequent processing of statements within the event. That way, multiple events could trigger at about the same time and the global variables won't be overwritten. I assume there may be other / better /easier to program ways to address this concern - e.g., maybe HS4 has some better local scoping mechanism or something could be added at this stage; so if there is another solution on the way, that would be just as welcome.
3. Groups and the Events "Referencing Device" drop down.
Currently, if you select a particular device in the "Referencing Devices" drop-down on the Events page, you will only see the associated event if the device is explicitly identified in an trigger / condition / action, but you won't see the event if the device is part of an Easy Trigger group. This can make it hard to trace which events are influencing which devices. The "preferred" solution for this would be if HS4 had its own "group" defining mechanism so that all plugins could see / access / share groups. However, if that isn't happening, consider if there is a way of "influencing" the plugin SDK development such that, when devices in the "Referencing Devices" drop down are selected, there is a way of identifying the relevant Events that may have the device as part of an Easy Trigger Group so that the proper list of Events could be displayed in the Events list.
I'm not sure if there is a better place to raise this, but I assume you are working on coding for a HS4 version of Easy Trigger and wanted to raise a few issues with the current version that I'm hoping you might be able to address in the HS4 version.
The purpose here is not to call for new features, but rather to address a few issues I've run into with current operation where there are a number of non-obvious "errata" that seem like they would be hard for new users to identify / diagnose.
They relate to the following subjects (which are detailed below):
1. Startup Initialization Delays
2. Handling of Global Variables (etDeviceName, etDeviceStatus, etDeviceLocation1, etDeviceLocation2, etDeviceRef, etDeviceValue)
3. Better recognition of Devices in Easy Trigger Groups when using the Events page "Referencing Device(s)" Events Drop-Down.
I'm assuming that a number of the issues may exist due to limitations in the HS3 plugin API, but as HS4 is still unreleased, maybe there's an opportunity to influence it and the plugin API to improve the operations.
Here are my thoughts:
1. Startup Initialization Delays.
In HS3, I have the startup script set to automatically runs an event on startup. That startup event includes actions that make use of Easy Trigger dynamic groups. I've found that the Easy Trigger groups will occasionally result in a Warning that the group is missing. I believe this is due to the fact that Easy Trigger is still initializing. While this can be handled by inserting a large delay at the start of the startup event, it would be better if the end-user didn't have to experiment and figure out the root cause in order to address this.
With this in mind, it seems useful to have HomeSeer wait until plugins finish initializing before running events.
I was thinking of something along the following lines might be a way to address the issue of events running before plugins are ready:
(i). Adding Plugin SDK calls where the plugin (a) informs HS that it should wait until the plugin finishes initialization before HS runs events, and also specifies a maximum wait time - say 3 minutes; (b) and another call where the plugin can report that it has completed initialization.
(ii). HS should delay running events until all plugins that have requested that HS wait for initialization have reported initialization is complete. HS should have a "safety" timeout just in case a plugin fails to report completion - i.e., it should have a maximum initialization wait time of, e.g., 5 minutes, after which HS4 will no longer wait but will, instead, log an excessive initialization time error.
2. Handling of Global Variables
Currently, as I understand the way that Easy Trigger global variables work, if you have an Event that triggers based on an Easy Trigger trigger, and that event takes a while to execute (for example, it has "wait" actions or slow actions), it is possible for the etGlobal variables to be overwritten by another triggering event before your first event is done processing them. What I suggest is that when an Easy Trigger event triggers, the event makes a local copy of the variables which live for the scope of the event and which are used for subsequent processing of statements within the event. That way, multiple events could trigger at about the same time and the global variables won't be overwritten. I assume there may be other / better /easier to program ways to address this concern - e.g., maybe HS4 has some better local scoping mechanism or something could be added at this stage; so if there is another solution on the way, that would be just as welcome.
3. Groups and the Events "Referencing Device" drop down.
Currently, if you select a particular device in the "Referencing Devices" drop-down on the Events page, you will only see the associated event if the device is explicitly identified in an trigger / condition / action, but you won't see the event if the device is part of an Easy Trigger group. This can make it hard to trace which events are influencing which devices. The "preferred" solution for this would be if HS4 had its own "group" defining mechanism so that all plugins could see / access / share groups. However, if that isn't happening, consider if there is a way of "influencing" the plugin SDK development such that, when devices in the "Referencing Devices" drop down are selected, there is a way of identifying the relevant Events that may have the device as part of an Easy Trigger Group so that the proper list of Events could be displayed in the Events list.
Comment