trigger.pluginTypeID usage

My trigger objects all contain an attribute named "pluginTypeId" that contains the <Event id = ...> from Events.xml. This attribute is not described in the IOM trigger base class. The name pluginTypeId does not seem appropriate for the Event id, so I'm curious about the intended use of this attribute. If I use it for my own purposes, will it be available in the future?

[jay (support)]

pluginTypeId is appropriate, as it represents the unique event type identifier for your plugin. This allows the server to dispatch events correctly to your plugin.

The Event IOM docs are pretty incomplete - mostly because you can't effectively create them programmatically. Conditions and more importantly Actions can't be manipulated via the IOM, so creating triggers programmatically is pretty useless since they won't do anything.

You don't really say exactly what it is you're trying to do, so I can't really say more.

Thanks, Jay.

Here is my plan: For Event id's that have multiple optional events, I plan to add an option called "any" which would trigger whenever any of the options occurred. In matching triggers with my plugin events, if the trigger.pluginProps['event'] is 'any' then I will match the event type id with the trigger.pluginTypeId instead of matching the event names.

[jay (support)]

I think I'm still missing some key pieces here - why would your plugin attempt to trigger events that don't belong to itself? And, event ID's inherently describe one event type, not multiple, so I don't understand what that means either. I think you need to more fully describe what you're trying to do...

Sometimes explanations fall short. My goal is to allow the user to optionally define an indigo trigger which will execute if any event of the same event type occurs. In the following Event.xml I define two event types <Event id="pigpioError"> and <Event id="limitFault">. Each of these types define multiple options for a <Field id-"triggerEvent" ....>. The user can select a specific trigger event or he can select "any" to execute the trigger if any one of them occurs. The code explains it best:

Code: Select all

<?xml version="1.0"?>
<!--
###############################################################################
#                                                                             #
#                              MODULE Events.xml                              #
#                                                                             #
###############################################################################

 PACKAGE:  Raspberry Pi General Purpose Input/Output for Indigo (Pi GPIO)
  MODULE:  Events.xml
   TITLE:  Pi GPIO event (trigger) objects (Events.xml)
FUNCTION:  Events.xml defines Pi GPIO events that may trigger specific indigo
           actions.  It identifies events, specifies GUI labels, and sets
           default values.
   USAGE:  Events.xml is read and interpreted by the indigo server during
           plugin startup.  When a user creates a new trigger, indigo uses the
           xml data to instantiate a trigger object per the indigo object model
           (IOM).
  AUTHOR:  papamac
 VERSION:  0.5.1
    DATE:  March 28, 2022


CHANGE LOG:

Major changes to the Pi GPIO plugin are described in the CHANGES.md file in the
top level PiGPIO folder.  Changes of lesser importance may be described in
individual module docstrings if appropriate.

v0.5.0  11/28/2021  Fully functional beta version with minimal documentation.
v0.5.3   3/28/2022  Change event field id's and add events for pigpio errors.

-->

<Events>


    <Event id="pigpioErrors">
        <Name>pigpio Errors</Name>
        <ConfigUI>

            <Field id="triggerEvent" type="menu" defaultValue="any">
                <Label>pigpio Errors:</Label>
                <List>
                    <Option value="any">Any pigpio Error</Option>
                    <Option value="startError">Start Error</Option>
                    <Option value="stopError">Stop Error</Option>
                    <Option value="readError">Read Error</Option>
                    <Option value="writeError">Write Error</Option>
                    <Option value="interruptError">Interrupt Error</Option>
                    <Option value="interruptResetError">Interrupt Reset Error</Option>
                </List>
            </Field>

        </ConfigUI>
    </Event>


    <Event id="limitFaults">
        <Name>Limit Check Faults</Name>
        <ConfigUI>

            <Field id="triggerEvent" type="menu" defaultValue="anyFault">
                <Label>Limit Check Fault:</Label>
                <List>
                    <Option value="any">Any Limit Fault</Option>
                    <Option value="lowFault">Low Limit Fault</Option>
                    <Option value="highFault">High Limit Fault</Option>
                </List>
            </Field>

        </ConfigUI>
    </Event>
</Events>

Within the plugin, the following method is used to execute the trigger:

Code: Select all

@staticmethod
    def _executeEventTrigger(eventType, event):
        for trig in indigo.triggers.iter(u'self'):
            triggerEventType = trig.pluginTypeId
            if trig.enabled and triggerEventType == eventType:
                triggerEvent = trig.pluginProps[u'triggerEvent']
                if triggerEvent == u'any' or triggerEvent == event:
                    indigo.trigger.execute(trig)


Example:

Code: Select all

self._executeEventTrigger(u'pigpioError', u'readError'). # Execute trigger if trigger GUI selects "Read Error" or "Any pigpen Error"

In this code, it is necessary to require that the event type be equal to the pluginTypeID to distinguish between the pigpioError and the limitFault events.

papamac

I haven't executed this code yet, so... there are some errors/typos. in the xml, "pigpioErrors" should be "pigpioError" and "limit Faults" should be "limitFault".. Also, there are no pigpen errors, only pigpio errors. Thanks to the spell checker for that one.

Thanks for your help,

papamac

Don't iterate through the entire list of triggers. Use

Code: Select all

triggerStartProcessing()

and

Code: Select all

triggerStopProcessing()

to maintain a list of your enabled triggers.

Code: Select all

    def triggerStartProcessing(self, trigger):
        self.logger.debug(f"{trigger.name}: Adding {trigger.pluginTypeId} Trigger")
        if trigger.pluginTypeId == "alertEvent":
            assert trigger.id not in self.alert_triggers
            self.alert_triggers[trigger.id] = trigger
        elif trigger.pluginTypeId == "modeEvent":
            assert trigger.id not in self.mode_triggers
            self.mode_triggers[trigger.id] = trigger
        elif trigger.pluginTypeId == "cameraEvent":
            assert trigger.id not in self.camera_triggers
            self.camera_triggers[trigger.id] = trigger

    def triggerStopProcessing(self, trigger):
        self.logger.debug(f"{trigger.name}: Removing {trigger.pluginTypeId} Trigger")
        if trigger.pluginTypeId == "alertEvent":
            assert trigger.id in self.alert_triggers
            del self.alert_triggers[trigger.id]
        elif trigger.pluginTypeId == "modeEvent":
            assert trigger.id in self.mode_triggers
            del self.mode_triggers[trigger.id]
        elif trigger.pluginTypeId == "cameraEvent":
            assert trigger.id in self.camera_triggers
            del self.camera_triggers[trigger.id]


Though, as I read your code a little more closely, it should work just fine. I've always maintained a list of enabled triggers, but doing the search for triggers for your plugin, then checking that they're enabled, should work fine. Not sure which way is more efficient. I think yours has more round-trips to the server, which is not that great, but it really depends on how many triggers (events) are returned by the search.

I think you were just getting hung up on the name of the property. I think it's that way to be consistent across other types of defined objects (devices, etc).

I think that in my case, there will be relatively few (5-10) triggers defined. In my mind that seems to favor using server accesses vs maintaining local lists. That's always a trade-off in indigo: the simplicity of using server data structures vs the efficiency (and complexity) of maintaining local lists. I've gone both ways on different occasions mostly based on gut feel. One time did a timing study on server accesses. There was a distinct advantage to local data structures, but even a factor of 2 difference was not a big deal in overall plugin performance. My Mac mini can deal with it.

Thanks for your interest in my problem.

papamac

[jay (support)]

I guess I'm still not quite understanding the issue, but if it's working then great!

hi Jay,

Sorry for all the confusion. The original concern in my first post was that the trigger attribute "pluginTypeId" is indeed intended to contain the <Event id=...> entry in Events.xml and that it would continue to be available as indigo evolves. Your reply seemed to confirm that, but you were curious about what I was doing. The confusion arose as I tried to explain why I cared.

Anyway, it works and all is well. Thanks for your help.

David (aka papamac)

[jay (support)]

Ah, OK. That's not at all how I read your OP. Thanks for the clarification.