Direct Connect Device Button Capability and Automations

bban · February 24, 2021, 12:00am

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?

nayelyz · February 24, 2021, 1:54am

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.

bban · February 24, 2021, 6:39pm

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

orangebucket · February 24, 2021, 9:19pm

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.

kwanghui · February 25, 2021, 4:56am

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

bban · March 5, 2021, 3:17am

@kwanghui Do you have any news?

kwanghui · March 5, 2021, 4:44am

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.

kwanghui · March 25, 2021, 12:56am

Hello @bban ,

We have added stateChange supported API into the SDK.

github.com

SmartThingsCommunity/st-device-sdk-c/blob/03f1354cf767b34faf52148c58d4625f5ff04a37/src/include/st_dev.h#L466


* @param[in] data The data json object if needed. Otherwise NULL.
* @param[in] options The option object if needed. Otherwise NULL.
*
* @return Pointer of `IOT_EVENT` which is used to publish device status.
*
* @warning Must call [st_cap_free_attr](@ref st_cap_free_attr)
* to free IOT_EVENT data after using it.
*
* @see @ref st_cap_send_attr
*/
IOT_EVENT* st_cap_create_attr_with_option(IOT_CAP_HANDLE *cap_handle, const char *attribute,
			iot_cap_val_t *value, const char *unit, const char *data, iot_cap_attr_option_t *options);

/**
* @brief Create IOT_EVENT data with releated command ID.
*
* @details This function creates a new IOT_EVENT data with input parameters.
* Once it returns, user has full responsibility for deallocating event data
* by using [st_cap_free_attr](@ref st_cap_free_attr).
* NOTE:IOT_EVENT created in this function must be passed to st_cap_send_attr function
* for sending events.

And the button capability sample also updated to use new API

github.com

SmartThingsCommunity/st-device-sdk-c-ref/blob/302768b7942809df7558510aa704ead77950d6c9/apps/capability_sample/caps_button.c#L143


if (!caps_data->button_value) {
    printf("value is NULL\n");
    return;
}

value.type = IOT_CAP_VAL_TYPE_STRING;
value.string = caps_data->button_value;

attr_option.state_change = true;

attr = st_cap_create_attr_with_option(caps_data->handle, (char *)caps_helper_button.attr_button.name, &value, NULL, NULL, &attr_option);
if (attr != NULL){
    sequence_no = st_cap_send_attr(&attr, 1);
    st_cap_free_attr(attr);
}

if (sequence_no < 0)
    printf("fail to send button value\n");
else
    printf("Sequence number return : %d\n", sequence_no);

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.

Thanks.

kwanghui · June 30, 2021, 8:19am

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

Topic		Replies	Views
Cloud-connected button pressed more than once but not triggering button-press events in logs or triggering scenes Connected Things developers	2	306	October 12, 2022
Capability.multiButton Capability Type Suggestions	3	1538	February 16, 2016
Help with released button -- GoControl Wireless Remote Switch webCoRE	8	1062	February 16, 2020
[DTH Multi-Component devices] Components not showing correctly Support	31	1506	November 17, 2021
[ST Edge] Issue with triggering automation/routine for button capability Support	6	882	January 4, 2022

Direct Connect Device Button Capability and Automations

Related topics