Possible to abort a piston execution if piston gets stuck waiting at a semaphore?


#1

1) Give a description of the problem
I’m using a piston to have any number of IKEA Symfonisk Controller knobs control volume for various home audio devices. When being rotated, the knobs send out repeated Zigbee events to indicate that they are in the process of being turned in one direction or the other. The piston looks for these changes and executes, aligning the volume with the level of the knob. There are a lot of events, so one of the piston executions will occasionally get stuck waiting at a semaphore (that part is expected), then trigger 10 seconds later, causing the volume to jump erratically back to some intermediate level.

2) What is the expected behaviour?
I’d like to be able to abort any piston firing that gets stuck “waiting” to avoid weird jumpy behavior in volume.

3) What is happening/not happening?
For example (see logs), events fire that set the volume to 42, 39, 36, 33, then end at 30. The 39 event gets stuck waiting, but the 36, 33, and 30 events fire without issue. Then, 10 seconds later, once the semaphore wait is over, the 39 event fires and volume suddenly jumps back up to 39 from 30. Ideally, the 39 event could be aborted since subsequent events have eliminated the need for it to execute.

**4) Post a Green Snapshot of the piston!

5) Attach logs after turning logging level to Full

4/6/2020, 3:55:00 PM +522ms
+1ms ╔Received event [Volume 4].level = 39 with a delay of 49ms
+10148ms ║Piston waited at a semaphore for 10039ms
+10187ms ║New knob level: 39
+10198ms ║New volume: 0
+10210ms ╚Event processed successfully (10210ms)
4/6/2020, 3:55:09 PM +401ms
+1ms ╔Received event [Volume 4].level = 30 with a delay of 52ms
+138ms ║New knob level: 30
+150ms ║New volume: 0
+161ms ╚Event processed successfully (161ms)
4/6/2020, 3:55:06 PM +770ms
+1ms ╔Received event [Volume 4].level = 33 with a delay of 50ms
+134ms ║New knob level: 33
+144ms ║New volume: 0
+155ms ╚Event processed successfully (155ms)
4/6/2020, 3:55:02 PM +158ms
+2ms ╔Received event [Volume 4].level = 36 with a delay of 54ms
+135ms ║New knob level: 36
+145ms ║New volume: 0
+156ms ╚Event processed successfully (155ms)
4/6/2020, 3:55:00 PM +391ms
+2ms ╔Received event [Volume 4].level = 42 with a delay of 55ms
+144ms ║New knob level: 42
+155ms ║New volume: 0
+168ms ╚Event processed successfully (168ms)


#2

You can usually avoid this entirely by changing your trigger to:

IF Dimmer's level stays unchanged for 1 second

This way, you spin the dial, wait a second, and the piston will run.
If you need more change, just repeat.


#3

I originally had it set up a similar way (I actually set up the DTH to measure start and end time and only sent a level change once rotation had stopped) but I was hoping for a more “gradual” change to volume, rather than the jumpy changes that that would get me.


#4

This sounds wise. Keeping the “spam” out of the pipeline will reduce the triggers here in webCoRE. :+1:


Considering all the hopping between middlemen, it is good to have a goal of getting updates within a second… but in some cases, it is often more like 1.2 - 1.5 seconds. (depending on many variables)