No, I’m not setting state change. Could you please clarify why is it required?
Thanks.
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)
else
log.debug('zemismart_button(): invalid component or capability ')
end
end
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
Lastly,
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:
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.
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.