SmartThings API Browser+ ... Now Available to All

Ooooo…and this:

I don’t know a way of finding out what the hub’s current info on that is, but the sunrise/sunset times for your Location can be pulled from the API on the URL{{locationId}}/capabilities?name=weather
1 Like

This is just amazing, great work and thanks a lot!
Is there also a way to create a virtual switch to trigger an alexa routine via your webpage?

Nevermind, already found it. If I create a virtual Lock I can use this to trigger alexa routines. Just perfect. Tx so much :slight_smile:


Everything looks good except I’m hitting a snag on why I wanted to check this API browser out. It looks like the driver section under devices is showing up blank.

I’ve created a couple additional tokens providing all access to my hubs, but it doesn’t seem to be populating with any entries. I was hoping to use this to map out which drivers were being used where. I’m wondering if there was anything that I missed that could have caused this?

Where you are looking, will only show drivers that you personally created. There’s another location for what I think you are looking for…

Location/Hubs/(select your hub)/Installed Drivers


And once you do that, highlight a driver and click on “List Devices” to see which devices are using that driver.


It is probably worth giving a little info on how this area of the API plugs together.

The /drivers endpoint returns the drivers that you (by which I mean the Samsung/SmartThings user that generated the PAT you are using - the ‘principal’) created yourself. Every other driver, even those created by other members of your SmartThings Location, is a third-party driver and is not accessible to you via /drivers.

Similarly the /distchannels endpoint (which allows for more than just channels of drivers) returns the channels that you created yourself. However you actually have access to any channel that you (again specifically the principal of the PAT) have subscribed to, by which I mean you accepted an invite to. You can see all of those by accessing /distchannels?includeReadOnly=true, and if you do you may find yourself wishing there was an ‘unsubscribe’ because all the extant channels that you’ve ever subscribed to are there. You can also see the Production Default channel as that is a special case that doesn’t need a subscription.

You can drill down into /distchannels to see which drivers are in each channel (/distchannels/{{channelId}}/drivers) and you can also see the metadata of each driver which includes the fingerprints (/distchannels/{{channelId}}/drivers/{{driverId}}/meta). Remember that’s only for the channels you have access to as mentioned above.

When it comes to looking at the channels and drivers associated with your hub you are looking for /hubdevices/{{deviceId}}/channels for the channels each of your hubs is enrolled in (which doesn’t include the Production Default channel), and /hubdevices/{{deviceId}}/drivers for the drivers installed on each of your hubs (and note that /hubdevices doesn’t do anything useful, you have to get the ID from /devices first). The channels give you the name, description and subscription URL for each channel but if you want more you have to use the channelId it gives you with /distchannels. Similarly the drivers give you the name, developer and the channelId they were installed from for each driver and if you want more you have to go hunting for it armed with the driverId.

I guess what I am trying to convey is that a lot of seemingly straight forward queries from a user point of view actually have to be anticipated as they need bespoke handling and security can get in the way sometimes.


This is helpful, as the IDE “placeholder” does not appear to be a good way to get a broad picture of how much has transitioned.

The easiest way to find what has NOT converted, is to use menu: Devices/Devices. Then click on Filter and choose Device Type and DTH. That will return all devices that are using an OLD DTH as the driver.


that helps- With my two manual conversations, I’m up to 30% now!

@TAustin I’ve now created a couple of ‘Virtual Locks’, because they come in handy as they can trigger Alexa routines which I need.
It seems that when you create them they are assigned a random battery % level? Any way to crick this up to a permanent 100% battery level, because now I’m constantly getting messages that battery levels are low… Which makes no sense for a virtual device :wink:

Tx so much!

I don’t currently provide a way to set that value within this app, but to me, the right thing to do is have the SmartThings team fix it.

@nayelyz - Could you please put a request in to the team that when you create a virtual lock through the API, that the battery state value needs to be set to 100% rather than a seemingly random number that can often trigger low-battery notifications?

In the meantime, you have a few choices:

  1. If you have the CLI you could use it to update the battery value
  2. If you have a hub, you could alternatively use my vEdge driver. With that you have further choices - create a virtual lock (that does not included a battery), or create an Alexa switch device with an an optional contact that can be used to trigger Alexa.
  3. Also if you have a hub, use my Alexa Multi-trigger driver which uses a slightly different approach that could work for you. Read more info at that link, and here.

Are we talking about the ‘Virtual Lock’ you can create via /virtualdevices/prototypes (which is smartthings virtualdevices:create-standard in the CLI)? I know that ‘Virtual Lock’ includes the battery capability and the default attribute value seems to be random.

If so then I don’t quite see the problem as you can set your preferred value via /virtualdevices/{{deviceId}}/events (or smartthings virtualdevices:events).

Thanks for the alternative options, since I have no programming knowledge (dont know how the CLI works) and I have no intention of buying a hub, the above options are not an easy option for me.
What I did now is turn off notifications for all the specific virtual locks and it does the trick as well.

@orangebucket thanks for the tip, I’ve created the virtual locks using this API browser+ from TAustin, I have no real understanding to what’s behind it, but I guess its kind of explained in this topic subject.

1 Like

Ah yes, I hadn’t registered which topic I was in.

Hi, I already shared this with the engineering team. Once I get their feedback, I’ll let you know.


Anybody else finding the Enable / Disable buttons not working for Rules?

Yes. It isn’t an API Browser+ thing, they are returning a 401 when I hit the API directly too. The error message returned is:

Failure: get-installed-app-by-id.

That might sound weird but Rules are actually installed SmartApps.

Every day I understand less!


I’ve been trying to create a rule through the browser (to incrementally increase the volume of a sonos speaker on the push of a zigbee button, which isn’t possible in the app). Not being familiar with coding I copied an existing routine from the browser and modified it with the help of ChatGPT and other examples on this forum. After many iterations I’ve not been able to get a working rule however, with a few different error messages [HTTP error 422, The request is malformed] each time I attempt to upload the JSON file.

In the end I copied an existing rule created by the app and tried to upload that, just to see what would happen, but again got an error regarding the if statement and an “unrecognized field”.

Is that to be expected? Am I doing something fundamentally wrong there?

You mean you copied a routine? It can be a useful way to learn but routines include a series of metadata that has to be eliminated, principally “type” but there are various, while notifications cannot be included.
I think if you posted your code here somebody could help you.
PS ChatGPT has been tried for rules but it doesn’t follow the correct syntax.