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.


© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.