Plugin SDK v1.5.2.0 Release Notes

This release focuses on events. Triggers can now tell whether they are being used as a trigger or as a condition, and triggers and actions can list every device and feature they reference in a single call. It also adds a way to get the list of running plugins.

• (PSDK-111) GitHub #277 Add AbstractTriggerType.IsCondition to tell whether a trigger is being used as a trigger - the "WHEN" or "OR WHEN" part of an event - or as a condition - the "IF" or "AND IF" part of an event.
  • Unlike CanBeCondition, which describes the trigger type, IsCondition describes the particular instance a user placed in an event. Use it to word GetPrettyString and to adjust the ConfigPage to the role the trigger is playing. It is already set when your trigger's constructor runs.
  • Add TrigActInfo.IsCondition, which is set by HomeSeer. Read AbstractTriggerType.IsCondition instead of this field.
  • Clarify the documentation of the isCondition parameter of AbstractTriggerType.IsTriggerTrue. HomeSeer only calls it for conditions, so it is always TRUE.
• (PSDK-319) Add IHsController.GetPluginsList to get the list of the plugins that are currently running. Each entry reads "name:instance".
• (PSDK-320) GitHub #364 Add methods listing every device and feature a trigger or action references at once.
  • Add AbstractTriggerType.GetReferencedDevicesOrFeatures and AbstractActionType.GetReferencedDevicesOrFeatures. Override them so HomeSeer asks once per trigger or action instead of calling ReferencesDeviceOrFeature for each device on the system, which instantiates the trigger or action each time. The list must agree with what ReferencesDeviceOrFeature returns. The base implementation returns NULL, and HomeSeer then falls back on ReferencesDeviceOrFeature.
  • Add IPlugin.TriggerReferencedDevicesOrFeatures and IPlugin.ActionReferencedDevicesOrFeatures. AbstractPlugin implements them. Plugins that implement IPlugin directly must add them.