Remember that I asked for support for the part where the Oops Sorry tab appeared when I made the Device Profile before?
Anyway, that was solved by making another project and deleting the Device Profile.
Instead, I have a lot of questions about other parts. I think I have to ask for a lot of support in the future…
My first question is Custom Capability.
I made some Custom Capabilities by watching Jody’s video.
But I’m not sure which method is the right way to use this Custom Capability.
Is DTH only way to use my custom capability?
The reason I ask this is in the Device Profile tab of my Workspace, I can find and select Custom Capability that I have defined.
as you know, The request came to my STSC in the order of
grantCallbackAccess -> discoveryRequest -> stateRefreshRequest.
I also implemented a handler to handle these by using my device profile’s unique id.
The problem what I really hope to solve is Command Request!
My Device Profile is composed of Custom Capability and Capability provided by SmartThing.
When I touch the UI of Capability provided by SmartThings, I confirmed that the request comes very well to my STSC. However, when I touch the UI of Custom Capability, any request comes to.
Isn’t it possible to send the correct Command Request by using my custom capability by creating a Device Profile of Workspace?
Is it impossible to use alternatives with stepper?
When the displayType is state, I have confirmed that the alternatives are clearly effective. But I don’t think it is possible in the stepper. In the case of a specific value in the stepper, I have to display something like “X”.
(The value will be sent by STSC)
It’s really serious. What should I do? (I tried to use this method as the visibleCondition has not been implemented yet)
As the development begins in earnest, there are many questions!
I’ll keep asking questions…
I expected to throw a state-refresh request to STSC when the user touches the device’s dashboard view on the UI of the Smartthings App to enter the detail view.
Or, in the detail view, I expected the stateRefresh request to be thrown by sliding the entire screen.
But neither of these things happen…
What sequence exactly is done to show the current state?
Of course, I could give the App stateRefreshCallback first, but I think that there must be a condition where the judgment for it comes first. What are the conditions for this behavior?
Was that part missing when configuring Capability?
Answer Please. thank you.^^
After all, stepper couldn’t implement these features because alternatives didn’t support it.
Inevitably, it was decided to mark something like 0.
(As you know, the way of expressing it that way is too bad.)
couldn’t your team create a custom stepper for my constraints? (… Its serious)
Oh and I found another new capability to apply for this situation. How about applying notification capability here?
I want to use it, but I can’t find an example of that capability. Could you please guide me a little?
First, I would like to know which Interaction Types can use Notification Capability.
Is it thrown through stateRefreshRequest?
Or am I supposed to first throw it through the Callback format?
Also when throwing
I am curious about the payload that should be included.
You can include this capability into your device profile and use it as a notifier at your device’s detail view.
For example, if you disable your stepper through your st.list, use the Notification capability to let your users know by not only responding the st.list command, but also including the message, e.g.
… and if your users try to force commands “because the thing is not working”, just respond with a RESOURCE-CONTRAINT-VIOLATION error enum (more details about Error Responses Here) to handle those responses… or you can send the uppercase version of your message (don’t).
If you need more details about this capability, check its definition and presentation with these ST CLI commands: