Is it possible to get the name or some kind of identifier of the currently selected icon for a device? This information has to be stored somewhere associated with the device and not locally. @nayelyz
You can use the device-profiles endpoint on either the api or cli i think
I think âOCF Device Typeâ is what drives the icon type
Sort of. If you pull the device object from the API (smartthings devices {{ID}} -y in CLI speak) you may see something like this listed under the entry for the main component:
categories:
- name: Switch
categoryType: manufacturer
- name: Light
categoryType: user
icon: oneui/oic.d.light
The icon only seems to be there if you have selected it in the app. The manufacturer category is specified in the profile. The user category is presumably also related to the app selection.
The API is in pieces at the moment so I canât do any more checking. Presumably if you define the icon in the device config/presentation that also appears here.
1 Like
Are you talking about pulling it from this?
https://api.smartthings.com/v1/devices/{{deviceId}}
If so I donât see any kind of information pertaining to icon.
Yep. It would probably have been easier to quote that URL to start with.
Edit :
It does give a basic identifer but, it doesnât differentiate between the type of lights. It doesnât matter what light icon you choose it just says light.
Thank you, after looking deep at the json itâs inside the categories array part of the json.
@orangebucket you are correct it does give you. They type of icon, for example if you choose light, it will display âlightâ but it will not let you know which light icon has been chosen.
I noticed the CLI shows the URL icon but the API doesnât, is this to know the resourceâs value to assign the icon to another device?
Command:
smartthings devices deviceID -j
For example:
"components": [
{
"id": "main",
"label": "capsDev",
"capabilities": [
...
],
"categories": [
{
"name": "Switch",
"categoryType": "manufacturer"
},
{
"name": "Light",
"categoryType": "user"
}
],
"icon": "oneui/light_floor_stand" //Here
}
]
Iâm needing to know the name of the assigned icon so I can know what icon to use when setting a widget icon state to activate/inactive.
Yes, I could manually assign them but I want it to do it dynamically. To minimize the code.
You can get it on the API as orangebucket said above, but you need to use the following URL without the version number
https://api.smartthings.com/devices/{{deviceId}}
And you also need to set the version in an accept header
"Accept":"application/vnd.smartthings+json;v=20170916"
This is how the CLI calls the API for devices
Oh yes, I was forgetting that the Core SDK uses a private API version for the devices endpoint and it does make a difference to some things.
Similarly, if you want to see the raw content of Scenes you need a different API version.
@nayelyz I think there may be some things you might like to try and get addressed here. Firstly it is ridiculous that the SDK, and so the CLI, doesnât use the public version of the API for everything. It shouldnât be necessary for those of us who favour other languages to dissect the Core SDK to find that out.
Secondly, despite the API reference implying that the API version number can either be specified inline in the URL or in the accept header it isnât true. You can use /v1 in the URL but anything else has to go in the accept header.
Thirdly, when you use the CLI in debug mode you will notice that it doesnât use either of the documented methods of specifying the API version. It only uses the documented application/vnd.smartthings+json;v=1 style of accept header when overriding the version number, otherwise it uses application/json. I found I had to follow its lead as certain requests will not even work with the documented accept header.
That still doesnât work.
Json return.
{
"deviceId": "3fcfddad-8858-484a-980f-799e31f03d07",
"name": "Ecosmart Light",
"label": "Loft Lamp",
"manufacturerName": "SmartThingsCommunity",
"presentationId": "438f1c9c-bb47-37aa-aadc-51e6abf7e7a1",
"deviceManufacturerCode": "The Home Depot",
"locationId": "7b48bdb7-1aa5-4689-a8ee-4ad213b43b3e",
"roomId": "b0c98c40-fe3a-44f3-948e-0b9fc10671a1",
"components": [
{
"id": "main",
"label": "Loft Lamp",
"capabilities": [
{
"id": "switch",
"version": 1
},
{
"id": "switchLevel",
"version": 1
},
{
"id": "colorTemperature",
"version": 1
},
{
"id": "firmwareUpdate",
"version": 1
},
{
"id": "refresh",
"version": 1
}
],
"categories": [
{
"name": "Light",
"categoryType": "manufacturer"
},
{
"name": "Light",
"categoryType": "manufacturer"
}
]
}
],
"createTime": "2021-03-01T20:13:17.594Z",
"parentDeviceId": "12734877-add5-4ef8-a2f6-0c26ba76d692",
"profile": {
"id": "5fffd47e-334a-3927-be4f-2ca7766fb30c"
},
"zigbee": {
"eui": "CCCCCCFFFE57E81C",
"networkId": "0773",
"driverId": "f2e891c6-00cc-446c-9192-8ebda63d9898",
"executingLocally": true,
"hubId": "12734877-add5-4ef8-a2f6-0c26ba76d692",
"provisioningState": "PROVISIONED"
},
"type": "ZIGBEE",
"restrictionTier": 0,
"allowed": []
}
Think you have specified the headers wrong, donât think they should have speech marks - but it all depends on the client app you are using (it looks a bit like tasker).
The header i copied was from one of my javascript based apps, where i was specifying the header and speech marks are used.
@lmullineux thank you for the help.
I donât know about you but it is very frustrating to have this much fragmentation in the API. @nayelyz why is there two different header types and a different URL needed to get the icon information. Is there a reason for the fragmentation in the way data is retrieved?
I donât have any info about this. Weâll ask the engineering team and let you know their feedback.
1 Like
Hi, everyone
Iâve been talking to the team about this concern. The answer they gave me is the following. There are not two different APIs, but two different versions of the same API. The icon information was always intended to be for internal consumption only since it doesnât really make much sense unless you are trying to build a new frontend. That is the reason why the v1 API is not currently showing it. Maybe, if you can share with us a strong reason why would this information be helpful for you, we can present the formal request to the team, otherwise, I wouldnât expect this to be changed.
Remember there also exists the web version of the SmartThings App: my.smartthings.com
My reason for wanting the assigned icon is because Iâm using the API and the Android app Tasker to build SmartThings Widgets that live on my home screen that will update the icon based on itâs state since the SmartThings app only supports scenes as widgets.
Hi, @Jake_Mohl
As I said before, I donât think we have any plans to show this information in the requests to the v1 of the API, but as long as the version 0 of the API is available, you can still check it there.