Hi, I finally, I think got some familiarity with the new ST API and models and wrote a Smart App (connector how they call it now) for my sleep number bed, with an intent to use SharpTools to control it. I also have written Alexa skill but it is annoying as you need to talk to much -
In any case their new way of developing is you need to define the Device Profile with a components and assign capabilities to the components (including custom capabilities which I needed to define). However looks like SharpTools only picked the main component and main capability and left out all the others. Both in the dashboard and in the rule engine. Ay tricks I should use?
Would you mind sharing some more details about the custom device integration? Maybe links to relevant code if it’s available (feel free to PM it to @support).
Do the components implement one of the supported core capabilities? (eg. Switch, Motion Sensor, Contact Sensor, Temperature Measurement, etc)
If the device implements any of the supported capabilities, it should show up in the list of devices to authorize and should grant access to all of the capabilities of the device. For example, I have a Wink Relay device which is a single device with a display, two buttons, two relays, and several sensors built into it. The main device implements most of the sensors and there are components for each of the relays. All of the components implement at least the Switch capability, so they all show up under the “Which Switches?” authorization section.
Granted, the Wink Relay device is a Groovy DTH which has been updated with support for the new components, ocf definitions, etc.
This is the device I’m trying to implement
This is the refreshHandler code
.stateRefreshHandler((accessToken, response) => {
response.addDevice(DEVICE_ID, [
{
component: ‘main’,
capability: ‘st.presenceSensor’,
attribute: ‘presence’,
value: ‘present’
},
{
component: ‘main’,
capability: ‘st.sleepSensor’,
attribute: ‘sleeping’,
value: ‘not sleeping’
},
{
component: ‘main’,
capability: ‘wanderdouble01905.smartbedpresets’,
attribute: ‘preset’,
value: 4
},
{
component: ‘heater’,
capability: ‘st.switchLevel’,
attribute: ‘level’,
value: 10
},
{
component: ‘pump’,
capability: ‘st.switchLevel’,
attribute: ‘level’,
value: 10
},
{
component: ‘head’,
capability: ‘st.switchLevel’,
attribute: ‘level’,
value: 10
},
{
component: ‘foot’,
capability: ‘st.switchLevel’,
attribute: ‘level’,
value: 10
}
])
})
I did enable it for presenceSensor and refreshable device, however it did not show up in any other place, now I understand the rest - so custom capabilties and switchLevel are not supported?
They would need to implement at least one of the supported capabilities, then all of the capabilities should get exposed once the device is authorized under any of the capabilities. For example, it’s common to implement the Switch capability alongside the Switch Level capability.
Alternatively, since the components implement the Refresh capability, you may be able to authorize them manually as noted here:
I did authorize it as a PresenceSensor and the refresh device in the SharpTools. It shows correctly in the ST also. Are you saying i need to add Switch to every SwitchLevel?
If it’s anything like the Wink Relay I tested with, each ‘component’ should show up like an individual ‘device’ in the authorization list.
Based on your screenshot above, the components don’t implement any of the capabilities that are available in the authorization lists. If the components are updated to include one of the core capabilities that are supported during our SmartThings authorization flow (like Switch), I suspect they would show up under the relevant authorization list.
Alternatively, since each of the components appear to implement the Refresh capability, I suspect they would show up under the “Which refreshable devices?” list during the manual authorization process.
You were right they all showed up in refreshable and once selected they could be used in the rules, which is great. However , it did not pickup a custom capability, what is the plan there?
Custom capabilities from the next generation APIs are not exposed by SmartThings to Groovy apps at the moment.
SmartThings has been working on a next generation set of integrations and we have been testing with them. They are not quite ready for prime time, but the new APIs are capable of exposing custom capabilities from the next generation device integrations. There’s some limitations with groovy device handlers with the new APIs though, so there will be some trade-offs to consider when it’s ready.
Ok, thanks, I have some workaround for now, will see how it evolves
Thanks for you resoponse
1 Like