This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision |
| indigo_2025.1_documentation:events_data_passing [2025/10/31 15:43] – [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 |
|---|
| |
| <code> | <code> |
| | message = {"somekey": "some value"} |
| indigo.trigger.execute(trigger_instance, trigger_data=message) | indigo.trigger.execute(trigger_instance, trigger_data=message) |
| </code> | </code> |
| |
| === Get Creative === | === 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. | 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. |