[ST Edge] Issue with triggering automation/routine for button capability


Following @Paul_Oliver 's report in Edge driver for Zemismart 6 button remote - #49 by Paul_Oliver

it seems the automation is not triggered for button state change.
The log shows the driver emitted a push event:

2021-12-31T17:56:11.850327461+00:00 INFO Zigbee Button Remote Driver [YG] <ZigbeeDevice: 19577592-86a6-4216-a12d-b3b0bfb54f5b [0x46FE] (6 button remote)> emitting event: {“capability_id”:“button”,“attribute_id”:“button”,“component_id”:“button1”,“state”:{“value”:“pushed”}}

Is it a known issue?
How needs to be done to troubleshoot this?


Did you set ev.state_chage flag?

ev = capabilities.button.button.pushed()
ev.state_change = true


@zambobmaz Thank you very much for your help.

No, I’m not setting state change. Could you please clarify why is it required?

My current code is like this:

local button_attr = st_capabilities.button.button

local event_id_to_capability = {
    [0x00] = button_attr.pushed(),
    [0x01] = button_attr.double(),
    [0x02] = button_attr.held(),
local function handler(...)
    local component = component_name and device.profile.components[component_name] or nil
    local capability_event = event_id_to_capability[v]

    if component and capability_event then
        device:emit_component_event(component, capability_event)
       log.debug('zemismart_button(): invalid component or capability  ')

In my experience, the actual principles and operations may be different.

If the hub receives the signal normally in the device, the APP does not execute the function (routine) if the value of the state_chage is “false”.

Unlike the Switch, Button does not know the previous state. So in “Edge Driver”, the button’s state_change flag seems to be “false”.

Even if the hub receive the stage_change as a false, the Edge Driver can read the value, so you can run the Function through the button click combination.

i.e) Press Button 1-> 2-> 3 in The Device == Trigger Press Button 1 in the APP

Your code might be

local capability_event = event_id_to_capability[v]
capability_event.state_change = true


Thank you for your input, @zambobmaz.
Indeed, @ygerlovin, you need to add this property. This is because the automations execute when a value change is received. If you push the button, the attribute value becomes "pushed", if the button is pushed again, the attribute value remains the same, that’s why we need to specify this is actually a change because as @zambobmaz mentioned, it is set false by default.
You can check this function of the Zigbee button driver released by ST where this property is sent:

1 Like

Thank you @nayelyz .

When the event is emitted, the value of capability in GUI is changed. I assume, the attribute value is changed as well.
However, after a short period of time, the capability in the app returns to ‘Standby’. The driver does not emit ‘standby’ event, it is probably generated by the hub or by GUI. As far as I understand, this event does not change the attribute’s value. That basically means that the GUI’s and capability’s attribute states are inconsistent.

Could you please confirm that my understanding is correct?
Would it be possible to share the reason for such approach?
Is it possible to disable automatic transition into ‘Standby’ state? The driver could schedule a timer to return to ‘standby’ state.

Thank you

Yes, ‘Standby’ is purely an invention of the apps. I don’t like it because it creates a misleading impression of how things work. I take the same issue with the use of verbs like ‘arrived’ or ‘opened’ which imply a change of state that might not have happened. However at least they don’t completely invent a state and you can work out what they mean. With ‘Standby’ the actual state could be any supported value.

It is useful to have a visual indication of an event having been received, but a simple flash of the background of the tile would do.