There’s a lot to learn in the Smartthings Developer Portal. My need is to write routines for my own house, so I am not a vendor or manufacturer. But I am a programmer and instead of dealing with a small app I’d much rather write code. My needs are pretty simple which is turning lights on and off based on time, sunrise, sunset, presence and so on.
Given that I don’t want to use the App and given that I do want to write code (in any language) and given that I am on a mac, what tool and approach should I use?
Can I suggest instead that you first take a look at Webcore? It’s essentially a scripting language for SmartThings, and will probably give you everything you’re looking for (including a web interface and global variables). They even have their own forum. There are lots of sample scripts there (which webcore calls “Pistons,”) so take a look and see if it meets your needs.
I couldn’t agree more. With webCoRE, you are essentially writing your own rules but with a lot less work. Yeah, I could write up some DOS commands and make Windows do stuff but the Smart folk over at Microsoft has already took all of the code and put it in a nice Graphical User Interface and all of the scripting language is done behind the scenes.
YMMV but IMHO, webCoRE is as simple or complex as you need it to be.
Thanks everyone, but the instructions are quite complicated and didn’t work. I couldn’t get this part to work. My iOS SmartThings app does not seem to have anything called marketplace.
Yes I think you’re right. I don’t have a marketplace icon, just dashboard, devices and automation. And I did mess around with the custom automations. It didn’t seem like it went far enough. And anyway my initial motivation is to be able to d scribe automations programmatically. What about the idea of using the cli to write shell scripts?
Definitely try the classic app if you want to write your own code (not in the app itself, just that you’ll have a better time trying to make use of your code).
One important note: if you go the programming route (either native Groovy SmartApps or WebCoRE), all of your automations will by definition be Cloud Based, and therefor subject to the requirement for constant Internet connectivity to your hub/location.
On the other hand, if you use the native automations in the “new” app, OR the ST-provided SmartApps in the SmartThings “Classic” app, many/most of your routines will run entirely within the hub.
Pretty much everything you describe has already been programmed (by SmartThings) and will run ‘local’ - Smart Lighting handles your lights (based on time/sun/motion/contacts open/close, etc), and Routines handle a comprehensive suite of changes based on presence, time, modes, etc.
FWIW, many of us here are programmers also - we just avoid rewriting code that’s already been done by someone else - focusing instead on those things nobody has yet provided.
Hence you can find a plethora of “cool” things for SmartThings, like Ecobee/Nest thermostat integration, Chamberlain garage door openers, Ask Alexa, Echo Speaks, Homekit bridges, WebCore, ActionTiles ad infinitum. Yes, all depend upon the SmartThings “Classic” app infrastructure, but collectively they make SmartThings far, far more powerful than the simplistic world created by the new Samsung SmartThings app…
So the classic app is still supported? Odd that ST took functionality out. I guess to make it easier for beginners. Is there any downside to classic, or do people run both?
Classic App is definitely still supported, and there’s no real end in sight unless SmartThings decides to abandon users with no alternative for the plethora of 3rd party add-ons and integrations (could happen, but we bet not).
Most of us “run both,” but find little reason to use the new one unless we need Samsung Control for Samsung Appliances (which isn’t as robust under the “old”). There’s just so much more that you can do with Old vs. New…
Their mobile app and the web-based IDE have made for a confusing mix of device control and hub administration.
The classic app is still supported, but at some point it will probably be deprecated entirely.
No one knows for sure why they released the new app even though it essentially was unfinished. It may have been rushed so that other Samsung product lines could be folded into the same mobile app.
The “new” platform won’t support most 3rd party device handlers, because they enable only a fixed set of attributes.
Want to know or control what stage your heat pump is running? Need to change your humidity setpoint based on outside temperature? Interested in getting weather data from your own Personal Weather Station instead of the homogenized/limited data available from Weather Underground (which no longer sends you your own PWS data, even if you request it). Interested in using Air Quality and Wind Direction to control your air intakes?
NONE of the above automations are possible in the New environment, and most won’t ever be because SmartThings has decided to significantly restrict the Name and Number of attributes a device can offer. If/when they DO kill off Classic, most of us “advanced users” will have no choice but to move to Hubitat - which by then is hopefully mature enough to handle the advanced add-ons that so many of us use.
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
19
Not exactly true.
SmartThings repeatedly asserted at the Samsung Developer Conference that they will have a “streamlined” process for requesting and implementing official new Capabilities (i.e., sets of Commands and Attributes).
For example:
You can (or will be able to…) request that SmartThings implement Capability “Heat Pump Stage”.
Is the above “Capability Request Process” red-tape highly unlikely to be handled in an efficient manner in the real world. Ummm… yup!
Well, FWIW, my Ecobee Suite defines more than 40 thermostat-related attributes and 20 commands;; SmartThings “new” supports less than a dozen of each. My weather station has more than 30 attributes, ST supports only 8.
Pretty sure they aren’t going to support anything close to those numbers, even with their request process. And I note that they originally said that they would have a process to add new attributes, which they never actually provided. Their track record is definitively “Least Common Subset,” not “a Superset of all devices”.
I don’t argue that the approach is without merit (even ActionTiles has a similar limitation against displaying extended/non-standard attributes or supporting custom commands). Without such support for 3rd-party defined commands and attributes, innovations like WebCoRE and Echo Speaks wouldn’t/Couldn’t happen.
Reminds me of a saying: possession is 9/10ths of the law. With Classic, we already possess the ability to provide extensions, without the requirement for any red tape. AND both the current Groovy model and WebCoRE both can immediately take advantage of those extensions…again, with no red tape.
I mean seriously, what is the likelihood that Samsung is going to approve new attributes that only one thermostat device, weather station API, or door lock supports (shout out to @RBoy and @tonesto7 and others for significantly extending these devices beyond the limitations of SmartThings, and for doing so years ago!)
