@TAustin I’m getting an error when filtering to offline devices. This started when ST hosed-up the other week and deleted most of my devices. I assumed something got messed up on my hub that the Browser+ didn’t like. Since the ST flub I have rebuilt everything and think I have things aligned. However, I am still getting the Browser+ error so I apparently still have some issue that I can’t see.
Any ideas how to go about troubleshooting? I get the error three times then I eventually get to the offline filtered list.
I would attribute this to a temporary SmartThings server issue. I see it occasionally with the CLI, but haven’t run into it using the API Browser+. 5xx errors indicate just that - a server error. Occasionally the SmartThings servers will reject requests and retries usually (eventually) solve it.
Let me know if you continue to see this happening.
@nayelyz Please see @Nezmo issue above. He is seeing fairly frequent server errors coming back from API calls. Don’t know if it’s a regional server issue or what; I see them occasionally with the CLI, but sounds like his are more frequent.
It would be useful to have info about the request you make (URL, eg. “https://api.smartthings.com/v1/devices” ) and the response, generally, when we make requests to the API, we get a requestID even if it wasn’t successful, that is useful to find the log of the error.
I don’t know if @TAustin exposes it in the browser console, otherwise, you would have to make that request to the API directly from a REST API client like Postman.
If it was querying a specific list of devices, it could be because there are some (or even one) devices with an issue.
Can you provide support access to your account again, please?
It is not exposed in the browser since the UI is a node.js app. There is not detail transaction logging in the API Browser+ implementation at this time.
In this case, the request would have been to the /devices/health API endpoint which would return the device list including the device health and then the response would be filtered down to just the offline devices.
Yes they are. And it looks like all other filters are working fine for me. It’s filtering for offline that throws the error (consistently three times each time I try).
ok, so you’re querying each device’s health to return only the ones “offline”, so you’re making several consecutive calls, is that correct?
The endpoint https://api.smartthings.com/v1/devices/health as suggested by @h0ckeysk8er doesn’t work, it needs a UUID of the device and also the CLI uses https://api.smartthings.com/devices/deviceID/health
I just took a cursory look at the code so I might have missed that the UUID is included in the call. As Todd mentioned, the code pulls the entire device list first so likely only calling the health endpoint if you filter based on status. I’m sure he’ll provide a more accurate explanation since he wrote it
I believe the method used is to query /devices to get a list, allowing for paging, and then cycle through the list hitting the /devices/{deviceId}/health endpoint. That seems like an awful lot of API calls.
I had been wondering whether there was any correlation between the paging and the number of errors, though I can’t really see a failure mode and I thought the paging was in 200s, which is a lot even for Nezmo.
I personally favour using the platform version 20170916 in the Accept header when working with the /devices endpoint, as the Core SDK does, and then hitting /devices?includeHealth=true&includeStatus=true to include the device health and device status in the device listing. I follow the lead of the Core SDK in never using /v1 in the path as I have had it break things. I just mention that for anyone wanting to do their own thing with the API.
I don’t see recall seeing too many 500 errors. The only problem I really have is that Chrome on Windows has an experimental protocol in use and I had to disable it when my hosting was upgraded.
I may not fully understand the point being made here. But just so all know, I have 408 devices. Before the ST collapse last week I could successfully filter for offline without issue.
Did you reconnect the devices or were recovered somehow? I’ll see if the team can check the issue but I need the timestamp on when you try to filter the list and the access to your account, please.
The thought crossed my mind that this could be a rate limit issue, but if that was the case, I’d expect the relevant error to be returned. It’s amazed me so far that we don’t see rate limit errors more often, since some of these functions I’m providing in the API Browser do require a high number of consecutive API calls to get all the required data. If @Nezmo has 408 devices, then that means a few calls to get all the device details, then 408 more calls to get the device health for each one. If SmartThings could expand the built-in supported query parameters, this could be avoided.
All that said, then if this is in fact related to the number of calls being made, then a 429 or 422 error should have been returned.
@nayleyz, you may be right that it could be related to trying to get the health of one particular problem device in his inventory. It’s a long list
yeah, I don’t think it’s the rate limit either since he could previously get the results successfully. Also, I got the same error when I accidentally broke a device integration making some tests, but that happened with the devices endpoint directly, not the health one and it seems there’s no issue with the first call…I already asked the team if they can check the logs around that time, to see if something is registered there.
I had been thinking in terms of paging in 100s and three of those failing, but that actually makes no sense because if they failed there wouldn’t be a way to see the next page.
I’d favour three individual devices that the API is barfing about, quite probably for the same reason.
