Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
indigo_2025.1_documentation:events_data_passing [2025/09/23 10:34] – [How do you pass data through?] davel17indigo_2025.1_documentation:events_data_passing [2025/12/14 20:10] (current) – [How do you pass data through?] jay
Line 46: Line 46:
  
 <code> <code>
 +message = {"somekey": "some value"}
 indigo.trigger.execute(trigger_instance, trigger_data=message) indigo.trigger.execute(trigger_instance, trigger_data=message)
 </code> </code>
Line 55: Line 56:
   * 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. 
-  8 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.
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. 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 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.+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.
  • /www/perceptive/wiki/data/attic/indigo_2025.1_documentation/events_data_passing.1758623665.txt.gz
  • Last modified: 2025/09/23 10:34
  • by davel17