Custom Capability and CLI Developer Preview

Developer Programs Tutorials
,
1295

The only thing that works for me is making a completely new capability with a new name and generating a new vid with that.

1296

Iā€™m seeing this problem too - it seems to have gotten worse. I used to be able to make tweaks to my presentation and have it show up within 24 hours. But now, I canā€™t get ANY changes to show up. I even created a new capability and added it to my device config, and itā€™s not showing up either - almost 24 hours later now.

Thank you for the suggestion of changing the capability name. I was also going to try changing the ā€˜versionā€™ value in the device config to see if that would have any effect since Iā€™ve never changed it from the default ā€œ0.0.1ā€. My next act of desperation was going to delete and re-create my device profiles and capabilities, but OMG what a pain that would be. Having to change the capability name would still require coding changes, which is NUTS.

1297

Iā€™ve been defining custom capabilities in order to get a better understanding of the feature and the development process. I feel the pain of community members who have been fighting the caching issues. However my first experience of the process today was encouraging. Is this first timer luck?

Changes to Custom Capability Presentations were getting refreshed in the ST app in approximately 60 seconds!!!

Here is my development process

  1. Create a Custom Capability definition and associated Capability Presentation

  2. Create a Device Type Handler (in the IDE) and associated Device (Type) Configuration

  3. Create a Device (in the IDE)

  4. Open the ST App on my iPad

  5. Update the Capability Presentation

  6. Re-Create the Device (Type) Configuration

  7. Exit the ST App (I am using IOS)

  8. Wait for 60 seconds

  9. Reload the ST App and Hey Presto the capability presentation change appears!

Repeat from Step 5.

1298

I donā€™t think the version does anything at this point.

Only the capability name has to change
The setter command and attribute names I think can stay the same. So you can slot in a new capability without changing the code, only the device config and vid will change.

1299

I did experience this error when creating my Device Type Handler.
Is this a BUG?

Groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method physicalgraph.device.CapabilityService#syncCustomCapabilityWithDuplo. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [class physicalgraph.device.Capability] [class physicalgraph.device.cache.CapabilityDTO]

The workaround is:

  1. Comment out the reference to the Custom Capability
  2. Create the Device Type Handler
  3. Remove the comments
  4. Save and publish the Device Type Handler.
1300

Youā€™re supposed to have the DTH installed before creating custom capabilities.

1301

Hi Matvel, Iā€™ve got loads of Custom Capabilities defined. Some are used in DTHs others are not.
The way I understand it you build (custom) Capabilities which may then be used in DTHs (current world) or Device Profiles (new world).

1302

Ahā€¦ you are referring to the ā€œnameā€ value in the capability json? Not the capability id itself. Now thatā€™s definitely something to try. But how exactly are you forcing a new VID to be created if the id isnā€™t changing?

Also, this doesnā€™t explain why a brand new capability added to an existing device configuration isnā€™t showing up. I still need to generate a new VID somehowā€¦

1303

No, Iā€™m referring to the ID. For example I hit a cache with circlefield05082.binstatus so I made a new capability circlefield05082.newbinstatus

The name of your attributes and commands inside this capability seem to be irrelevant, so you can use the same commands and attributes in order to avoid rewriting code.

You will need to generate and create a new device config and will get a new vid.

If youā€™re trying to update custom attributes or capabilities from an old DTH to support the new app, all you need to do is use the same name for the attributes and commands and they should just work. But youā€™ll want to comment out the old capability or attribute definitions in the DTH so it uses your new ones instead.

1304

Iā€™m working with direct-connected devices (device profiles via Developer Workspace)- no DTH or groovy. In the device app, you have to specify the id of the capability you are working with, so if the id changes, the code has to be updated (isnā€™t this also true of DTHs??). The only way I know to force a new VID to be created is to create a whole new device profile and you canā€™t even do that through the API!! You have to do it manually through the DW. This is not a reasonable option for anyone.

I donā€™t think the issue Iā€™m seeing is even a caching issue; if that were the case, I should still see changes within 24 hours. Right now, Iā€™m seeing NONE; EVER. Well, there was this one time when a change randomly appeared about 2 weeks after I had submitted the json update!!

1305

You include the capability in a DTH, but when you call the commands associated with it or sendEvent to update an attribute, you arenā€™t using the id. Since you can keep the names of the commands and attributes the same, you only need to change the line where you include the capability (and change the vid). And changing the id of the capability will definitely change the resulting vid.

But I have no idea how direct connected devices work, I have never used one.

1306

Beginners luck? :grin:

In the beginning I could see changes get updated in a reasonable timeframe as youā€™re seeing, but something has changed and devices/capabilities Iā€™ve had defined for months are no longer able to be updated. Itā€™s so much manual work to get them defined and setup; the thought of having to delete everything and re-create every time I want to tweak something is just ridiculous.

1307

Thatā€™s all I meant - you still have to go into your code to change the id. Which means stopping and restarting your devices. So what you are saying is to create a whole new capability. Well, yesterday I created a brand new one, added it to my device config, and itā€™s still not showing up over 24 hours later, and based on how things have been working the last couple weeks, it may never show up unless I completely re-create a new device profile.

Youā€™d think after 7 months weā€™d have a more productive development environment by now.

1308

The device usually has to be deleted and readded.

1309

Yea - even worse! A real nightmare with direct-connected devices because they have to go through a re-onboarding process. Iā€™ve actually tried that approach, painful as it is, but doesnā€™t yield anything.

1 Like
1311

This week I have undertaken some further testing on creating and updating custom capabilities.
Here is what I have found.
My development process, steps 5 to 9 ALWAYS refreshes the Deviceā€™s UI in the ST APP within 60-120 seconds.
The trick is to ALWAYS CHANGE THE DASHBOARD STATE LABEL. (I.e. the ) in the Capability Presentation definition.

"dashboard": {
    "states": [
        {
            "label": "<CHANGE THIS TEXT> {{source.value}}"
        }
    ],

Hope this helps
Tim

2 Likes
1312

My previous notes assume you are maintaining the same Vid/PresentationId in the DTH, and just need to change the GUI of one of the custom capabilities that the DTH uses.

But what if you want to change the Vid/Presentation ID in the DTH. E.g. if you want to add a new or change one of the custom capabilities it uses.

I had 2 devices, each using its own DTH. Importantly, both DTHā€™s used the same Vid/Presentation ID ( and consequently they both used the same two capacities, one a custom capability).

I then created a new device (type) configuration which used a different custom capability.
I then changed the VID/Presentation ID in one of the DTH and save&published it.
The result was : The device using the changed DTH STILL USED THE OLD DEVICE (TYPE) CONFIGURATION! It is still linked to the old Vid/PresentationId.

I then created a new device using the changed DTH and it picked up the new Device (type) Configuration.

CONCLUSION OF MY FINDINGS SO FAR

  1. If you are able to keep the same Vid/presentation ID in the DTH. If you follow my development steps (and change the Dashboard States Label each time), the changes in Capability Presentations show up in the ST APP within 60-120 minutes.

  2. If you change the VID/Presentation ID in the DTH you MUST create a new device to pick up changes in the Device (type) Configuration.

Hope this helps
Tim

1 Like
1313

Way to go, @Tim99! Thank you for sharing your findings :smiley:

1314

Even after you first mentioned that here a week or so ago, I was doing exactly the same thing without any success whatsoever. Not only was it taking many hours for the device presentation to be updated with changes to capability presentations, regardless of what I tried, but it was then taking many hours for the Android app to pick up the device presentation, again regardless of what I tried. However I have just had cause to update a capability presentation and so repeated my tests.

I have just found that recreating a device presentation (i.e. st presentation:device-config:create with an unchanged config file) has indeed pulled in altered capability presentations. I only have a sample size of one to work on so far.

I have also just been able to make the Android app pick up the presentation change by clearing its cache. Again that was definitely not happening a week ago, indeed I canā€™t remember ever having had much luck with this.

So that looks promising. Two crippling caching problems seem like they may have been resolved. The solution for the capability presentation really isnā€™t a hardship, it just needs a line of documentation here and there to make it clear that ā€˜createā€™ also means ā€˜refreshā€™. Deleting the cache on the Android app is OK for the moment, but there needs to be a elegant way in the app itself.

What I havenā€™t had cause to examine is the issue of updates to the presentation ID in the DTH taking time to be reflected in devices.

1 Like
1315

This is another thing I examined a week or so ago with different conclusions. I found that if the presentation ID (vid) was being added to a DTH it would be available to devices using that DTH immediately. However changes to existing IDs were being cached and this applied to newly created devices as well as existing ones. The only way to get around the problem was to create a completely new copy of the DTH and use that. I even rewrote every single DTH I have so that it was possible to differentiate between different copies of the DTH in the device type lists.

2 Likes