New API PAGE Params?

Is there any way to pass some meta info through PAGE confirmation during Webhook app config lifecycle that would be passed back to the parent app on PAGE request?

This would be helpful for my app to be more simple on the backend instead of writing many pages for something I could write one and then process logic based on a param that doesn’t need to be saved.

Thoughts?

Ideal world example:

...
   sections [
      {
        name: "Hello World",
        settings: [
          {
            id: "pizza",
            name: "Look for Pizza",
            description: "Tap to look",
            type: "PAGE",
            ***params:*** {
              item: 'pizza'
            },
            page: "look_for_food"
          },
          {
            id: "burgers",
            name: "Look for Burgers",
            description: "Tap to look",
            type: "PAGE",
            :***params:***: {
              item: 'burgers'
            },
            page: "look_for_food"
          },
        ]
      }
...

Hi, there! Let me see if I understand, you want to show some values (parameters) in the Configuration page of the SmartApp but you want them to be ignored in the Install Lifecycle?

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:”

User:
Code: [Int]
Name: [string]

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:

user:[uuid]
code_[uuid]: [int]
name_[uuid]: [int]
ect_[uuid]: [ect]

Example lifecycle JSON:

"config"=>{
"name:vgUUog"=>[{"valueType"=>"STRING"
 "stringConfig"=>{"value"=>"Samantha"}}]
 "code:ifef2A"=>[{"valueType"=>"STRING"
 "stringConfig"=>{"value"=>"2345"}}]
  "name:ifef2A"=>[{"valueType"=>"STRING"
 "stringConfig"=>{"value"=>"John"}}]
 "code:XwMp1w"=>[{"valueType"=>"STRING"
 "stringConfig"=>{"value"=>"12345"}}]
 "code:vgUUog"=>[{"valueType"=>"STRING"
 "stringConfig"=>{"value"=>"44444"}}]
 "code:KvYEGA"=>[{"valueType"=>"STRING"
 "stringConfig"=>{"value"=>"2222"}}]

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.

So, you’re hosting a SmartApp and you want to allow other users to register it at the Dev Workspace and install it in their account using the URL you provide?
A SmartApp instance is identified by an ID (installedAppId). When you register it, you can allow multiple installations in the same location and each instance will be treated singularly thanks to its ID.
Therefore, it doesn’t matter if a lot of users use the same URL, each will have a different installedAppID and the configuration can be accessed from the context variable, which you can store and use through the withContext() function.
This is how you can differentiate the events and send commands to the corresponding devices.

I think you misunderstood my usecase solution/problem.

The app code itself will be hosted on an AWS virtual box and the underlying code is closed-source… this is correct. I am not currently worried about publishing this app, and will leave that to another day.

I think my mention of “user” in this case was misleading as “user” is not a referance to a SmartThings “user” but a referance to a config variable labled “user” in the prospective of a person who has access to a person’s door. “user” could be anything here, “member”, “client”, “foobar”.

An app install will contain MANY of “foobar” settings which will be used in logical control over an automation. app HAS_MANY “foobars” in this case many >codes< or >names< or >schedules<

As far as I can tell, the current Sections and settings offerings for user input does not allow for dynamically generated setting IDs.

Here’s a screenshot illustrating a hypothetical page in my app containing N number of pages to edit N number of “members/clients/foobars”

To get around this, my app generates a unique key for a dynamically generated input:

  {
    "id": "code_<GENERATED_KEY>",
    "name": "Access code",
    "description": "Tap to set a code to unlock this door",
    "type": "TEXT",
    "required": true
  }

This is great and works fine, but is a HACK in that if a user then decides to delete any given “member/client/foobar”, the SmartThings lifecycle will never forget about the settings param at that ID.
EG:

....
name_XwMp1w => "Sue"
code_XwMp1w => "1111"
schedule_XwMp1w => "datetime"
notify_enty_XwMp1w => "false"
notify_exit_XwMp1w => "true"
....ect ect ect....

Will always be shared on every single lifecycle event until the user deletes the app install. Over time, the lifecycle will be absolutely FULL of these declarations as some app installs will have had hundreds of entries.

If I just have a form like this:

name => "Sue"
code => "1111"
schedule => "datetime"
notify_enty => "false"
notify_exit => "true"
key => "XwMp1w"

I could render the from ONCE, but if I want the user to create another config for another key, say " ifef2A" then each of the inputs for the labels will be filled in with form entry values from previous lifecycles.

I think I get it now. Your Use Case is similar to an Admin panel to define those users configurations, right?

About this, I’m not sure if this is what you mean, but as you already have a list of users, you can create the inputs assigning a dynamic ID according to that list. Here’s one example where:

  • I have 3 inputs at the beginning.
  • When I install it, I remove one element of the list.
  • The next time I try to update the config, the element I deleted doesn’t generate an input.
    The other input’s previous value is kept, though.

Here’s also an example of inputs being created dynamically:

For future reference on the available settings, it’s better you look into this page.

1 Like

Thanks for your reply. I tried following your sample app logically in my head without running it as a demo so my apologies if I’m wrong, but here’s my understanding of it.

1: Install your “Dynamic Delete” App.
2: Initialize with 3 input options and save.
3: Your node app splices (deletes) one of the input options.

This works fine logically from the standpoint of your app, but in the scenario where:

1: comment out the “deleteOneElement()” function call L:41 (so that we dont splice the input out)
2: save all inputs with some input, could be anything.
3: save inputs on SmartThings lifecycle, via SmartThings mobile app.
4: run function deleteOneElement() on a UPDATE lifecycle once.
5: that element deleted will be deleted from the prospective of your NODE app.
6: It’s deleted on your node app, however from within the SmatThings lifecyle in “CONFIG” whatever value that was previously stored in that INPUT for a dynamic ID, it will always be sent to your app in the lifecycle process whenever a PAGE cycle happens. There doesn’t seem to be a way to programmatically delete the dynamic input without having the user null it out manually on the SmartThings app.

Maybe this isn’t really a huge issue, but I feel like it could be when hundreds of deleted dynamic inputs could possibly be loaded into a users app during a lifecycle PAGE process. My app can dynamically remember that these values are deleted, but they will still be present in the HTTPS calls that are sent from SmartThings (just ignored)

I see what you mean, the deleted values remain as part of the configurationData in the requests.
I’ll share this info with our engineering dept. and I’ll let you know their feedback.

1 Like

Exactly, you got it. Sorry I wasn’t able to communicate that so succinctly. :smile: