Maker API - Get Device Info - Return Device Type

📢 Feedback Feature Requests
1

@patrick,

would it be possible to include the device type in the "Get Device Info" request?
http://[IP]/apps/api/[appid]/devices/[Device ID]?access_token=[token]

It is currently returned by the "Get All Devices with Full Details" but not if we just query to info for a single device.

Thanks

1 Like
2

+1 to this request - the lack of parity means it takes a "Get All Devices with Full Details" call, which on my system takes 9 seconds instead of 50 ms for a single Get Device Info.

3

/devices/all actually has bugs in it and returns incorrect data for attributes sometimes (often) that are also mangled/malformed json.

Just do /devices/* . It is 3-4x faster than devices/all (in my testing on my hubs) and returns the data in the /devices/## format (which I think is what most people want) with non-malformed json.

1 Like
4

Thanks for the suggestion! I tried that and it's faster, but still doesn't contain the "type" field which shows the driver name - eg Generic Zigbee Dimmer.

Best case scenario is that I can do a single device query (faster, less locking potential for the hub during the query vs. an "all" query) and that it returns the "type" field.

5

(Use case: need the driver name in order to show correct icon for the device)

6

Tagging @bravenel since I think (?) he's the new maintainer of Maker API.

7

Why not do devices/all in the initial setup of your app, and either query individual devices or do devices/* when necessary? You can save device type during initial setup.

8

Ah, gotcha. Sorry about that. I don't use type for anything so didn't notice that. I base everything 3rd party I do on the advertised commands and attributes, so have never been the type field.

@aaiyar suggestion would be mine as well then, unless you get market API changed of course. Bruce has been very reasonable in tweaking it when presented with the case of why the change is needed.

9

Yes, thanks. I could definitely take the approach that @aaiyar offered, and build a working app - no doubt, and thanks for the suggestion. However, there are two arguments for adding the “type” field to the get device (single) API:

  1. API consistency — it’s an odd wrinkle that the "type" (driver) field is only available in an “All” call - in fact it’s the only missing field between All and Single (afaik). I’m guessing it was just an oversight when building one of the API’s.
  2. Better database access hygiene w/ reduced risk of temporary hub slowdowns -- for a case that doesn’t require point in time consistency, I think it’s better to issue a series of small DB queries over a longer period instead of a monolithic block of SELECT’s. The monolithic block approach tends to dominate the DB, starving out other queries that should be real-time responsive. In practical effect for Hubitat, that could be the difference between a motion lighting event firing in real time vs experiencing lighting delays while walking around the house.
10

Gotcha. Well, I would suggest you submit a feature request to Bruce and see if he'll add it.