Child devices in new app

I found out that ocfDeviceType only changes the icon on the main tile, but not the value. The main tile is preset by the vid, but I have not found a way to select the value for the main tile without using a preselected vid

I’ve tried all those tricks as well. I just updated my version of that DTH to add the vid “generic-switch-power-energy” and to remove ocfDeviceType: “”. That seemed to have worked for me, but I have no idea why…

@blake.arnold, my understanding is that, OneApp works with device plugins, some capabilities from the classic app has equivalent device plugins in OneApp, like Temperature measurement or Switch. If this is listed in the DH then the OneApp will pick it up and provide the plugin for it, and if the attributes and commands were followed then it can work in the OneApp without any issue. (I am not mentioning here some dependencies of capabilities like Switch and Health check.)
For device development there are some already made path with the device profiles and vendor ids. If a device profile has already been created and published then it can be reused by any DH if the corresponding vendor id (vid) is referenced in the metadata. If it referenced then the OneApp will follow the device plugin assigned to the vid and will disregard the selected capabilities when it displayed in the app. Ie. If a DH of a switch would have the vid generic-thermostat, then it will not display any Switch option in the OneApp, but temperature, operating state etc. (Just for example as misassigning capabilities related to the real functionality.)
@mark_cockcroft has made a list in the other topic of the thermostat related vids. I guess he looked into the DHs of the public repo and searched for vid and the connected capabilities. Device Handler update to support new STSC app
The only problem, that the current documentation is not containing all capabilities and, I haven’t found yet, there isn’t a list of vendor ids and connected capabilities. Some of us could reuse the already published vids, meanwhile others should have to create new device plugins to match functionality with the Classic app.
It is more frustrating that some of the documentation seems to be incorrect, or not working. I was in a search for a device profile/vid for a camera which does Image Capture. Indeed, I have Image Capture as capability in my DH, but it is not working in the OneApp and neither listed as a capability in the developer documentation, neither selectable in the Dev workspace, but it must exist as the Cloud-connected devices section of the documentation has a reference table to device handler types with c2c-camera-2 and c2c-doorbell-2. Although c2c-music-player-2 is in the reference list with Music Player and Audio Notification capacities, but Music Player is depreciated and Audio Notification is not documented. Anyhow, I couldn’t make my camera working with Image Capture in the OneApp yet (tried c2c-camera-2). I know that the Ring and Smartthings cameras are working in the OneApp and they have corresponding device plugins.
So, it would be really useful if the documentation could be updated to be a bit more complete and accurate. And it would be useful for all of us, if we could have a generic list of vids with connected capabilities what we could use in our DHs. I believe it would make our integration/transition to the OneApp easier. Later on then we can try to work on custom device plugins if the generic ones wouldn’t be good enough. That is a small step forward, but it would make it worth for the whole community.
Please correct me if I understand the things wrongly.

Thanks for the help!


1 Like

This is interesting reading. I’m not so far along in my understanding and haven’t experimented. The following has been exercising me this morning and I’d like to throw it into the mix:

The Vendor ID (vid) is part of a device profile and presumably it needs to be used in combination with an organisation ID (mnmn ?) to uniquely identify it. That would also suggest it could be considered to be ‘owned’ by the organisation that created it. If I create a device that does something similar to the Nadir Widget and reference ‘mnmn: nadir vid: nadir-widget-v1’ I would be a bit daft because Nadir might move the goalposts, but would there also be intellectual property issues? On similar lines, are the SmartThings Vendor IDs that have been used my many custom handlers really intended for general use in this way?

You are probably absolutely right. But as from my experience, the “generic” ones can be used with any mnmn. They are reused in different DHs in the public repo. If the Device Plugin fits, then it can used in other DHs. Makes sense to reduce the amount of work for anybody. There are DHs what were never public, like Ring doorbell or the Sonos integration, they probably have their own specific ones what you are referring to.
But honestly, it would be much more easier if some documentation would be released and people would not have to guess from the pieces what have been found recently in the public repo.
@blake.arnold @jody.albritton
The whole guessing game runs for a year at least and the documentation is still fragmented. I have even asked support to get the capabilities updated about 2 months ago, but still nothing.

@GSzabados, I 100% agree the documentation needs work as does the overall process for users to modify the way devices display in the new app. There is active work underway to improve that in a few different ways.

Part of the challenge that we face (particularly as a Product Manager) is providing this sort of flexibility while also providing reliability. The DTH and tile formats in Classic are really flexible and straightforward, but that also results in a lot of branched and fragmented DTHs, broken UI, etc. making it really difficult for us to support users when something goes wrong (especially when those users have only a vague understanding of what they’re pasting into the IDE!). We’re trying to address this problem holistically by providing functionality for community devs to customize and create using the platform, but also figuring out where highly desired features or solutions provided through custom DTHs and SmartApps could be natively integrated into the platform so everyone can easily use them.

As I mentioned, there’s ongoing work to shore up documentation and make this sort of DTH creation and customization easier to get started on and maintain. I’m sorry I can’t go into more details right now, but we are listening and actively working on this and will have something very shortly which I will make sure is socialized to the community.

Beyond explanations about VID, MNMN, and how capabilities interact with and render in the device plugin, are there additional topics that would be helpful to address?


@blake.arnold, I understand your problem regarding the support of the old app tiles. As my understanding was, that support was not even bothered to do anything related to custom DHs. What was quite bad, when you have ran into a genuine bug, which was of course not related to the DH but the system/firmware.

I love the idea in the new app. It gives far more possibilities, but I believe the development is more complicated as device plugins. I don’t know how will you be able to support that though, if custom ones will be made. Anyhow, we can see that the generic vids are working in our custom DHs, and the device plugins for these vids are under continuous development. But would be possible to publish a list of the generic vids with their capabilities? I have some Wiser TRVs what I have tried to make a custom DH (I am not a developer, just a hobbyist). It works now with one of the generic vids in the new app. It gives most of the functionality what I need there. I like the way how this generic vid is rendered in the new app. I don’t have a need for extra buttons or sliders or any lists. It fits into the generic setup. There are many custom DHs, what could be doing the same the generic devices plugins.
Many of us is still trying to keep away from the new app because the lack of support for some custom DHs. This could give push to many people to move forward. I think this guessing game is just causing frustration. As I wrote in one of my previous posts regarding the camera, the documentation refers to things what are cannot be really used. And the documentation missing things what are already in use.
All of us understands that continuous development brings these issues and documentation would not be updated immediately. The way how capabilities works and related device plugins and attributes would be good to know, together with some examples how to develope device plugins for custom features and attributes. (Like a boost function for a thermostat.) I think @prjct92eh2 has already asked about the main tiles and icons and values there. That would come useful too, especially for custom attributes. (Another thermostat example, heating or not heating and current temperature and aim point. I like to see both of them. But in the classic app it was no option to display multiple attributes on the main tile.)
I think myself, @RBoy and other people using the Generic Camera DH are looking forward for capabilities related to cameras, like Image Capture, Video Stream, etc. for integrating local network cameras. (We all know that some work has been done for this as the Smartthings Cam is supported and the Ring cameras too, and they render video stream “tiles” in the new app.) By the way, do we still call them tiles in the device plugins? :slight_smile:
So, a generic list would be a good start. Then we all can play with those for a while and redo the DHs to follow Smartthings standards, if not yet.

I think that is definitely the meat of the sandwich. In the past the lack of the information has at best promoted uncertainty as to which way things are going. We’ve now got to the stage where we’ve gone up a notch or two and the lack of information is more harmful. It sounds like you realise that and are on the case though.

Hand in hand with this is the broader issue of capabilities. As you will be aware, when we look up the documentation for capabilities we get one list in the Classic documentation and another list in the ‘new’ documentation which is substantially different and also differs in some of the individual details. Working in the developer workspace also seems to reflect a limited range of capabilities consistent with the documentation. The natural response is ‘how can this be?’. A lack of support for specific capabilities is one thing, denying their very existence is another.

It would also be useful to have some comment on the future of custom commands and attributes, many of which are used in official SmartThings device handlers. I could understand them being strongly deprecated but is there a pathway to their removal?

I also believe that there can be issues handling some C2C integrations in Classic SmartApps. A case in point is the TP-Link Kasa integration which as far as a Classic SmartApp is concerned doesn’t seem to have on() or off() commands for its switches, or something like that. If that is that the sort of thing that can happen going ahead, it would be useful to know how to address it.


Can we submit a list of some missing features being used by DTH’s? Many things can be repurposed, is that something you’re looking into well for capability driven UI’s? For example, a smoke sensor, we have locks which have fire/smoke detectors.

1 Like

Custom Capabilities are on the way and will address this particular issue. More details available after we launch them into the public.


is there any additional info available on either of these?

thank you.

1 Like

We’re reaching out to some users for initial feedback and closed beta and will have more info for the broader community shortly. Thanks for everyone’s patience on this.


One of the nicest things since the very beginning of Smartthings has been the open platform into which almost any device can be implemented and the groovy IDE. So far, it seems like the “new App” was a big step backwards.

I’ve used “smart” devices since from X10 the 90’s ( some of these still controlled with ST) to ESP32 based devices today as well as devices based on shared groovy DTH from the community.

I think that being able to design custom DTH easily is ST’s raison d’etre especially when comparing with other platforms.

I hope that you come fast with a way for the community to continue developing custom devices and support more 3rd party ones without all the constraints of the new app.

We agree. Openness is one of the core values of our platform and that’s not going away.

Groovy DTHs continue to be a perfectly acceptable solution for hub connected devices, with the obvious exception that the ‘tiles’ have always seemed to be an interesting but limited idea in completely the wrong place. The handlers are a bit ridiculous when they are (ab)used to support cloud based devices (though at the same time satisfying).

As for Groovy SmartApps, I don’t think history will be kind to them.

I can see where much of the ‘new’ environment is coming from (but not the lambda apps or whatever those things are, and the developer workspace is a bit weird). I still don’t understand why the new app even exists as anything but a device, as the UI really should be browser based. Making the mobile apps really decent presence / geofence sensors and notification and alarm devices seems a better thing for Android and iOS developers to be engaged with.

It just feels like the ‘classic’ environment had gone as far as it could down a dead end, the ‘new’ environment has headed off in the wrong direction and got lost, and what we are now seeing is an ‘even newer’ environment that is more confidently going the right way.

1 Like

Custom Capabilities, simple way to design the UI, good documentation and simple way to convert classic device handles (including child) to support the new platform will be very helpful.
VSC integration or an updated IDE will also be appreciated.

And a couple of months later… is a references to VID, MNMN and OCF dtype somewhere? Totally beginner here and reading forumpost for days trying to understand and unfortunately I’m starting this in the middle of transition from old app and new app. Only tried the new and managed to get my Philio 3-in-1 from an old Philio 4-in-1 device handler. A Heiman smoke detector works with Z-wave Basic Smoke alarm. But trying to fix some minor stuff like getting rid of Contact Sensor, no luck. And getting Checking status… . Trying all the VID, MNMN and ocfDeviceType and clearing out Contact sensor without success. Really like the initial experience here and no experience of old app so I really like the new one. But to find relevant documentation…

@Stiffboard, you can look here for vid reference. Unfortunately it is incomplete, but a fair starting point:

Ah, thanks, I’ve came across that one first few days, but couldn’t find it again…bookmarking. A lot of trial and error right now but my 3-in-1 sensor is finally ok, no more “Checking status…” and Sensor is gone and values updated correctly. Happy with that.

And tiles is not used…good to know, took some reading to find out. Would be nice to know what other sections aren’t used anymore for cleanup.

Good “Getting Started” with simple device handlers examples and instructions with examples on migrating from Groovy to the API will be greatly appreciated.

1 Like