SmartThings Community

Querying modes in webhook smartapp API

(Chetstone) #1

OK I’ve got my example color weather light smartapp working, but I’d like to disable it in certain Modes (e.g. Away, Night, etc.). I haven’t found any way to subscribe to or poll the current mode of the hub in the new API. Am I missing something? Also, is there a way to send Notifications to the App?

(Jim Anderson) #2

You’re not missing anything - the APIs to work with modes are not public at this time. I’ll pass this on again to our product team, but it would be good if you also open a developer support ticket so it can be tracked.

(Chetstone) #3

Oh, so the new API is an incomplete Beta? I don’t remember seeing any mention of the word Beta in the documentation for the new API. It’s also not mentioned on the banner at the top of the “Classic” developer documentation. That says:

See the new Developer Portal for the current features, APIs, tools, and processes for working with SmartThings. To publish your device with SmartThings, see these guidelines.

When I first saw this banner, I clicked on it, thinking maybe the look and feel and some enhancements to the groovy interface were being introduced. Yes the look and feel of the site was totally different, but I was not prepared for the content to be so radically different. I was completely baffled, couldn’t find anything familiar, like I’d stepped into an alternate universe that had a completely different SmartThings. Case in point:

  • The SmartApp can either be an AWS Lambda function, or a WebHook endpoint with a RESTful API interface.

WTF? I thought a SmartApp was two things:

  1. Something you install on the SmartThings app to automate or integrate your “Things”
  2. Groovy code running in the SmartThings cloud to implement the above.

The new API docs make no mention of either of these. There’s no context for someone who has done a modicum of SmartApp development in the past. I looked around for a blog post that would explain the rationale and background for this change, couldn’t find anything and finally reading this forum I was able to start figuring it out, especially thanks to posts by @tgauchat.

Based on my experience getting the example weather color app going, I have to agree with the folks who complain about the new API being unfriendly to hobbyists who want to cook up something simple for personal use. For myself, I am proficient in JavaScript, I happen to have a VPS I can host a webhook on, and it wasn’t a whole lot of trouble to add a virtual host to nginx and get some certs from LetsEncrypt, so it was all a bit of fun for an old retired guy with plenty of time on his hands. But let’s face it, all that stuff is a huge bar to get started. Not to mention that a similar groovy app (with more functionality) is 379 lines of code in one file, while the new API Example is over 7000 LOC in over a dozen files.

So I hope the groovy stuff is not going away. But it sure feels like it’s headed that way. I would urge SmartThings to continue to support and maintain it and revise the documentation for both groovy and new platforms to treat it as a first-class citizen. The current documentation reads like they’re trying to pretend the Groovy stuff never existed. That’s not good.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #4

The key word here, @chetstone, is (or, more accurately, sooner than later…) WAS.

“Samsung SmartThings, a division of Samsung” is no longer “SmartThings: An independent subsidiary Company acquired by Samsung”. I’m not sure exactly when the merger took place, but I guess around 1Q 2018, when original SmartThings CEO Alex Hawkinson “resigned”.

SmartApps are now called “Automations”, though the term SmartApp is still used in the new API it is, as you’ve surmised, a rather different beast.

Oh you can rest assured - the Groovy API is deprecated and most certainly going away. I can’t predict exactly when, nor if Samsung may decide to implement a “development toolkit for dummies” to help retain the current perceived ease-of-use of the legacy platform. But they have very little incentive to do so.

I estimate that fewer than 1% of all SmartThings Customers have ever logged into the IDE - Let alone actually done anything with Groovy Code.

(Chetstone) #5

Ah thanks @tgauchat for bringing a little clarity and perspective once again. It’s sad when a good thing goes away. Fortunately or unfortunately Alex did the right thing in using Zigbee and ZWave for this stuff. I don’t know why the rest of the industry is using Bluetooth and WiFi. It doesn’t make sense.

When I first heard last spring that I was going to be forced to get a Samsung login to continue using SmartThings, I decided to find alternatives. I was willing to throw away my “things” if necessary and my smartapps, if I could find something that was workable. I settled on Homekit for various reasons and got a couple of WiFi devices to try it out. After fighting for hours including time on the phone with support to try get them connected to my network I gave up, thinking, well I don’t have any privacy anyway I’ll have to stick with SmartThings.

Too bad Alex decided to sell. Good for him, I guess he got a ton of money but bad for the rest of us.

I estimate that fewer than 1% of all SmartThings Customers have ever logged into the IDE - Let alone actually done anything with Groovy Code.

That’s still many many thousands of people.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #6

It definitely was entirely his decision. Despite a successful Kickstarter, you a company like SmartThings can’t thrive on only $1 million - it took another $17 million to keep going and that was likely running low when Samsung offered $200 million. Most of that goes to the folks who, you guessed it, provided the $17 million. The vast majority of tech startup success stories start with a great idea, team, and hard work but soon become just another gamble by the millionaires and billionaires who own venture capital firms. The best product doesn’t define the winner: The most lucrative company buyout does.

Just how many customers do you think SmartThings has?

And I said fewer than 1% even logged into the IDE (even once).

So frankly, let’s say 0.1% actually do anything with Groovy. It doesn’t matter if that’s thousands of Customers - Only the overall market size is important. No company is going to invest disproportionately in 1% of its customers. It’s actually inevitable and excellent business strategy to cut them loose.

(JIm) #7

I agree with what @tgauchat says about some of us being just a small part of ST and therefore not of much importance. I don’t like it, but that’s the nature of the business.

But I also agree with @chetstone. For people like myself, old retired f–t, who has a limited knowledge of today’s programming. ( I used to be a programmer back in the old C days). I was able to grasp the groovy stuff pretty easily, but the new API has me totally baffled. I couldn’t even get the example working.

I changed from a previous system to ST because of the ability to customize it the way I wanted. I have a few small smart apps of my own cause there was no easy way to do what I wanted. Webcore was ok, but too hard to modify if I wanted to change something. With a smartapp I just open the phone app and change a contact or sensor as needed. I tried changing my stuff to either routines or the new app automations, but just couldn’t get the same level of functionality.

So if, or rather when, groovy stuff goes bye-bye I’ll either have to make do with less functionality or find something else. If they would somehow comeup with a simple template to fill in the blanks on the new api, similiar to the groovy one, it would be nice.

Just my 2 cents worth.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #8

There’s some confidence that WebCoRE will survive the transition. It’s a great alternative to direct Groovy programming for automations with more functionality.

(JIm) #9

I also believe that WebCore will probably survive. I used it for awhile, but it just wasn’t fitting my situation. I had problems with it not always executing correctly. The biggest drawback was having to use a computer to change something. I find myself many times wanting to tweak a timer setting or change what sensor does what. Using my own smartapps I can just open my phone and change it. Maybe that’s unique to me, but that is the way I use my system.

I hope Actiontiles survives the transition ok.

(Chetstone) #10

@tgauchat Thanks for the history briefing. So Groovy’s going away. As one who is not afraid of change, I guess the upside of this transition is that it should make it easier for developers to publish and sell their smartapps at scale. Is there any information on how and/or when this would work? The link I quoted at the start of this thread that appears on the classic developer banner:

To publish your device with SmartThings, see these guidelines.

is broken. Anyway, that’s for devices, not automations.

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #11

All the available information is on the new developer’s website.


(Chetstone) #12

Thanks but that page only refers to distributing devices, not publishing automations, unless I’m missing something

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #13

Pardon my bluntness, but I presume that you can search the rest of the online documentation as well as anybody else can. That’s why I just gave you a starting point.

If you don’t find what you’re hoping for - then it doesn’t exist. (Hint: It probably doesn’t exist.).