CoRE Piston Triggered by Momentary Button Tile Creating Inconsistent Results

When I trigger a CoRE piston using the ON event of a Momentary Button Tile (virtual device) sometimes nothing happens (the ON event seems to be ignored).

I noticed that a “Momentary Button Tile” (virtual device) generates an ON event and an OFF event when it is tapped. I have a “Basic” CoRE Piston that is triggered when a virtual momentary button tile “changes to ON”. The actions for the ON event are not successful about 15% of the time. When the piston action is successful I notice in the debug logs that the OFF event is processed by the piston before the ON event. When the piston action is not successful I notice that the ON event is first, and the OFF event that happens next seems to interrupt the processing of the ON event.

Here is the logging for a time when the ON action did not trigger as expected:
[NEWEST EVENT AT THE TOP]
7:35:18 PM: trace Piston done in 606ms
7:35:18 PM: trace Task processing took 64ms
7:35:18 PM: trace Removing any existing ST safety nets
7:35:18 PM: trace Rescheduling time triggers
7:35:18 PM: trace Processing tasks (v0.3.160.20161014)
7:35:18 PM: trace Event processing took 217ms
7:35:18 PM: info Basic Piston changed state to false ?
7:35:18 PM: debug Primary IF block evaluation result is false
7:35:18 PM: debug Function eval_trg_changes_to for Ari Pop - Hold’s switch [off] changes to ‘on’ returned false
7:35:18 PM: debug Event eligibility for the primary IF block is 2 - ELIGIBLE (triggers required, event is a trigger)
7:35:18 PM: trace Processing event switch for device Ari Pop - Hold with id [omitted], value off, generated on Tue Dec 06 01:35:18 UTC 2016, about 163ms ago (v0.3.160.20161014)
7:35:18 PM: trace Received a primary block device event
[HERE IS WHERE PROCESSING OF ON EVENT SEEMED TO BE INTERRUPTED BY OFF EVENT]
7:35:18 PM: trace Installing ST safety net
7:35:18 PM: trace Rescheduling time triggers
7:35:18 PM: trace Processing tasks (v0.3.160.20161014)
7:35:18 PM: debug Event eligibility for the primary IF block is 2 - ELIGIBLE (triggers required, event is a trigger)
7:35:18 PM: trace Processing event switch for device Ari Pop - Hold with id [omitted], value on, generated on Tue Dec 06 01:35:18 UTC 2016, about 140ms ago (v0.3.160.20161014)
7:35:18 PM: trace Received a primary block device event
[OLDEST EVENT AT THE BOTTOM]

Is this expected behavior for CoRE? I get that if an event occurs followed by the opposite event it is often the case that processing of the first SHOULD be interrupted. It seems like that is happening. In my case, nothing is intended to happen for the OFF event and therefore I do not want my ON event to be interrupted. Is there a way to override interrupting the processing of the ON event in CoRE?

Or, is there a type of virtual button that only produces an ON event on tap, and no OFF event?

Unless the community has a better answer, I will probably use a simulated switch and use the action of the piston to turn the switch back OFF when it has been turned ON. This doesn’t feel as clean as using a button and there may be problems with this extra bit of complexity that I have not considered yet.

Mainly I wanted to post information about this issue because it was a tough one to track down and it seems like a configuration many people would attempt to use.

Thanks!
Mike

I’m not sure if this will solve it, but you might try changing the Task Override Scope from Local to None in the action. Worth a shot while you’re waiting for someone more knowledgeable to come along :wink:

Willing to try anything, I went ahead and tested changing the Task Override Scope to None. The change did not have an impact. I’m still experiencing the same problem.

My understanding of Task Override Scope, which could be flawed, is that it controls if a newly created Action should cancel Action(s) that were created in the past (but are still on an execution queue or scheduled for a future time).

My theory is that Task Override Scope is not relevant to this problem because only the ON event creates Actions. The OFF event passes through the piston without triggering any conditions, it just makes the Piston state go from true to false. Unfortunately, I don’t think (based on the logs) the ON event has enough time to trigger its Actions before being interrupted.

I don’t have a complete understanding of all this so please call me on my bs. :slight_smile:

Can you post an actual screenshot of your piston?

Does your piston have any ELSE actions? If so, the OFF event is most likely to be the culprit since it will run the ELSE actions which most likely override the THEN actions. The TOS defaults to local which means, when an action schedules its tasks, it deletes any previously scheduled tasks for the same device, tasks that were requested at any time in the past and have not been executed yet. If this is the case, change the TOS for the ELSE actions to either Action (action deletes only tasks previously scheduled by the same action) or None.

A picture of the piston would help.

As for the two events being so close to each other, ST will spawn two instances of the piston, each dealing with its own event. Execution is not interrupted for any of them, although certain race conditions may happen where saved state is overwritten by the last instance to finish. Scheduled tasks reside in the state.

Here are screen captures of two pistons that both have the problem described above. I have a physical Logitech Pop button that is either double tapped or held to activate “Ari Pop - 2 Taps” or “Ari Pop - Hold” which are both virtual Momentary Button Tiles. Each Piston Mode is “Basic”, no “Else”, etc.

I appreciate the knowledge shared. Note that I have implemented new logic that is working for me. I really struggled with the problem above, however, so I wanted to share the information I learned.

Here is the log from a time the “Ari Pop - Hold” piston did not run the intended actions (failed).

Here is the log from a time the “Ari Pop - Hold” succeeded.

Workaround Solution

Regarding my question about virtual devices… I found that the following virtual devices are both recognized as “button” devices by CoRE and will produce a “pressed” event without producing an “OFF” event:
Simulated Button
Simulated Minimote

Those would normally be good alternatives to the Momentary Button Tile that produces both ON and OFF events on a single press. Unfortunately, they did not help me because the Logitech Pop device I am using supports triggering “switch” but not “button” device types. As a workaround I created “Simulated Switch” virtual devices and setup Logitech Pop to toggle the simulated switches. I setup my piston to trigger on condition “Changes” (regardless of if changing to ON or OFF).

I would be curious to know the source of the original problem, however, my current needs are now met. Thank you!