Yes, ignored or otherwise more flexable. Let me get you what I’m trying to pull off.
My app would host N number of settings given an automation, not a set config value but it will have 1-N number of “Users” which will have many sub-settings such as schedues, notification rules, ect.
I’ve been able to hack this to work on the new platform, but it’s hacky and dirty.
What I’ve done is generate a KEY on my app per each “user” setting that needs to be avalivle on the SmartThings UI. That includes, but isn’t limited to “code” and “name:”
Since SmartThings expects ID NAME and CODE for these fields to always represent the same value, I cannot override the input values for these when it renders on the SmartThings UI. So my app generates a UUID for the user on create, and makes a new ID for each field value:
Example lifecycle JSON:
This seems to work but gets MESSY fast. Consider when a “user” is deleted in the app. I will cease automating that user’s settings and then not render the config values to SmartThings during the lifecycle events, however SmartThings will continue passing these values during the lifecycle phase forever through out the life of the app. It’s possible (likley) that certain users would have hundreds of these users through out using the app, and this will make lifecycle CONFIG passing very large.
What I’ve seen that may help:
Being able to DELETE config values from the lifecycle process. When a user DELETES a “user” in their app, I would have my app delete all the config keys associated with that UUID.
What would be better:
Let my app set the VALUE that the SmartThing UI renders on the lifecycle event, simular to how DefaultValue works, but instead let me set the value explicitly even when SmartThings “thinks” it knows what the value is.
Currently, I don’t think there’s any reason to store many of the values that the app uses in SmartThings config cycle OTHER than to display them to the end user for information or editing.
All I need is to be able to set a param (say a UUID) to the lifecycle to render a CONFIG UI to the user, then when the lifecycle triggers to submit that config back to the app, I can use that UUID to update the data in the database for that config value.