| Both sides previous revision Previous revision Next revision | Previous revision |
| indigo_2025.1_documentation:events_data_passing [2025/09/23 10:29] – davel17 | indigo_2025.1_documentation:events_data_passing [2025/12/14 20:10] (current) – [How do you pass data through?] jay |
|---|
| The //''source''// item is a little more tricky. Here are the possible values: | The //''source''// item is a little more tricky. Here are the possible values: |
| |
| - //''server''// - this is what will show if the server performed the event on it's own during the normal course of operations. A device state change trigger, a schedule fires, etc. | - //''server''// - this is what will show if the server performed the event on it's own during the normal course of operations. A device state change trigger, a schedule fires, etc. |
| - //''python''// - this is what the source would be if the operation was started via an IOM command. So if you did a //''indigo.actionGroup.execute(12345)''// this is what the source would be. | - //''python''// - this is what the source would be if the operation was started via an IOM command. So if you did a //''indigo.actionGroup.execute(12345)''// this is what the source would be. |
| - //''api-http''// - similar to //''python''// above, but if the command came in through the HTTP API. | - //''api-http''// - similar to //''python''// above, but if the command came in through the HTTP API. |
| - //''api-websocket''// - similar to //''api-http''//, but the command would have come through a websocket. | - //''api-websocket''// - similar to //''api-http''//, but the command would have come through a websocket. |
| |
| Plugin supplied events (for instance, the Z-Wave Command Received event, email received event, or any event that your plugin may provide) will **add** the following plugin specific information: | Plugin supplied events (for instance, the Z-Wave Command Received event, email received event, or any event that your plugin may provide) will **add** the following plugin specific information: |
| |
| <code> | <code> |
| | message = {"somekey": "some value"} |
| indigo.trigger.execute(trigger_instance, trigger_data=message) | indigo.trigger.execute(trigger_instance, trigger_data=message) |
| </code> | </code> |
| |
| Some notes on standards for your data: | Some notes on standards for your data: |
| | * You won't want to duplicate any of the above built-in names as it would get overwritten. |
| - You won't want to duplicate any of the above built-in names as it would get overwritten. | * You probably want to name your keys with something that's easily identified with your plugin. For instance, the Z-Wave plugin uses the prefix `zwavecmd-` for it's keys that describe the event data that it passes through. |
| - You probably want to name your keys with something that's easily identified with your plugin. For instance, the Z-Wave plugin uses the prefix `zwavecmd-` for it's keys that describe the event data that it passes through. | * We tried to use dashes `-` as separators rather than underscores - we think that's a better option for string keys. |
| - We tried to use dashes `-` as separators rather than underscores - we think that's a better option for string keys. | * Keys should follow the restrictions on `indigo.Dict` keys (alphanumeric, dash, underscore, starting with a letter). |
| - Keys should follow the restrictions on `indigo.Dict` keys (alphanumeric, dash, underscore, starting with a letter). | |
| |
| FYI, you can pass arbitrary data around using the IOM and the various `.execute()` actions on Triggers, Schedules, and Action Groups. Just pass through //''trigger_data''//, //''schedule_data''//, //''event_data''// respectively to those function calls when performing them through the IOM. | FYI, you can pass arbitrary data around using the IOM and the various `.execute()` actions on Triggers, Schedules, and Action Groups. Just pass through //''trigger_data''//, //''schedule_data''//, //''event_data''// respectively to those function calls when performing them through the IOM. |
| This is a complete action handler with type hints. While we don't envision a scenario where //''event_data''// is passed `None`, it's possible that it may happen or could be optional at some point in the future, so your code should make sure that the data is present before assuming anything. | This is a complete action handler with type hints. While we don't envision a scenario where //''event_data''// is passed `None`, it's possible that it may happen or could be optional at some point in the future, so your code should make sure that the data is present before assuming anything. |
| |
| === Examples of how it may be used === | === Examples of How Events Data Can Be Used === |
| | There are likely a lot of different scenarios where //''event_data''// is useful, but it may be helpful to see a complete working example all in one place. Here is a simple example just to show how straightforward the mechanism can be. |
| | |
| | Create an Action: |
| | * Create an Action Group called "Log Event Data" |
| | * Select **Server Actions** > **Script and File Actions** > **Execute Script** |
| | * Select Embedded Python and enter the following short script into the code block. Notice that we didn't do anything special to access the //''event_data''// payload. It's automatically supplied by the host process when the script is called __due to an event__. |
| | <code> |
| | indigo.server.log(f"{event_data}") |
| | </code> |
| | * Select OK |
| | |
| | Create a Trigger to fire the action: |
| | * Create a Trigger called "Log Event Data" |
| | * You can link it to an event, but for this example the event type doesn't matter |
| | * You can also set a Condition, but for this example the condition doesn't matter either |
| | * On the Actions tab, select **Server Actions** > **Execute Actions Group** |
| | * Select the "Log Event Data" Action you created above |
| | * Select OK |
| | |
| | Now, from the Actions list in Indigo, highlight the "Log Event Data" Trigger and select **Execute Actions Only**. When your Trigger fires the script, something similar to the following should appear in the Events log: |
| | |
| | <code> |
| | Trigger Event Data Trigger |
| | Action Group Event Data Example |
| | Script EventDataDict : (dict) |
| | event-indigo-id : 553162605 (integer) |
| | event-type : DeviceStateChangeTrigger (string) |
| | source : server (string) |
| | timestamp : 2025-10-31T10:18:37 (string) |
| | </code> |
| | It's that simple. |
| |
| There are likely a lot of different scenarios where //''event_data''// is useful. One thing that comes to mind almost immediately would be for plugins that provide virtual devices/wrappers/shims to allow the user to specify a path in the data then map that into either a custom state or a property (onState, etc). Combine this functionality with the [[indigo_2025.1_documentation:webhooks|Webhook functionality]] and it would make it possible to have a webhook directly update a virtual device. This would reduce a lot of glue code necessary now in handling those types of things. | === Get Creative === |
| | The new //''event_data''// mechanism opens up a lot of possibilities for plugin developers. One thing that comes to mind almost immediately would be for plugins that provide virtual devices/wrappers/shims to allow the user to specify a path in the data then map that into either a custom state or a property (onState, etc). Combine this functionality with [[indigo_2025.1_documentation:webhooks|Webhook functionality]] and it would be possible to have a webhook directly update a virtual device. This would reduce a lot of glue code necessary now in handling those types of things. |