Moving your device from SmartThings Classic?
Learn more about Device Plugins and how to arrange UI Metadata in the SmartThings app using the VID Selector.
-I guess there will be an official announcement too, but here you go, to quickly share it from the SmartThings Developer Newsletter.
Very cool! Makes for a good start.Now for some light reading on the Readme…
Yay, finally
Well, not as cool as I thought. We seemed to have already guessed most of this.
For example, I know that generic-switch-power-energy shows signal strength, but checking the signal strength checkbox shows no meta data found.
Guess it’s still a wip.
Now that we’ve been given an inch, can we take a mile? 
I’d still like to see the following as we work towards the new app supporting custom capabilities:
ocfDeviceType metadata and quick explanation of what it influences (only icon?).VID and ocfDeviceType in a Groovy DTH@DavinD, could you please follow Jody’s advice and report it as a feedback?
Already sent
Thanks!
My 10 cents, none of the thermostat related vids are listed there, no Heating or Cooling Setpoint.
@jody.albritton - I’ve sent an email. 
Interesting. I thought ‘vid’ stood for ‘Vendor ID’, as in the device profile. Certainly I was able to customise the display of a custom DTH (including what displays in the dashboard) by using my own device profile and using my ‘mnid’ with ‘vid’ as my vendor ID from the profile.
What I couldn’t work out how to do is use a device profile from my organisation, even though it is readable.
Good to see things moving forward.
I’m not really sure why they even use VID. They have the capability in the DTH, just use it. If a device has a capability, display it.
In the new app, i’d wager there are more devices that don’t use Groovy than ones that do. So it would appear the Groovy way of defining and displaying capailities is not the path forward
That is what they do in the absence of a VID, and look at the number of comments they get about things not being in the right order, or the new app dashboard widget things having the ‘wrong’ capabilities for the status message or action button.
@jody.albritton - thanks for this start in a step towards adapting groovy-based custom DTHs to better work with presenting devices in the new mobile app.
I am wondering how the heck to make sense of the VID metadata examples. They appear too have been auto-generated, I think? There are multiple languages so I’m not sure how I would “hand code” that into any custom groovy-based DTHs.
That’s what i meant by:
I think all you have to do is include it in the DTH metadata like:
definition (name: "Z-Wave Basic Window Shade", namespace: "smartthings", author: "SmartThings", ocfDeviceType: "oic.d.blind", mnmn: "SmartThings", vid: "generic-stateless-curtain")
It’s a little more complicated than that. The new app uses UI Metadata (basically a super complicated JSON file) to define how things should be displayed in the device details pages. If there’s no VID, it defaults to a generic UI Metadata which pulls in whatever capabilities are listed but displays them in a static order. The VID allows the app to draw in more specific UI metadata which renders the capabilities in a much more specific format. Jimmy’s right in that this way of rendering allows significantly more flexibility in what devices can be added to and displayed in the app.
As I mentioned in past posts, this is intended as a temporary solution. We’re aiming to provide more full-featured control over creating custom capabilities and also specifying how those capabilities render in the future as a long-term solution.
This is what I was referring to in a previous post on the big migration thread. UI Metadata is very complicated right now in its current format. The long term solution for this functionality is designed to make it much easier for users. I would hold off going too deep into learning about the metadata, frankly.
Can we get a quick comment on how to successfully get changes made to the meta data to show in the new app? Our speculation is it’s changing the device type to something else and then back again, with maybe a force stop of the app thrown in?
This makes it difficult to test any changes we make.
@blake.arnold, I’ve sent an email (two) to the address mentioned by @jody.albritton.
Long story short, there are some missing VIDs in the selector and the Capabilities on the Developer page has missing capabilities compared to the list of the selector. So it is mismatching vice-versa.
It would be really good if you could provide some details regarding what @Automated_House asked, it would be useful. (ocfDeviceType and VID together and maybe the way to change displayed value on the tile.)
The question above from @DavinD is valid too. Could you provide some basic instructions how a DH can be updated/tweaked and force the new app to pick up those changes? If it comes with the new release, then it is all good, but so far I cannot see any clear way to force the app to download the add-on pluggin/UX for a changed DH. Indeed, I can see for my testing done mixed up metadata with multiple incorrect capability displays.
Last thing, I don’t know has it been mentioned in the other thread, but the combined Temperature and Humidity graph UX is a fail at the moment. The new Temperature one is working well, but the one with both capabilities is not working. It is not displaying any historical graph. I guess that is already on the bug list, but just here to mention.
Will talk with the device architecture guys today about the right way to get a DTH to refresh. I’ve done it myself before but want to get you an official answer of the proper way to do it.
Looking at the combined temp/humidity graph on an Aeotec 5 multisensor I’m seeing history for both show up, but I agree it’s still really confusing (particularly the minute-level graph).
(And yes, that’s a measurement from my backyard… this was a “warm” day here in Minnesota.)
Other than not showing a dual-measurement graph (I hate dual axis graphs, personally), what would be helpful - a legend at the bottom? Annotation for “temp” and “humidity” on the graph itself? Most recent value annotated for each? Would like ppl’s thoughts to bring this back to the UX team. Thanks.