EVENTs from buttons

Developer Programs Writing Device Types
1

Contact Sensors and Motion Detectors have two states that they can transition between: open/closed and active/inactive. A status query shows the state at the time of the query.

A button appears to have only two states: pressed and held. When an event handler is triggered from the API, the “pressed” and “held” attribute values are passed in. A status query shows pressed or held (depending on the last action?), because there is no “unpressed” value.

Why isn’t there an event for a button for a “released” event?

2

Actually there are now lots more states for a button than ‘pushed’ and ‘held’, but older apps aren’t necessarily aware of them.

                            "pushed",
                            "held",
                            "double",
                            "pushed_2x",
                            "pushed_3x",
                            "pushed_4x",
                            "pushed_5x",
                            "pushed_6x",
                            "down",
                            "down_2x",
                            "down_3x",
                            "down_4x",
                            "down_5x",
                            "down_6x",
                            "down_hold",
                            "up",
                            "up_2x",
                            "up_3x",
                            "up_4x",
                            "up_5x",
                            "up_6x",
                            "up_hold"

You are right there isn’t a specific “released” value for those buttons that do report it. There also isn’t a matching event value that could differentiate the initial press from a completed single push, if any buttons report that.

I don’t have any issue with this as I can’t see what they’d mean in a system that doesn’t work in real time.

3

It might not quite be real time, but a home automation network should be reasonably responsive (100ms?).

So a perfectly reasonable requirement for it would be as a dimmer control. i.e. change in proportion to how long button was held down for. More generically it would be a requirement for anything that is a displacement based actuation, for which holding the button down for longer means “I want more”, rather than repeating presses for a pre-defined increment.

It’s not that different from an open/close contact, so why make it different?

4

From a device class definition standpoint, it’s a lot different from a binary state device.

That said, your original example was the right one. There are many button devices for both Zigbee and Z wave which do distinguish between “press“ and “long press,” But it’s nothing to do with real time execution. It just offers multilevel reporting. Exactly like you suggested for a dimmer device. The longer you hold the button down, the higher the level of brightness requested.

Or sometimes it’s simply used to give you more options from the same button. Tap, double tap, and long hold are common on many button devices, and that give you three different control options. In that case, the exact timing of the long hold doesn’t matter: just that it is longer than what is considered a single tap.

On a zigbee device these are often described as “pushed” versus “held.” Where pushed is a short tap and held is the long hold. The button sends a single report indicating either pushed or held. It doesn’t send a release event message. It doesn’t send the exact time the button was held for.

So those are two different use cases for a long hold. One to set the level of a multi level command, the other to simply create a third control option.

In platforms which didn’t have a cloud component, capturing the “button released“ event was pretty common, and we did used to see that up until about 2012.

The problem once you introduce a cloud component isn’t the additional time, it’s the variability created by cloud latency. It just becomes harder and harder to accurately distinguish between even a tap and a double tap, let alone a long hold.

So most device manufacturers have shifted to a design where the tap pattern is captured by the device itself. This means the release event message is no longer needed. The end device does the calculation itself And then determines the next action to take. If it’s a setlevel command for a multi level function, it just sends the desired target level. Rather than sending the release event and expecting the receiver to figure out the target level from that. :thinking:

All of which is to say we used to see a lot of release event processing, but now that’s very rare in systems with a cloud component. Because it just turned out not to be a reliable method.

Also, the first rule of home automation still applies: “the model number matters.”

Some button devices do calculate the length of time of the hold and send that as a setlevel report.

But other button devices just treat the long hold as a third option. They don’t send the time interval. Just “pushed” or “held.”

This reporting is determined by the firmware on the device and it’s not something that you can control from the smartthings side.

But you can make sure that the DTH you are using matches the features of the physical device, and in particular, that it is correctly capturing setlevel if that information is available

1 Like
5

Again, you are asking questions about how the IKEA On/Off switch is working.

Here is the DH of the device:

You can see how is it working from the Zigbee messaging point.

1 Like
6

No. It’s a question about how generic button events are modelled. (Which is why I created it as a new topic) But thanks for the data.

8

Whether it’s a tap, double tap or hold is determined as close to the source as possible surely? No one is suggesting that you send low level event across the mesh or the cloud and expect them to get there reliabily and in sequence surely? Or maybe they did and that’s the reason…

Conceptually, the “duration of press” is usable data. It could be made available.

9

Some devices do, although usually translated into a setlevel value. That’s how the handheld remotes that controls Dimming usually do it.

But remember that the whole goal of mesh network design for Home Automation is to keep messages as small and as infrequent as possible. These are intended to be low power, inexpensive devices. So nothing gets sent that isn’t needed, and in particular extra messages don’t get sent because they will kill battery life.

But, yes, there are some buttons that will send a value that distinguishes between presses of various lengths. But not all buttons. It’s not a generic feature. It’s an optional one which some manufacturers will choose to implement.

10

So I think you are getting the impression that I broadened out the discussion on to 3 threads on purpose to talk about the same thing on each. I didn’t. I thought it raised 3 separate issues for discussion:

  1. How Smartthings hub occupies and manages a Zigbee network,
  2. This thread. How the event modelling for a button seems limited (i.e. how do you go about raising a change request for such a thing on this website)
  3. and (specific to my IKEA button - can it be onboarded in a way that does not mean it loses it’s ability to control my lights directly - which I think you have answered completely)

And the old thread was closed because my failed attempt to subscribe to the button events has been resolved.

In case you are wondering what I’m actually trying to do. I just wanted to get started in setting up a home brew system. Smartthings looked excellent right at the beginning. But I thought I’ll just do something basic so that I can evaluate the maturity of the platform, the quality of the documentation, the quality of the implementation, the quality of the support team and the quality of the community, and also to ask questions that I didn’t feel were addressed in the core documentation. If it looks like I’m focussing on one particular issue, I’m not, I’m exploring the API to see how I can make use of it - and I feel it’s right to ask questions where it doesn’t look to describe what I’m seeing and to propose new ideas.

11

To be honest, for brewing might be good, but it is a cloud based platform. If the cloud has an outage or your internet goes down, then your brew is going to be wasted.

Hubitat or Home Assitant might be a better choice with fully local control.

Or just look at this project,

1 Like
13

Moving, slowly, for years…

1 Like
15

They’ve been promising “more” local control since 2015. So far it’s been significantly more stock DTHs, which is good. And significantly more functionality for the official SmartLighting feature. Also good.

And beyond that…multiple bullet points mentioning local processing at various developer meetings, but that’s it.

I’m not saying there will never be more local processing, but it’s just obviously not a company priority or it would’ve been here already.

16

I still can’t believe they added “pushed_6x” and not “released” because almost every central scene device I’ve worked with that reports “held” also reports “released”, but hardly any support more than “pushed_4x”.

I can’t imagine anyone pushing a button 6x to trigger an automation, but the ability to use the “held” event to start something and the “released” event to stop it would be useful.

2 Likes
17

Homeseer has a couple of models that support five taps, but that’s the most I’ve seen.

And I definitely agree that if the device transmits a release event, the DTH should be able to support it. :sunglasses:

2 Likes
18

I ended up having to use up 1-5, down 1-5, and pushed 1-5 for the Zooz ZEN30, but that’s the highest I’ve seen so far.

I’m actually glad they support 6 because the Automations feature in the new mobile app doesn’t appear to support button numbers so all the events generated have to use button #1 and having more options to choose from allows you to work around that.

I’m hoping ST fixes the button number issue in automations and adds released, up_released, and down_released to the supported attributes list, but I doubt those things will happen any time soon.

1 Like