@Dianoga, yup defaults are a thing, and I see that now since @baldeagle072 called defaultValue out to me. Thanks to both of you for replying
You also describe just what I’m trying to work around - that the settings collection is not mutable from the app, only by the user from the UI. I can’t imagine the rationale behind this partitioning.
My use case is that I want to manage user codes for one or more locks. Each device will be the source of truth for its own data set. In fact, I want the app to not hold any state for the devices, Just taking the simple scenario of a single lock.
I can list the codes already set in the lock device within the app. How I’d like to do this is that, on tapping an existing code or a button toe create a new code, I’d show a page that I reuse with blanks for Name and Code. The variables would always be empty, but I’d use defaultValue if I had to pre-fill a value. If I’m adding a new code, the inputs would be blank. If I’m editing a slot, the inputs would be pre-filled with whatever valued the lock had data for the slot I’m editing (using defaultValue). If deleting a value, I’d use a separate button the on the page. In all cases, once I collect and use the values from the input fields in the updated method, I don’t need or want the settings variable nodes any longer.
The only way I can see to do this is to generate new settings variable names for each invocation of an add, edit or delete since I can’t flush or override whatever values had been in them previously. This seems hugely wasteful at best, and explicitly coding a memory/storage leak at worst.
I’ll be the first to acknowledge that this may be a sign that this isn’t the right way to accomplish this goal - is there a more SmartThings way to go about this? Could using a child app help here? I could only see that working if a child app instance can be brought into existence when I go to add/edit a code, and destroyed after I do what I need to do with the data. Of course, addChild is mentioned only once in the docs (http://docs.smartthings.com/en/latest/smartapp-developers-guide/dashboard-solution-smartapps.html?highlight=addchild) , and there’s no hint of a “removeChild”
To give a thumbnail of why I’m going down this road - I want to manage locks in tandem. Say front and back door locks. I want to set code 8675309 for Jenny, and have it propagate onto both locks. I don’t care what slot number it is in on the locks, or even if it’s in the same slot on each. The device can handle the slot-name-code acrobatics, and the app’s purpose is to provide the UI, and a sensible UX to the end user. Future directions include selecting which lock(s) a code would be inserted on, setting schedules and the like.