List of compatible categories/ocfDeviceType used by SmartThings Skill

[w35l3y (Wesley Menezes)]

In my tests, it seems SmartThings Skill uses ocfDeviceType field that is present at metadata block of device profiles to make devices visible/controllable by Alexa.

I would like to know whether my suspicious is confirmed or not.
If so, what is the acceptable values that we should use when creating profiles to make device compatible with Alexa?

This is what I have so far… but none relate anything with SmartThings Skill.

Change icons in new app

I extracted this out of the Developer Workspace a few months back. I make no claims for it, other than it is the list that was available for creating Device Profiles at the time. UPDATE: This list has been referenced in various places so I thought it should have an update. This version was created on 9th October 2021. The ‘Device Type’ column appears in PascalCase in certain contexts. I chose to use the readable version … Device Type ocfDeviceType Air Conditioner oic.d.airconditioner Air Purifier oic.d.airpurifier Air Quality Detector x.com.st.d.airqualitysensor Battery x.com.st.d.battery Blind oic.d.blind Blu-ray Player x.com.st.d.blurayplayer Camera oic.d.camera Contact Sensor x.com.st.d.sensor.contact Cooktop x.com.st.d.cooktop Dishwasher oic.d.dishwasher D…

New SmartThings Alexa skill (2020)

I tweeted a bit about this, but thought it might be a good heads up for the ST nerds not on Twitter Especially since new users can no longer use the old skill. The old skill is now called “SmartThings Classic” while the new one is just “SmartThings”. If you search the Alexa skill catalog you will only find the new skill, but the old/Classic one still shows under your installed skills if you already set it up. I don’t know what SmartThings’ plans are for migration, but i thought it would be worth discussing since the skill is public and new users will be using it. Based on the lack of it appearing in the Groovy IDE and appearance in the new app, the new one uses the new APIs instead of a Groovy app. So far here’s the differences I’ve noticed and my experience: Enabling the …

The meaning of deviceTypeId and a list of available types

Hi, I’m trying to understand the meaning of deviceTypeId, deviceType and ocfDeviceType and find a list of available values for each one. Could you please point me to some documentation regarding this? Specifically, how changing of deviceTypeId in devicde-profile.yml of edge driver is reflected in ST APP? If I understand correctly, the icon is shown based on ocfDeviceType, not on deviceTypeId . Is there any difference between DHT and the edge driver for those types? Thanks

[orangebucket (Graham)]

@w35l3y

In my tests, it seems SmartThings Skill uses ocfDeviceType field that is present at metadata block of device profiles to make devices visible/controllable by Alexa.

I haven’t used Alexa for a while, but a quick sample of various of my devices doesn’t reveal any that have ocfDeviceType in the profile, and it doesn’t seem to be used in the profiles for any stock Edge drivers.

[w35l3y (Wesley Menezes)]

Interesting.
So they have some kind of precedence.
What do you think they use to distinguish device types ?

In my case, I had the declaration below and wasn’t being recognized:

metadata:
  deviceType: PresenceSensor
  ocfDeviceType: x.com.st.d.sensor.presence
  deviceTypeId: PresenceSensor
  mnmn: SmartThingsCommunity

Then I changed x.com.st.d.sensor.presence to oic.d.switch and it showed as a switch.

[orangebucket (Graham)]

I would have been looking to the categories of the main component first.

[h0ckeysk8er (Bruce Pinsky)]

@w35l3y

Interesting.
So they have some kind of precedence.
What do you think they use to distinguish device types ?

In my case, I had the declaration below and wasn’t being recognized:

metadata:
  deviceType: PresenceSensor
  ocfDeviceType: x.com.st.d.sensor.presence
  deviceTypeId: PresenceSensor
  mnmn: SmartThingsCommunity

Then I changed x.com.st.d.sensor.presence to oic.d.switch and it showed as a switch.

Here is a sample of the OCF device types that I see in my Z-Wave, LAN, OCF, Matter, and VIPER devices:

oic.d.smartplug
oic.d.light
oic.wk.d
oic.d.wirelessrouter
oic.d.refrigerator
oic.d.tv
oic.d.camera
oic.d.dishwasher
oic.d.thermostat
oic.d.switch
oic.d.smartlock
x.com.st.d.hub
x.com.st.d.remotecontroller
x.com.st.d.networkaudio
x.com.st.d.sensor.contact
x.com.st.d.sensor.presence
x.com.st.d.sensor.motion
x.com.st.d.mobile.presence
x.com.st.d.doorbell

[orangebucket (Graham)]

@orangebucket

I haven’t used Alexa for a while, but a quick sample of various of my devices doesn’t reveal any that have ocfDeviceType in the profile, and it doesn’t seem to be used in the profiles for any stock Edge drivers.

I want to revisit that statement to make it clear that I was talking specifically about the device profiles. Apart from some special cases like the device objects for device groups and ‘mobile as a thing’ devices, all of my device objects have an ocfDeviceType.

So I wouldn’t want to question the significance of ocfDeviceType to Alexa, only to note that it seems that it is ‘normally’ a derived value.

.

[nayelyz (SmartThings Developer Support)]

Hi, @w35l3y
I checked with the internal team and they mentioned that custom integrations are not officially supported to be discovered by Alexa.
There are several check-ups to verify if a device is ok to be discovered to ensure that the integration will work as expected on both sides. The metadata like ocfDeviceType is only one of them.