Google Latitude

[jay (support)]

Apparently it isn't a big omission given that you've just now missed it...

It's been on the feature request list for years but has just never gotten high enough on the priority list to make it into a release. It was my feeling that plugin devices and the potential for less rigid states may increase the priority but so far that hasn't really panned out. Anyway, we'll look at it for future releases.

There's nothing stopping you from implementing a custom event in your plugin to do it. You're getting all the state changes any way so it would probably be pretty easy for you to add.

Apparently it isn't a big omission given that you've just now missed it...

It's been on the feature request list for years but has just never gotten high enough on the priority list to make it into a release. It was my feeling that plugin devices and the potential for less rigid states may increase the priority but so far that hasn't really panned out. Anyway, we'll look at it for future releases.

There's nothing stopping you from implementing a custom event in your plugin to do it. You're getting all the state changes any way so it would probably be pretty easy for you to add.

The only way I see to do it would be to create yet another device type to be a "street scanner", where the user could place a street to monitor for....

Surely there has to be a better way to do that? I don't recall a way to create a custom trigger beyond the editor? Or is there a mechanism in the plugin to create a custom trigger?

[jay (support)]

Yes, there is a pretty simple solution: create a plugin-defined event in your plugin.

So rather than using a device state changed trigger, they use your custom event as the trigger. Your custom event would collect the device id and pattern to match and then whenever that state changes in the device your plugin would check it's events to see if there was a match. If there was, then you'd fire the actions.

Look at the Airfoil plugin for examples of plugin-defined events.

Yes, there is a pretty simple solution: create a plugin-defined event in your plugin.

So rather than using a device state changed trigger, they use your custom event as the trigger. Your custom event would collect the device id and pattern to match and then whenever that state changes in the device your plugin would check it's events to see if there was a match. If there was, then you'd fire the actions.

Look at the Airfoil plugin for examples of plugin-defined events.

Jay,

There's a disconnect in the Wiki documentation....

The wiki describes creating the Events.xml, but doesn't go into any details on how to utilize it.

The Airfoil plugin gives some good examples on how to create the custom XML to create a custom trigger...
But I don't see, in the airfoil python code, how it detects the tri.......

Okay.... I think I partially Grok it now.... But using the Airfoil code as an example is going to cause some massive headaches....

I really, really, *really* encourage you to update the wiki docs, and include some minimalistic examples, that are less convoluted.
Or at least finish the "FixMe"'s....

If I am reading this right...

1) I'll need to add a triggerStartProcessing, to filter just the single trigger I want, and presumably pass on all other triggers. (Presumably the pass on all other triggers is automatic, since I don't see the TriggerStartProcessing passing data to any other function).

2) Ditto for triggerStopProcessing....

- Ben

Jay,

Okay, I have created a custom event, and I have to say this needs better documentation....

I have it working, but I don't know if it's because I am using it in the official manner, or if I've just kludged it...

1) Trigger Processing isn't necessary. I started with it, but it seems to be completely unnecessary, since I'm manually triggering the triggers anyway
2) I would suggest that the indigo.triggers contain a pluginTypeId set to "built-in" or something similar... The "Aquarium Motion" trigger in the default database doesn't have a PluginId and I've worked around it. But it would be nice if I didn't have to work around it.

Using the custom events could be quite handy...

What I can't understand is that the Trigger that I created is always firing when the Plugin is reloaded...? Any idea on why this might be happening?

[jay (support)]

Event processing works very similar to device processing. If your user has created any of the events (triggers) your plugin defines, then on plugin startup/trigger enable/trigger create (just like devices) triggerStartProcessing() will be called with the trigger instance as configured by the user. You will then do whatever you need to do to keep a reference to those triggers so that when the appropriate event occurs (in this case the device state changes) you can then fire the appropriate actions. Triggers that aren't defined by your plugin won't be called because your plugin isn't responsible for them.

We have a todo on our list to add an Event example plugin to the SDK we just haven't gotten around to it. You're a sharp guy though so you should be able to figure it out from the Airfoil plugin. In a nutshell, the Airfoil does this:

1. On triggerStartProcessing, it adds the trigger to a dictionary of active triggers using the trigger type as the key
2. When something changes in Airfoil it checks the dictionary for triggers of that type (like a speaker change for instance). If it finds a speaker change trigger, it looks further to see if the change matches the trigger definition (in this case there's nothing else to check but it could, for instance, see if the new speaker contains some string). If it does, then it executes the trigger (which, by default, will have the conditions associated with the trigger evaluated).
3. On triggerStopProcessing, it removes the trigger from the dictionary.

The flow of custom event processing is almost identical to how device processing works.