Direct Connect Device Button Capability and Automations

Hello, @nayelyz @kwanghui

I’m having an issue with the button capability for direct connected devices. I have my button device connected and when I press, double, or hold, I can see in the app the value update the button capability value briefly before going back to standy. I thought that was all that was required and my button was working. When I tried to hook an automation to it I discovered the automation was not being triggered. Eventually I observed that if I double press or hold then single press the button the automation associated to pressed is executed.

This observation makes me think that automations are not being triggered because the button capability values being updated to ‘pushed’ from ‘pushed’ doesn’t change the state in the cloud resulting in the automation not triggering.

My question is if my direct connected device using the button capability is supposed to clear the button capability value after sending ‘pushed’ or ‘double’? The SmartThings defined button capability doesn’t have a ‘standby’ value so it’s unclear me to what I’m supposed to do after sending the updating button value. Is possible there is an issue in the Smartthings cloud?

Hi, there! I see what you mean, yes, the button value stays as ‘pushed’ unless you change it. Using DTH, there’s a property added to the event to treat it as a state update (isStateChange: true) even it isn’t a different value.
I’m not sure something similar is available in other integrations so, I would suggest you change the value after a small delay.

@kwanghui Do you know if there is any plan to add a isStateChange like functionally to the direct connected device API?

I notice that the subscription API has a ‘stateChangeOnly’ flag, and that there isn’t any obvious sign of any equivalent of ‘isStateChange’ when generating events via the REST API or in the Schema, not that I can see anyway. I am wondering if there has been a switch from preventing propagation, as was the case in the legacy environment, to filtering on consumption of the events. Although it means more events flying around, the latter seems a much more sensible approach as it lets the user decide what is important.

It would seem strange for the events to be suppressed at the device end, but if they aren’t, where are they going? Automations, as in the bog standard ones in the mobile app, have no problem working with repeated ‘pushed’ events, or any other values come to that.

Hi @bban, I’ll back with some internal discussion. Thank you.

@kwanghui Do you have any news?

Hi @bban ,
Sorry for late response.
The team decided to expand API to support StateChange. I think it would take sometime to deploy on public github.
I’ll update here when there is an update.

Your observation was great helpful for us. I really appreciate it.

Hello @bban ,

We have added stateChange supported API into the SDK.

And the button capability sample also updated to use new API

Those changes are still in develop branch. I think you can use that for your testing.
I’ll update here when those commits are merged to the master branch.



Sorry for late update. The stateChange feature is available at master branch.