SmartThings Community

Example using new SmartThings Cloud API!


(Jim Anderson) #21

Can you try using an incognito (in Chrome) window? I think that will fix it. I’ll pass this on to the engineers to make sure the issue gets looked at so that’s not necessary.

Thanks!


(Sno Wake) #23

Boy do I feel foolish - but I’m definitely missing something obvious.

I’ve generated my Personal Access Token - and am ready to start exploring the API - and following the documentation from the link above, quickly find myself at a dead-end:

https://smartthings.developer.samsung.com/develop/workspace/sdk/installation.html

I’ve completed all the pre-requisite steps - but when it comes time to “Download the SDK” - the step indicates that I “Go to the Developer Workspace (Coming Soon) and then download”. HUH? I’ve searched and browsed and tried every attempt to find / access the Developer Workspace, so that I can download the SDK - but clicking the “Workspace” link in the top banner, which directs here:

https://smartthings.developer.samsung.com/workspace

Takes me to a page that says “coming soon”. I enter my email address - and then receive a link prompting me to ‘login’ - except - I can’t figure out how to login at the link provided??

Is the workflow such that I need to ‘create an organization’ before I can register?

Thanks in advance for any insight / guidance. Really eager to get my hands on the SDK and new API.

Cheers!


(Sno Wake) #24

BTW: I have been able to install the sthelper CLI, claim a Personal Access Token or two, and am having great fun exercising the API via Postman… but still curious if I’m somehow missing a step required to get my hands on the SDK?

Thanks again for this outstanding development!!


(Jody) #25

Some features like the SDK and developer workspace are still under heavy development. Betas should be coming soon.


(Bill) #26

I have a couple questions of questions about the new API…

#1 - Is it possible to get the status of multiple devices with 1 web request?

I’m looking over the documentation & I see that the “/devices” endpoint does not return state information. So it appears the only option is “/devices/{deviceId}/status” which doesn’t accept multiple device IDs.

#2 - Is it possible to subscribe to device state changes so polling isn’t necessary?

Other APIs I’ve worked with have used Server-Sent Events so clients don’t have to constantly poll their servers. I was looking over the “/devices/{deviceId}/events” endpoint & thought that might be something similar to SSE.


(Jody) #27

It’s possible via your own lambda or webhook smartapp

https://smartthings.developer.samsung.com/develop/guides/smartapps/webhook-apps.html


(Bill) #28

Thanks @jody.albritton, Any chance you know if that feature might make it into the REST API?

I was really hoping to get away from using a custom SmartApp. My SmartApp has actually been stuck in the pending approval stage for over 2 years.


(Jody) #29

Which feature?

If you are talking about subscriptions, they are already in the API. You still need a lamda or webhook smartapp that details the endpoints to post to and your endpoint needs to verify the http signature as detailed in the docs I linked.


(Bill) #30

Yeah, sorry about that, I was referring to subscriptions.

Let me rephrase my question. Any chance, in a future version, event subscriptions can be set up without a custom SmartApp?

I just really want to avoid the situation that I have to wait 2+ years to get a SmartApp approved.

Yesterday I tested the “/devices” endpoints & they worked pretty well. That could really simplify the process for users to control their SmartThings devices from the Home Remote app. Right now I’ve got a rather lengthy process that’s prone to errors. If the only thing users had to do was generate a token, that wouldn’t be so bad.

Wink uses PubNub & Insteon uses SSE for their event subscriptions. Both are super easy to use & very efficient. Within a second or 2 device status changes are received. Those services are built right into their REST API. They don’t require a custom SmartApp to consume. I guess I was really hoping you may have, or can add, a similar solution to your API.

https://winkapiv2.docs.apiary.io/#reference/subscriptions

https://insteon.docs.apiary.io/#reference/houses/house-device-activation-stream/retrieve-a-house-device-activation-stream


Schedules in new API
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #31
  1. What’s the difference, here, between a Lamba and a “webhook smartapp”?

  2. May I also ask what’s the difference between the current definition and meaning of “SmartApp” and “webhook smartapp”? Or are they the same thing? What about publication & update process?

  3. Ref #2… if there is a major difference, why not call the new “smartapp” concept something else entirely, please?


(Jody) #32

@billv @tgauchat a lot of this stuff is still new to me too :slight_smile: so forgive me if I get something wrong. @Jim might swoop in and correct me.

I am working through the new webhook smartapp flow myself and here is my current understanding of the flow.

  1. I am going to build my webhook smartapp in the framework of my choice.
  2. I will use the REST API for SmartThings to create a new SmartApp
  3. Via MY framework interface I will be able to install the SmartApp to my location using the REST API
  4. I will be able to configure the SmartApp settings in the mobile app
  5. In my example I am collecting temperature data so I will need an access token that has read permissions for all devices.
  6. Subscriptions will be created for all temp sensors at the selected location
  7. On any new temperature event the webhook url will be called
  8. My framework will handle the event and do whatever backend processing I wish

So a couple of things are dramatically different here. You will no longer need to go to the IDE to install a SmartApp. A user could just log into your website and install it by authenticating with their own SmartThings credentials. This would obviate the need for publishing altogether. Do note that you would be subject to rate limits and currently for your own purposes you can use the Personal Access Token. In the future you would need to obtain an ID and SECRET that allows others to install your SmartApp and the publication process will be completely different and mostly regulated by rate limits given that code is running on lamda or your own server.


(Jody) #33

Lambda Functions on AWS are a serverless architecture where you code is only executed as needed and a Webhook SmartApp would be where your code is hosted on your own server making and accepting calls to SmartThings.


(Jody) #34

I don’t know the answer to this question but it’s still technically a SmartApp, you are just installing and configuring it via API rather than the IDE and rather than the life cycle events being handled by groovy code they are being handled by lamda or your web app.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #36

Thanks for the answer, but unfortunately being “technically a SmartApp” really depends entirely on what the exact definition of “SmartApp” is! :wink:

You do give some helpful examples of what’s different (e.g., not using the IDE and Groovy…), but to us though are currently fundamental characteristics of a “SmartApp”.

It’s like saying that… Orange juice is “technically an orange”. Not true… OJ is a substantially different derivative or variation of the same fruit.

Perhaps to SmartThings, a SmartApp has always been “orange juice” and the IDE/Groovy/Publication, etc. is all just pulp, and zest, and peel… But:

  1. Juice looks nothing like an orange
    And
  2. The peel and pulp are substantially valuable features. ie, it’s non-trivial to SmartApp developers to lose the IDE, the integrated language of Groovy, and… most significantly, the logic execution environment provide by the current SmartThings Cloud!

Of course, though, having juice offers more flexibility than an orange. Juice can be put in a glass or carton or soda fountain. So the new “SmartApp” has plenty of super advantages. I just think that the disadvantages are being downplayed…


Sorry for the crazy analogy, but am I capturing the gist with any accuracy?


Schedules in new API
(Jody) #37

This is a gross oversimplification but I will try my best.

An old school SmartApp was a database entry that referenced some groovy code hosted on the smartthings servers.

New SmartApp is a database entry that references some code hosted on external servers.

They both share some common characteristics like needing authorization from the user and a set of life cycle events.

Installed
Configured
Updated
Etc

The difference between the old and the new is primarily where the code is being executed.


Schedules in new API
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #38

OK… makes sense: I just wish they had different names over the transition period!

SmartThings “hosted” old school SmartApp logic execution & processing, at no charge.

For new ones on external servers, developers have to pay that external hosting / processing cost…


(John C) #39

That would also make a clear delineation between the ST/user responsiblity; even more of “you’re on your own!” Makes sense from a Support cost-containment basis (and some VP probably gets a big bonus for that).

Most folks don’t have their own servers, either. This could be interpreted as a move away from an open platform towards a more closed/controlled environment.

Pure speculation, of course, since we have no visibility to the ST roadmap…


(Steve White) #40

You’re probably right, although SmartThings has said that Groovy apps will continue to be supported, although there not stating any timeframe. AWS Lambda also has a fairly reasonable free tier that should be able to host a several SmartApps for the average user. The problem is that it’s not user friendly to set up, install, or manage.

The SmartApp model will be changing, I think thats the one thing we can count on.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #41

I can’t say I’ve reached that conclusion, though I guess one way to get perspective is to compare it to another platform such as Wink.

  • How would folks rank Wink on a scale of 1 to 10 for “openness”. Compare that to current SmartThings? Compare that to “new” SmartThings.

  • So far, it seems that “new” SmartThings API only affects SmartApps, not DTHs. Is it possible at all, in Wink, to write / install a “custom DTH”? That alone keeps SmartThings more open than Wink.

My gut analysis says that SmartThings is getting more open, not less; except that it’s an open door to a somewhat different part of the building. Some folks are going to be much more comfortable with this new interface (door); others, won’t have a clue or will need more assistance.

Moving away from the ability to “cut and paste” SmartApp code (and the GitHub integration) is a loss to a segment of SmartThings users while attracting a different segment. This latter segment is for projects (open source, donationware, and commercial) who can now provide a much friendlier setup to customers without waiting for a formal review and publication of an “old style” SmartApp. That is a good thing.


(Jeff Beck) #42

From another thread @tgauchat

There’s a particular line of questioning there, for example, as to whether or not the new API supports a possible “serverless” infrastructure (pub-sub, or use of PubNub, SSE, or ?). @billv has interfaced with Wink and dozens of other smart products, so he can express the question more clearly than I can.

Perhaps jump over to that Topic and toss in a few cents, unless you’ve got nothing new to add?

So using serverless infrastructure is I think better supported via using subscriptions and a lambda setup then SSE.

In our case a SmartApp is the holder for all the integration details.

The other subscription models do require code to consume their events, the main difference with what you are looking at is the focus on a SmartApp that is installed for a user and goes through configuration. Yes there is more custom code to deal with install but that means the install of a SmartApp starts inside the ST app instead of from an external flow.

So there is a need for something like SSE for realtime updates into a given place that makes sense for a UI focused app. The APIs that are exposed in the preview right now focus on delivering functionality that could back automation style apps and hopefully drive people to try things and request new APIs.

#1 - Is it possible to get the status of multiple devices with 1 web request?

Not today, thinking through what the usecase for this would be good. Ideally we don’t want you to poll for state. So understanding what the use pattern is for this and if we are just trying to save rest calls vs spreading the calls out over the system.

The point of the preview is for everyone to try it and provide feedback. (There should be links on the new docs site. Somewhere…) So if there are things you really need or oddness that blocks your usecase let us know. And remember this is a preview of the APIs we are not saying they are a complete offering yet.