Child devices in new app

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