Add held back to original button about xiaomi HOT 13 CLOSED

I just came up with a way to get it work and also add an additional function. Just posted over on ST Comm Forums, but here it is again:

Use a runIn() function to set a countdown timer instead of the method of comparing “pressed” versus “released” time used in the a4refillpad DTH.

So if the device handler receives a “pressed” message from the button, it starts the runIn() countdown based on the user-set preference. At this time, no message is sent to the hub (the button state is not updated).

If the button is released before the runIn() countdown is finished, then the device handler tells the hub the button was “pressed” (state change).

If the button hasn’t yet been released when the runIn() countdown is finished, then the device handler tells the hub the button is “held” (state change).

Then… (additional feature), when the button is released, a “released” message is sent to the hub (state change).

With the "held" then "released" combination, it could be used to set up a piston to start dimming a light on “held”, and stop dimming on “released”. Or make the lights brighter (if starting from an off state - but that's the WebCoRE users' thing to work out). Anyhow, the button could be used for setting the brightness of a light/group of lights.

from xiaomi.

Actually, I missed the 'held' and was trying to figure out a way to make it work as it did in the old one - looks like you're getting it though!

from xiaomi.

(and no, I'm not moaning @tmleafs !) - just very gently whining :-)

from xiaomi.

Just in case there wasn't a notification, I made a Pull Request #95 with my stab at a momentary button function that uses runIn as described above. Since it's so different from what you're working @tmleafs, I made it a Pull Req on your Pull.

Note that I rearranged the order of functions to move the parseButtonMessage() (renamed from parseCustomMessage) up, just below the main parse() function, and then moved getContactResult() to be just below that, and added a new heldState() function after.

The Toggle Mode is set up to work exactly the same as it does for the Aqara button: When the button pressed message ("on/off: 0") is received, the device.button state alternates between "pressed" and "released". Toggle Mode ignores the released message ("on/off: 0") from the button

Here's how the Momentary Mode using runIn works, in a nutshell:

1. When a button pressed message is received, the runIn is called with a time of the waittoHeld preference setting (or 2 seconds default if not set), and a boolean attribute named countdown is set to true.
   Note that the device.button state is NOT changed to "pressed." This is because that is the way the old DTH worked. We could consider adding yet another preference that allows 3 states in Momentary mode ("pressed", "held", and "released") which would allow for some pretty fancy stuff to be done with it in WebCoRE.

2. When a button released message is received, the device.button state is changed to "released," and the countdown attribute is set to false.

3. When the runIn countdown is finished, the heldState() function is called, and if countdown is set to true, the device.button state is changed to "held."

In theory, it should work fine, but I haven't put any safeguards against a user repeatedly pressing the button setting up a cascade of runIn countdowns. What would happen for each runIn countdown as it reaches the time to call heldState() depends on the value of the attribute countdown. I don't think it would be a problem because if you repeatedly pressed and quickly released the button a number of times, and then held it, one of the runIn countdowns will see that countdown attribute is set to true, and change the state to "held". Then release the button, state is changed to "released" and the other runIn countdowns would just expire without any action.

But since I don't have an "original" Xiaomi button, I can't really test this. I do have the Mi Cube, so I suppose I could do a hack that turns one action into button pressed and another into released, but that's just not the same.

Anyone here have an "original" button to test this out with???

from xiaomi.

I was just looking at the original a4refillpad code again, and actually the momentary function changes the button.state to either "pushed" or "held". It never sets the state to "released: (which I think is really strange, but let's save that discussion for later).

Anyhow, I'm sorry, my bad. But that can be changed after testing whether the runIn method works.

I forgot mention that I put a bunch of debug log messages that start with "BUTTON TEST:" to help see whether it working properly or not.

Also, having reviewed the old DTH code, I can't for the life of me see how that code displays whether the button has been pushed / released in the main tile. That tile is set up to be linked to the switch state, not button. The switch state shouldn't even be used because that capability is reserved for controllable switches that directly control something (such as a wall socket switch or in-wall mains-powered light switch or dimmer.

from xiaomi.

Don't think we need to change it back - since we do get both statuses with the old button we might as well use it, no? Not home w/ my button but will test when I get home this eve.

from xiaomi.

Don't think we need to change it back

@alecm - Well all these users of the "original" button and the a4refillpad DTH seem to already have WebCoRE pistons set up that look for "pushed" and "held" events. So I think it would be best to provide that at a minimum.

The additional preference setting could then be the three-state Momentary Mode. ("pushed" when button pressed, "held" if held to the countdown time, and "released" when released.)

from xiaomi.

Sorry about confusion - agree that we should have 'pushed' and 'held' - meant that we should take advantages of the 'pressed' and 'released' messages on the old one - probably misunderstood what you meant.

from xiaomi.

Wasn't able to get around to testing the button last night - will do so tonight (I'm at work already)

from xiaomi.

So - with many thanks to @alecm, I've not got my own round "original" Xiaomi button to do testing with.

Unfortunately, after trying both the older a4refillpad DTH and my attempt at using a runIn() countdown, I can see that no method is going to be 100% reliable.

I'm quite sure the reason why it doesn't work consistently is because of it's multi-click capability.

The multi-click feature results in a delay of sending the single-click message to the hub while the button's hardware waits to determine if a multi-click is happening. To make things worse, due to the way SmartThing's ZigBee message parser works, the messages for double, triple, and quadruple-clicks are not passed on to the device handler to make use of.

So what I have seen in my initial testing is that some normal press & release actions (to produce a "pushed" message using the a4refillpad DTH) are completely missed. The button needs to be held for about half a second for it to decide a multi-click is not happening. Then the "single press" message is sent to the DTH, and a "release" message is sent when the button is released. I think it's next to impossible to expect users to be consistent with how they press the button, so no matter what method is used for generating both "pushed" (for short press) and "held" (for long press) messages, it just won't work 100%.

With that in mind, it's just a matter of deciding which method is more consistent in its behavior, and then put some kind of disclaimer text in the preferences page about the momentary mode feature.

from xiaomi.

As mentioned in my last post on my Pull Request #95, I am going to give up on the runIn() method, because it just isn't reliable due to SmartThing's cloud-executed code. This is super-frustrating, especially since the exact same method for a momentary button function works perfectly on my local-execution-only Habitat hub.

Anyhow, I think we should still integrate the a4refillpad method for the momentary mode function, despite not working 100% of the time (again because of could-execution of code).

from xiaomi.

Just a quick update - The beta testing of the updated round button DTH code using the time difference method to determine pushed vs held is going really well, with positive feedback from the people beta testing it in use with webCoRE.

I've also worked quite a lot at improving the code and enhancing the DTH.

Please see the thread on my Pull Request #110 for more information.

from xiaomi.

Closing this issue, because an update to the "original" button DTH with "held" function was released after extensive beta testing, and by all accounts is working fine.

from xiaomi.