Piston is evaluating triggers I have not set

[Danabw]

I have a piston that appears to be evaluating triggers that I have not asked it to monitor. See piston below and logs below.

I’m using an HEM energy monitor w/custom DTH that has one clamp on the washer, other on the dryer. Washer wattage is crazy all over the place during wash, so I’m using a simple timed piston. Washer starts, wait 50 min (length of standard cycle), notify it’s done.

The trigger for the piston is a “button press” from the Aeon HEM (the DTH code creates one virtual button for each clamp, that can be pressed or held, depending on the watts usage). That works fine.

The problem is that in some cases the DTH sends a “held” signal for the button, and instead of ignoring it the piston accepts it and kills the timer, skips the done" messages and reset of the variable value, and drops down to the final “with” section of the piston that sends the current variable state to me via SMS.

How do I get the piston to ignore the “Held” signal? I only want it to pay attention to the Push.

[Danabw]

EDITED:

OK, maybe the “No operation” action is how I can solve this…

[ipaterson]

This might be a case for using the task cancellation policy of Never Cancel. As long as there is no reason you would want that wait to be interrupted, enabling that option on the if statement will avoid cancelling it.

You may also need to move the SMS into the if to avoid it triggering for false conditions like when the button is held. I think the behavior you are seeing is due to how the button works… Rather than two separate “events” for pushed and held the piston has to subscribe to a single event that provides one of a few possible values (an “enum” with values “pushed” or “held”). This pattern wouldn’t be necessary for all device and trigger types.

[Danabw]

Ah, thanks! That makes sense. I’ll make those changes. That will also help in cases when the cycle is interrupted briefly to add another item. Win-win!

Can I then remove the else if section at the bottom (the one with the No operation action) that is trapping for the “held” trigger? Does this TCP change essentially make the piston ignore any held signals?

Also, you said to set the if statement to never cancel. I was wondering about the practical difference between that and setting the first with statement just below it to never cancel. I assume that if I set the if statement to never cancel then every action under it is protected, but if I set the first with statement to never cancel, just that with statement tasks are protected, correct?