Smartthings history via API

Developer Programs Support
1

Hi,

Does anyone know if there is an API for the ‘History’ you can see from the SmartThings mobile apps. It’s so much more detailed than the https://api.smartthings.com/v1/history/devices type history as it shows what triggered it too (e.g from a routine or something else)

IMG_0123
IMG_01231170×2532 206 KB

Thanks!

1 Like
2

We know that the mobile app has access to different APIs for some of its capabilities. This may be the case for the mobile app history. Perhaps @orangebucket can comment as he is familiar with some of the mobile app APIs.

2 Likes
3

I think what you want is the /activities endpoint, but I struggle to bend it to my will.

If you do:

https://api.smartthings.com/activities?location={{locationId}}

(where the location filter is optional) you get something very like the /history/devices endpoint.

However if you use what I call a ‘platform version’ (I’ve no idea what it is supposed to be called), and this time include the location filter, you get more joy. That means get rid of the /v1 in the path (I never use it) and then instead of using an accept header of Accept: application/json use:

Accept: application/vnd.smartthings+json;v=20180919

Update: I wrote the wrong number first time around and the location seems to be required in this case.

I think that is about as far as I ever got with it.

I suppose I ought to comment on the results. Basically you get activities of type DEVICE and of type EXECUTION. All I have ever seen for the latter are Rule execution events and they all have the text ‘Routine activated’ even though in my case they are mostly NOT actually Routines in the mobile app sense. I feel there is more to be had.

Update: I forgot that although Rules, Routines and Smart Lighting are all lumped together with the rule type of ‘BEHAVIOR’, there is a separate ‘SCENE’ type which has the text ‘Manually run routine activated’. Sadly the mobile app infests everything. There are also LOCATION_MODE activities.

3 Likes
4

Thanks for the response @orangebucket

I tried this (with the below curl command) with and without the location query param but every time I just got back an empty array of “items” (and a 200)

If I remove the application/vnd.smartthings+json;v=20180819 then it returns data that looks almost identical to history/devices as you said

curl --request GET
–url https://api.smartthings.com/activities
–header ‘Accept: application/vnd.smartthings+json;v=20180819’
–header ‘Authorization: Bearer {{token}}’

Any idea of what to try next/anything I’m missing?

5

Yes, use 20180919 as despite checking twice I still managed to write it wrong last night.

1 Like
6

Hahah,

Some progress (well a different error message) - with the updated date, it now returns a 400 - again have tried with and without the locationId…
Currently using: 20180919

7

Make sure you are using the query string ?location={{locationId}} in this case (where {{locationId}} is the UUID of your SmartThings location). The API is rather inconsistent about how it labels parameters and in what cases they are required.

8

Cracking, that’s the one - had to be location rather than locationId.

For anyone else that struggles with this, full curl command is

curl --request GET \
  --url 'https://api.smartthings.com/activities?location={{locationId}}' \
  --header 'Accept: application/vnd.smartthings+json;v=20180919' \
  --header 'Authorization: Bearer {{token}}'

Thanks a lot :slight_smile:

9

As an aside… how do you know this? Did you proxy the calls and look through them or is there some secret documentation somewhere?

10

I’d like to think there is some secret documentation but I certainly am not aware of it. Proxying the calls would have probably been a sensible idea. No most of what I’ve learned about the API has been based on reading the API reference, reading the API definition (not all of it makes the reference documentation), reading the Core SDK source, reading any other sources I come across, ridiculous amounts of trial and error over a four year period, and some guesswork.

I think a key lesson I have learned is that anything involving UUIDs as IDs is a reassuring sign. That suggests you are in SmartThings’ own territory, a world of conventional REST APIs with path parameters identifying resources, and query strings as filters, where things do actually make sense after a while.

Anything using short unique IDs is a sign you’ve wandered too close to planet Samsung or are otherwise working with relics of the early days of the ‘new’ platform and the Developer Workspace. It isn’t worth trying to make any sense of it.

2 Likes