Noob SmartThings developer… looking for clarity/direction

I’m an experienced developer who’s looking to create a few custom apps (and I think device handlers) for SmartThings. After looking at existing handlers & SmartApps that I’m using and reading through the ST dev docs, I’m a little confused and looking for some guidance. It seems, but I can’t figure out, is that Samsung recently introduced some changes to their platform that may have introduced new things and deprecated others… but I can’t tell if this is accurate or not.

I have two different scenarios: (1) connect directly to a local device (RaspberryPI) to monitor and control devices & sensors connected to it & (2) connect to a cloud hosted REST API to monitor & issue commands.

It appears the for both, I want to create device handlers and SmartApps… correct? Is there a special device handler API? Looking at some samples, I see some methods in the groovy file that I can’t find declared or referenced anywhere so I assume these are global methods part of an API.

Next question, how does a handler work with a SmartApp? I’m not groking what the SmartApp does. It seems like it is a way for me to create a “project” that contains settings that the handlers can use or walk the user through an auth process… but I can’t see how it’s connected/integrated/uses with the handlers.

Looking for someone who can help me connect the dots… thanks!

Device Handlers implement Standard “Capabilities”, like ‘Switch’, ‘Motion Sensor’, etc… Each of these “Capabilities” defines a set of Attributes and Commands specific to that capability. For example, a “Switch” must have an Attribute of ‘switch’ which may have one of two values - ‘on’ and ‘off’. A Switch must also implement two Commands - on() and off().

The job of a Device Handler (driver) is to connect a physical (or virtual) device to the SmartThings platform. For example, a DH that implements a Switch Capability, could be used to communicate to a Zigbee, Z-Wave, or LAN connected physical device.

Once devices are paired to the ST Platform, SmartApps are used to implement logic. For Example, the Smart Lighting SmartApp can be used to turn on a “Switch” device at a certain time of day, or based on an Event from a “Motion Sensor” device. SmartApps are the glue that tie devices together to make the home truly smart. They are the “Automation” in the Home Automation.

Some SmartApps also exist only to provide an integration between SmartThings and another platform. In turn, they often create Child Devices that can be used in whatever automations you desire. For example, the Logitech Harmony Hub integration ‘SmartApp’ is used to communicate between SmartThings and Logitech’s cloud servers. The Harmony platform centers around “Activities”, which are implemented within SmartThings as Child “Switch” devices. These switch devices can then be used in whatever automations you desire. Behind the scenes, changing the state of one of these switches results in the Parent SmartApp communicating to Logitech’s cloud server, which in turn talks to your Harmony Hub in your home to turn on the “Watch TV” Activity, for example.

I hope this helps at least a little…

As you have already noticed, SmartThings is in the midst of a transition to a new design. I am not very familiar with their new design, so most of what I am describing above pertains to me experience with the original SmartThings Groovy-based Platform.

3 Likes

It’s a really bad time to start developing handlers because a lot of the stuff in the documentation is going away and ST hasn’t provided any information on how to write handlers for the new app.

In the topic below they mentioned new metadata that replaces the tiles, custom capabilities, and having to refactor parent/child handlers, but haven’t provided any details.

They said they should be releasing the details within a few weeks/months, but they’ve been saying things like that for over a year…

They’re also trying to get users to stop using custom handlers and use the built in handlers instead.

1 Like

We have documentation on how to create cloud connected devices with our new developer tools

As well as how to migrate hub connected devices

We are working on a new way to handle custom capabilities so there is still a limitation there, but there will be a solution provided.

Only in the context that we have updated many of our stock handlers to have features that are equal to or greater than the custom DTHs from the community. Keep in mind that many of these custom DTHs are no longer even supported and haven’t been touched in years.

2 Likes

Thanks for pointing that out, my response was based entirely on hub connected devices and it shouldn’t have been based on the actual questions that the OP asked.

There’s also the unknown metadata and refactoring for multichannel and/or parent/child handlers, although I haven’t had any problem getting that to work in the new app and that’s also based on hub connected devices.

I don’t agree with that at all, at least not for z-wave devices because hardly any of the new handlers support configuration parameters and they often don’t include any of the complex features.

You’re right about that, but there are also some developers that are really active and write fully functional handlers for devices that ST doesn’t even support yet or the built-in handlers only provide the most basic functionality…

3 Likes

Hi, @swamplander

Complementing with Jody’s response, and regarding your second approach:

Will you be developing a third-party app to monitor devices from your ST account?

Greetings,
Erick.

I’m not sure how to answer that… let me explain more what I’m doing which might answer the question.

In two scenarios, there are existing services with REST API’s (Nexia & Tesla) that I’ll leverage. Yes, I know others have built solutions around these (that I’m currently using), but building another mousetrap will give me a better idea how this works being able to reference something else.

Not trying to replace or upstage other people’s work… just a way I like to learn. Yes, I’ll make these public for others to use as well.

1 Like

Great! Thank you for sharing.

For instance, Nexia, it is Cloud-Connected to SmartThings, and you can access their thermostats through the ST app. Documentation shared by Jody will issue this approach.

If then you want to do the inverse approach and be able to interact with devices at your SmartThings account through an outer app , check the OAuth Integrations documents.

Yes… a ton… thanks!

As you have already noticed, SmartThings is in the midst of a transition to a new design. I am not very familiar with their new design, so most of what I am describing above pertains to me experience with the original SmartThings Groovy-based Platform.

Can you suggest where I can learn more? Does the “new design” only work with the new & not classic app and/or will it only work with v3 hubs?

Actually I can’t, at least from the research I’ve done. All search results for Nexia + SmartThings pointed me to a custom device handler & SmartApp to see & interact with the thermostat in the Nexia system (it’s actually a Trane thermostat that utilizes Nexia). Without installing this handler & SmartApp, SmartThings couldn’t see the thermostat.

However, in my case, I have another sensor in Nexia that this particular SmartApp doesn’t see.

If then you want to do the inverse approach and be able to interact with devices at your SmartThings account through an outer app , check the OAuth Integrations documents.

This approach would be a custom service that reaches INTO SmartThings, correct?

Totally agree, this is also what I was talking:
image

As you mention, SmartThings needs for that Handler that serves as a proxy with the device. There has been a discussion on whats a DTH this days due to the differences with the Classic app and the New app. I’ll dig in to find those threads.


It that sensor the one you’ll be integrating?


Regarding your last question, it is a custom service for the fact that it is a personal/outer/independent web or mobile-based app controlling or monitoring the devices added on a SmartThings Account.

The version of ST hub does not matter as long as we’re talking about the v2 and v3 hubs. Avoid the ADT - ST hub as its days appear to be very numbered… The original v1 hub does not support any local processing.

As for the New App vs Classic, I am really not familiar at all with the New App. Most of my focus these days is on writing drivers for Hubitat for custom Arduino boards using my ST_Anything/HubDuino project.

Where is that screenshot coming from?

The goal of my SmartApp will be to show two things: thermostat & sensor. The latter is a climate sensor that shows temp/humidity in another room. The existing Nexia SmartApp I found only shows the former.

Hi, @swamplander

The screenshot was from the SmartThings brands catalog, and accessing to Nexia’s available integrations.

I’d recommend you to stick with the new documentation. Here some topics that we’ve talked about:

And another thing about the DTHs and the new platform. Now that integrations are intended to be self-hosted, the app that initially runs the integration becomes the handler itself. Now the profiles or dth are merely UI metadata of the device.

1 Like

The page you referred to states that you must be “enrolled as an organization member in Developer Workspace” in order to create hub-connected devices. What does that mean? Can a regular user still self-publish a custom device handler?

Also, is says that only “ZigBee and Z-Wave devices are currently supported.” What about HTTP (Wi-Fi/Ethernet) devices? Are they still supported via HubAction?

Thanks.

This is helping quite a bit… thanks!

Making sure I understanding this…

  • if I have an existing service (hosted, cloud service such as Nexia, Tesla, or a weather service), I’d create a cloud-connected SmartApp
  • if I was to create a new thing, like a RaspberryPI with connected sensors, it could either be a hub-connected implementation OR I could create my own hosted service & have the RaspberryPI communicate with that service & then use the cloud-connected Smart App

Correct?

The latter scenario is one I’m working on - creating a controller / monitor for an aquarium with water temp, flow & level sensors, valves, etc. Instead of creating my own UX, makes more sense to expose everything to SmartThings to leverage the existing platform, automations, etc.

1 Like

Hi, @swamplander

It is correct. I’ll share with you a connector tool that eases the integration of your cloud and the SmartThings cloud:

Hello, @geko

Regarding your first question, yes, it is correct, you must enroll your account to an organization to create Hub-Connected integrations. To enroll your organization or to enroll in an existing organization please Click Here. When you finish the registration process, please login back to refresh your organization’s status. You can observe the changes created by this process at MyPage.

About your second question, please take a look at the Direct-Connected Integrations for more information.

© 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.