Differences

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

--- indigo_2025.1_documentation:events_data_passing [2025/10/04 14:05] – [Examples of how it may be used] 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 94: / 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.
-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 [[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.
+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.
+=== 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.