Normally when a subscribed device event or a timer event is received the piston will execute rather like a script, starting at the top. However timers (every blocks) and on events blocks are different. They are self-contained. So they execute independently of the “normal” parts of the piston. Personally I’d avoid using on events unless you really, really need it and let the normal piston triggers handle things.
Triggers are not quite they might appear to be. A piston will, by default, subscribe only to the device and time events that might affect the result of evaluating trigger conditions (if there aren’t any trigger conditions it will consider the ordinary conditions). That is pretty much all a trigger means. However many/most of the trigger conditions are evaluated based on the event that is being processed. So, for example, the trigger Heater switch changes to on can only ever be true if the piston is currently processing an event from the switch attribute of the Heater device. If you call the piston by URL then that is why the piston is being executed, not because the switch has changed. So that is why you can’t use the trigger conditions.
I am little surprised by the structure of your piston in the original post. The switch and case on line 20-21 are OK, though it would be easier to use a basic if {{comparison}} then {{do something if it is true}} end if. The while block creates an infinite loop that will last until the piston runs out of execution time (fortunately only twenty seconds). It is pretty rare to see when true and when false being used. In the last two or three years I think I’ve only see one piston using them that actually needed them. You again simply need an if ... then ... end if block.
Your log in the original post is actually showing a ‘recovery’ event. At regular intervals, and whenever another piston executes, webCoRE checks to see if any piston expecting a timer event has yet to receive it thirty seconds past its due time. If it finds one it sends that piston a recovery event so that it executes. This may make your piston do sensible things or it may make your piston do things you wish it hadn’t, but the key thing it does is to allow your piston to schedule its next execution as that is something pistons do for themselves (there is no ‘cron’ like mechanism, pistons use a single timer set for when they should next run). Without it they may just ‘stop’. Sometimes events get delayed inexplicably or just disappear, but sometimes things are just broken.
