@JDRoberts @orangebucket legends! Thank you!
If only some of this was in the docs and guides. The “available capabilities” one is a classic i searched for over a good 45mins and found multiple users asking the same; most replied linked to legacy lists and/or sites with collections of outdated data. @erickv eventually gave me the information in a support DM.
All the documentation needs is an edit to say something like “Each manufacturer includes different capabilities within their products. To find out which capabilities your target device supports, make an authenticated GET call to to /devices/{device_id} within the SmartThings REST API. If you list too many or include capabilities the device does not have, it will not show up in your configuration request.”. Hopefully others will be able to find the info in this thread in the future: i spent far too long trying to find the appropriate capability string for a device which has a vibration sensor (quote, from Samjin Multisensor sold in Best Buy) and not finding it anywhere as a listed ST API capability.
Not to say that any of these things are insurmountable, but they make it an unnecessarily frustrating and confusing endeavour.
I find it frustrating that the primary UI to SmartThings isn’t web based.
I totally agree with this. SmartApps are predominantly talking to a webhook backend through the entire process and performing the same “advanced” OAuth flow you’d find reminiscent of most modern web apps. Designing one in a web UI would make it far simpler. It makes absolutely no sense to me to install an “app” inside an “app” - it more like a “plugin” or “external connector module” which doesn’t’ have the flexibility of one API talking to another (and a webhook is really a POST/PUT call to your API).
That app will either be acting as a connector to present your devices to SmartThings in a standard fashion, or it will be an automation that is interacting with SmartThings devices wherever they may be.
See, that terminology - “connector” makes it far simpler to conceptualise. An “automation” could easily be called a “reactor” or “responder”, and a “schedule” a “scheduled task” (a schedule is a calendar list of appointments, an action taken at a specific time is a task - in fact, “action” is even easier to think about).
I guess if a user revokes permissions you might just have to find out the hard way by attempting to use them. That would be fairly typical wouldn’t it?
Not necessarily. You’d check for a 401 response and never assume a 200, but GRANT and/or REVOKE lifecycle stages would be useful, if, say, a device is removed, faulty, or somehow should have conditional access (e.g. door lock - security breach, temporary codes etc).
How do you mean where do you get the Capabilities from? Do you mean how do you know what they are? They are listed in the documentation (somewhere …).
See above - the docs don’t have it anywhere.
it is the integrated development environment for developing devices handlers and apps in the Groovy language.
It’s a web-based console for storing functions and routines really: an IDE has a very specific meaning (think Eclipse or JetBrains stuff) and could really do with a sandbox featuring “dummy” devices to test on. Would be great to have “virtual device” profiles for testing rather than having to spend $$$ on hardware which doesn’t bloody work reliably between the new and classic systems. It would normally be a semantic (read: pedantic) distinction but it speaks to the issue of terminology again - software development is always about creating a “virtual world” or representation of things in your head before they are applied in code, which is what makes it so maddening!
I get that SmartThings is an ecosystem designed to be powered from Samsung’s phones and the Android app, but surely there have to have been conversations about making the platform truly developer-friendly?
