Classic device handler migration to new smartthings platform

[jbisson (Jonathan Bisson)]

I can’t really seems to find a good post that explains how to migrate classic device handler to new app.

As far as I can tell, the tiles ie: tiles are gone in the new app. Is there any equivalent? I saw there is a notion of “plugin” but not sure the integration between the device handler and the plugin…?

In the classic app, we could send different events (which was found under the recently) tab - however, is this gone in new app? Is there any equivalent now?

Wish they had a migration document that explains all of that, both from a developer and/or users standpoint!

[johnconstantelo]

@jbisson

I can’t really seems to find a good post that explains how to migrate classic device handler to new app.

This will get you started, as well as tagged links at the bottom of the first post:

Custom Capability and CLI Developer Preview

Overview At SmartThings we want to provide tooling to allow developers to get their device integrations working in the SmartThings app. These changes will allow an integrator to move from using custom commands and attributes to custom capabilities. DTH Migration For Custom Capabilities In order to follow along with the example set forth in this guide, you will want to have the CLI set up, so make sure that you take this step first. You can download the CLI here from the releases tab and read more about it in the README. It is also recommended that you familiarize yourself with the concepts: Custom Capabilities Capability Presentations Walkthrough We are going to walk through a simple example of updating our Device Type Handler (DTH) so that devices installed with the DTH will be …

[orangebucket (Graham)]

@jbisson

As far as I can tell, the tiles ie: tiles are gone in the new app. Is there any equivalent? I saw there is a notion of “plugin” but not sure the integration between the device handler and the plugin…?

To cut a long story short, the UI in the new app is based on capabilities. All standard capabilities, and all community created custom capabilities, have a ‘presentation’ that describes how they should be presented in the UI in various contexts: the status of of a dashboard tile (the dashboard being an alternative name for the home screen in the mobile app); the action of the dashboard tile; whatever the extended area of the dashboard tile might be when it is at home; the details view (that’s the device page in the new app); automation conditions; and automation actions.

At a device handler level, it is possible to define which capabilities are displayed where and in what order, either by creating and/or specifying a device ‘presentation’ or leaving things to default to something sensible. I don’t know if a default device presentation file gets created or if the default stuff happens elsewhere.

The presentation is defined in pretty general terms. The dashboard status is text, the dashboard action is a broad type like ‘pushbutton’, and again the details view is something like ‘toggleSwitch’ or ‘list’.

The conversion of the presentation into what you see in the app is down to the ‘device plugin’. Newer device integrations can, if required, use custom plugins to do their own thing, but anything using the legacy Groovy DTHs is stuck with whatever the default plugin chooses to do.

You may feel my choice of ‘chooses to do’ is a little loaded. You are right. The default plugin seems perfectly happy to ignore the capability presentations for stock capabilities and/or implement completely new device types that are unknown to the API and completely outside developer/user control. It can be rather annoying.