I’d say your second example is more obvious and that you should enforce the wait, then evaluate the light state. That seems the most logical way to process having a wait between two if statements.
The first example could follow the same logic, and enforce sequential flow. The first if statement should not be reevaluated until the while loop has completed.
If you want to allow parallel operations within a single piston, I’d suggest adding in some syntax to explicitly perform this. Otherwise, I think it’s going to be rather confusing. People can always create multiple pistons if they want parallelism, no need to overcomplicate it.
each piston stores up to 500 event timing stats in its own state. Not sure where you can use them. Export them? Sure, it is a possibility. For now, they just make it into that graph…
Finally got primary device commands to actually work - pistons really execute commands (params are not yet parsed). Virtual commands coming up next, when it reaches a more stable/complete reach, I will publish it so you can start enjoying it
Waits are not implemented yet, I am thinking short waits will use pause to wait for that time to pass, longer waits will rely on rescheduling. Hopefully by Monday we have the device commands running and some basic virtual ones. But it’s starting to come together… once that is done, I will concentrate on getting the UI ready (correctly handle triggers and timed conditions) plus advanced parameters on tasks - you will be able to use constants, variables, or expressions in any parameter
v0.0.022.20170305 - ALPHA - Some tasks are now executed. UI has an issue with initializing params on editing a task, will get fixed soon.
Many things still not working, so take this with a grain of salt. Also, waits longer than 5 seconds are not yet handled. Too many waits would also run into a timeout - the scheduling module is non-existent at this time.
But basic stuff is now working:
6e30f16e-cea6-41c7-8b31-b810e62d1452 9:19:05 AM: trace ╔ Event processed successfully (done in 1621ms)
6e30f16e-cea6-41c7-8b31-b810e62d1452 9:19:05 AM: trace ║╔ Execution stage complete. (done in 634ms)
6e30f16e-cea6-41c7-8b31-b810e62d1452 9:19:05 AM: trace ║║ Executed [Kitchen Island Lights].on (done in 20ms)
6e30f16e-cea6-41c7-8b31-b810e62d1452 9:19:05 AM: trace ║║ Executed virtual command [Kitchen Island Lights].wait (done in 255ms)
6e30f16e-cea6-41c7-8b31-b810e62d1452 9:19:04 AM: info smartapp_pause called by smartAppName=webCoRE Piston, value=250, smartAppVersionId=1e756c9a-2e2a-4ec8-984e-ab4b2824a17d
6e30f16e-cea6-41c7-8b31-b810e62d1452 9:19:04 AM: trace ║║ Executed [Kitchen Island Lights].setLevel (done in 4ms)
6e30f16e-cea6-41c7-8b31-b810e62d1452 9:19:04 AM: trace ║╚ Execution stage started
6e30f16e-cea6-41c7-8b31-b810e62d1452 9:19:04 AM: trace ║ Load stage complete. (done in 981ms)
6e30f16e-cea6-41c7-8b31-b810e62d1452 9:19:03 AM: trace ╚ Received event temperature from device Kitchen Sink Leak Sensor with value 76 with a delay of 182ms
You can now force a condition subscribe to events even if triggers are present. This is done by using the advanced options, setting the subscribe method to “always”. Also, a condition can be set to “never” to exclude it from subscribing. You will notice an orange bolt next to conditions/triggers that do subscribe.
Found one disadvantage of the technology used behind CoRE (SE): Devices that the piston has subscribed to will show that piston under the Smart Apps tab of the device. But devices that pistons control won’t… you will however see the main CoRE app listed there, just not the exact piston…
That actually works. By means of subscribing to the “” attribute The piston now shows in the SmartApps tab Thanks for the idea. No fake events, it appears…
Going from CoRE’s inherent asynchronous ways to the new synchronous ways of CoRE (SE)'s, because people really seem to think synchronously LOL, it feels like I’m doing this:
@ady624 I have designed a new logo for CoRE if you are interested. Love to contribute it to the community. Message me and I can give you all the files and AI file too. If your interested.
The piston now shows in the SmartApps tab 
Thanks for the idea. No fake events, it appears…
