What is best way to migrate a trigger

[ab39870]

In my Plugin I can have Events of id="x" or id="y". As part of a new release of the plugin I want to convert all Triggers with Events of id="x" to Triggers with Event id="y" and will be removing the ability to have Events of id="x".

I initially thought about doing this in the triggerStartProcessing method but it appears this method only runs for enabled triggers. But since you can still edit disabled triggers this could be a problem.

My current thinking is to do this within the startup method. Posting here to see if that makes the most sense or is there a preferred or better way.

[whmoorejr]

I'm not sure if this will be helpful, but I'm also curious about your situation.

A trigger is based on the created states of a device... so I'm guessing it's the state id's for the device in your plugin that's changing?

If there are a new set of state ids, you could run a parallel set for a while. " x" states & "y" states with a change to the <TriggerLabel>Depreciating next version - x state name </TriggerLabel>

But if the state id is staying the same, even if the name of the state changes, I would think the user's triggers would be unaffected.

If there is not a way to auto migrate triggers.... maybe it would be good to have a 0.5 release. A release with the old and new set of trigger options with a notation of which triggers will be depreciated on the full release, so release 1.0 will have only the new "y" triggers and you can clean all the "x" stuff out of your plugin.

[DaveL17]

I think startup() is a good place to do it. That is, I'd put the migration code into its own method and then call that method from startup(). You could also use some kind of a flag (like a hidden plugin prop) to track whether the migration has been done -- so the step would be skipped in future plugin starts.

[ab39870]

Thank you DaveL17 and whmoorejr.

I (re)reviewed the Trigger API and also realized I need to clarify what I was intending to do. I also think I know the best path forward for my scenario which your posts helped me think about.

I am depreciating a particular Plugin Event. Another Plugin Event has been updated that can perform the same function and some additional functions too. From the API documentation and my own testing, when a Plugin Trigger is created, the Plugin Event associated with the trigger is stored in the property "pluginTypeId". That property does not appear to be editable - it is read-only. And while I can look for all triggers that have pluginTypeId = "theEventToBeDeprecated" and then create a new Plugin Trigger with the pluginTypeId of "theEventThatReplacesIt"; it does not appear the Indigo API allows me to access any of the conditions or actions associated with the Trigger to create. Thus, I don't see any automated way to change all Plugin Triggers of pluginTypeId = "theEventToBeDeprecated" to pluginTypeId of "theEventThatReplacesIt" such that no changes are required by the user. Not ideal, but its a corner case and I don't expect the API to handle every case.

So my current planned path forward is:

1. I believe I can modify the pluginProps in Events.xml and convert these as needed for each applicable Plugin Trigger on startup() such that converting from one Event to the other is seamless - all values will "carry over".
2. Release the next version with both Events (both Events exist in the current version too) and disable the ability to change the to-be-deprecated Event settings by making all fields readonly in the Events.xml for the to-be-deprecated Event.
3. Use my Release Notes and the startup() and the triggerStartProcessing methods to WARN the user that these type of Events will be deprecated in a future release, can not longer be modified, and the Trigger needs to be changed from the current to-be-deprecated Event to the other type of Event by simply editing the Trigger, changing the Event type, and re-saving the Trigger. From testing, this appears to work fine and retains all the Conditions and Actions of the Trigger with the new Event type.

[DaveL17]

That sounds like a pretty good plan to me. Sometimes managing development changes across plugin versions can become tricky.

[jay (support)]

TBH, I would just remove the event entirely and convert the existing ones. You can document the transition in your Release Notes, but I think the extra work of leaving the old one in isn't particularly useful.

[ab39870]

Jay,

Thanks for the reply.

I don't see any way to simply convert a Plugin Trigger of pluginTypeId = 'X' to pluginTypeId = 'Y'.

And while I see from the documentation that I can create a new Trigger with the correct Event type/pluginTypeId and even include all the needed pluginProps (i.e. migrate those from the other Event data); as far as I can tell, the new Trigger won't have the Conditions or Actions from the previous Trigger. So thus user will still have to go in and re-create those on the newly created Trigger.

I'd be happy if I am missing something.

[jay (support)]

Ok, sorry, I thought you could change the typeId (missed it in your post above). Apparently not...