Differences

This shows you the differences between two versions of the page.

--- indigo_2025.1_documentation:events_data_passing [2025/09/23 10:33] – [Events Data Passing] davel17
+++ indigo_2025.1_documentation:events_data_passing [2025/12/14 20:10] (current) – [How do you pass data through?] jay
@@ Line 46: / Line 46: @@
 <code>
+message = {"somekey": "some value"}
 indigo.trigger.execute(trigger_instance, trigger_data=message)
 </code>
@@ Line 52: / Line 53: @@
 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.
@@ Line 95: / Line 95: @@
 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.