[ST Edge] What happens to unused references to presentation:device-config:create?

Developer Programs Support
1

I know this has been asked before in passing.

I’m experimenting more with device-config which acts as a final filter on how a device is displayed.

Today I was playing with the patch[] section. Since the device-config on its own doesn’t reference any living entities, there should be minimal syntax validation. At some point I started getting the following error from the CLI:

Error: Request failed with status code 400: {"requestId":"D0913D70-07A6-45A8-8AB0-2032727A3D1E","error":{"code":"UnexpectedError","message":"unsuccessful-http-call status=400","details":[]}}

I’ve found that if I change an (arbitrary) single character in the patch path, the error goes away. This sure looks like some sort of caching/storage issue specific to my account.

smartthings presentation:device-config:create gives you a vid/presentationId that can be referenced in a device profile. However, there does not appear to be a way to view/delete these objects. It looks like I’ve got a conflict with a phantom of sorts.

You can laugh at my example. I was trying to associate a filter with fanSpeed so that the enumerated options could be controlled dynamically. I don’t even know if that’s possible. I never got that far.

The following is rejected. I believe it was accepted previously.

{
  "type": "profile",
  "detailView": [
      {
          "component": "main",
          "capability": "fanSpeed",
          "version": 1,
          "patch": [
              {
                  "op": "add",
                  "path": "/0/list/command/supportedValues",
                  "value": "button.supportedButtonValues.value"
              }
          ]
      }
  ]
}

If I change the case of a single letter in path (e.g. “path”: “/0/list/command/supportedvalues”), the file is accepted. presentation:device-config:create has no usage context, so the values are arbitrary at this point.

2

Delete no, but you just ask the CLI if you want to see them. You can see both the presentation and the associated device config (you used to need the API for the latter but I think the CLI does it now - I cannot conveniently check at the moment).

I haven’t used ‘patch’ for quite a while so I can’t recall how it interacted with the hashing process and if I ever encountered the 400.

3

I’m talking about potentially orphaned device-configs. I can sit here and crank out new vid values on demand. The device-config references capabilities, but it does not reference a particular device. You get the vid first and then associate with a device profile later. Unless there’s some timeout and recycle mechanism, won’t the vids just pile up? I think we’ve all experienced problems with updates to custom presentations being ignored. The solution there seems to be renaming the capabilities. I’m seeing similar problems with device-config. I had something that worked as expected and after several revisions, I can’t get back. device-config is only necessary for stock capabilities. Stock capabilities cannot be renamed to influence the hash. It’s a catch-22.

I will retrace my steps after some sleep. I can put my files under source control, but I have no way to verify what’s happening in the cloud.

4

Ah sorry, I see where you are going. We can’t tidy up after ourselves.

Unless I have misunderstood the presentations all along, they aren’t even ‘ours’. They are a hash of the device config contents. So if I am working on a similar device to you with stock capabilities we could ‘create’ the same presentation. The explanation I saw for this was that they didn’t want lots of identical presentations.

From my point of view this seems odd. I may have, say, ten active presentations, but because we can’t update them I have probably created a couple of hundred, most of which will never be used because they have my custom capabilities in them, many of which no longer exist.

Maybe the big numbers that ST see from their end makes the situation look different.

Maybe there is some tidying up.

5

I figured out why my device-config suddenly wasn’t being applied. At some point I indented the following which changed the context in the profile. YAML is more compact, but without bounding braces (JSON), it’s very easy to introduce errors.

metadata:
    mnmn: SmartThingsCommunity
    vid: 17967b88-fea5-3036-8e49-7d9179046900

    metadata:
        mnmn: SmartThingsCommunity
        vid: 17967b88-fea5-3036-8e49-7d9179046900