Oh by the way, you need to enable them - there is a filter like icon on the top bar - tap that to show the “when” clauses - those are the restrictions…
This is awesome, you are the man!!! Does this also mean a piston will execute at this point or have to wait for that?
It executes alright, but lacks the logic that does anything - one step at a time, patience is key 
This is the handler code so far:
def handler(evt) {
Map rtData = parent.getRunTimeData()
//todo start execution
}
It’s lacking a few thousands of code lines
2 Likes
Keep it going, there is a light at the end of the tunnel.
I think it looks fine just like that… I bet it’s fast!
Well, talking about speed - I have taken measures to prevent real device IDs from being given away outside of the ST cloud - the dashboard only sees device IDs of this form :4f3e810004b369a0ee8b687917bf9eaf: (yeah, it’s got : at the start and end - helps me anonymize them easily) - to do so, I have to calculate an md5 hash of a string in Groovy with my 100+ devices all selected in the main app, it was taking about 2-3 seconds to calculate all those hashes. I had to cache them into state and made it blazingly fast - I can issue an evaluation of an expression from the dashboard and that loads that runtime data (which was taking the 2-3s) and evaluates the expression in less than 300ms. About 220-260ms on average.
9:28:01 PM: trace ║ Evaluating expression (289ms)
9:28:01 PM: trace ║ Generated run time data (268ms)
The evaluating expression time includes the generate runtime data. I think it’s fast enough, but a key element here is: only use devices you need. Any additional device becomes overhead.
2 Likes
Probably a dumb question, I started playing with CORE about a month ago, and I’'ve liked it a lot. Pretty cool. How stable would you say CORE (SE) is compared to CORE. I’m thinking of swiching. Can you run both at the same time?
CoRE (SE) doesn’t do anything yet… It’s a ways off
1 Like
CoRE (SE) is just learning how to breathe… it’s more powerful, but less ready
Thanks!. Appreciate it. I’ll back off. I installed it and started trying to play with creating a piston or two.
You can play with it, it will soon start actually doing things - but it’s still just ALPHA… so in terms of stability, not near close to CoRE.
2 Likes
You got my
CoRE (SE) is coming to life 
events now run the pistons, they even execute their statements, evaluate conditions, but not yet execute action tasks. But I’m slowly getting there, couple of hours per night…
5 Likes
Okay, so last night I ran into this puzzle:
What will happen if Pinocchio says, “My nose is about to grow.”?
Oh no, wrong paste, sorry. Here’s a conundrum, given the following sample piston:
execute
if (Door contact is open) then
send notification "Door opened"
end if
while (Light switch is on)
do
send notification "Light is on"
wait 5 minutes
end do
end execute
Let’s start with the door closed and the light off. Turn on the light. IF will be false, skipping over to the while, light is on, send notification, wait 5 minutes. At this point, the piston would be suspended, scheduled to re-execute in 5 minutes (with instructions to resume from the wait 5 minutes line). So far, everything is synchronous, so nothing out of the ordinary. But now, let’s open the door. What happens next? The piston never ended its execution, it’s awaiting the 5 minute mark to resume… does it run again? Should it send the notification, even though it’s in the middle of the while loop, waiting? Would that just reset the while loop and start the execution over again? Which means, the notification will be sent again about the light being on, even though it’s been less than 5 minutes?
My best bet so far would be that in the event that the piston is stuck in a loop, waiting, nothing before that loop should execute and the only thing that can move the piston forward is an event that would cause that loop to become false. Therefore, the door opening/closing would have no effect whatsoever until the light turns off, allowing the piston to finish its execution and get ready for a new one. This way, at least, prevents most weird interactions. I could also add a parameter that allows “parallel executions” which would then start a new “thread” if a new event happens. Not to mention, things get more complicated with a while inside a while and given the open ecosystem that the piston is, you can have 10 layers of those while loops… what to do, what to do…
And to add to it, here’s another example:
execute
if (Door contact is open) then
send notification "Door opened"
end if
wait 5 minutes
if (Light switch is on) then
send notification "Light is on"
end if
end execute
Open door. 1 minute later, turn light on… what happens then?
1 Like
Personally I would want to know if the door is opened, the light is just informational kibble; ± a few minutes for a message is not a deal breaker.
If the wait is queued I would cancel the request and start the piston over again with a door open alert and a fresh 5 minute light timer.
Thank you. But how about if you reverse the light and the door? Have the light in the initial if and the door in the while loop… then what? 
This may be one of those things where you just have to state the operational precedence in the docs and a caveat, "If you do this then all queued commands will be cancelled and re-evaluated."
Kinda like BEDMAS
But you don’t always want them to be canceled…
Consider this one:
if Door is closed then
wait 5 minutes
while (door is open)
do
send notifications 'door is open'
wait 5 minutes
end while
end if
If the door opens within 5 minutes of it being closed, then send a notification every 5 minutes for as long as it stays open. In this case, whenever the loop is active and the door is closed, the loop will exit, but the whole cycle is not yet restarted because the initial IF wasn’t reevaluated as part of resuming the loop. This is where you would need to have that just reset and start over.
Now consider this one:
if (door is open) then
while (door is open)
do
send notification 'door is open'
wait 5 minutes
end while
send notification 'door is now closed'
end if
In this scenario, if the door opens, the loop is started and that will run until the door closes, triggering that last notification. If the “door closed” would issue a restart, you would not get the “door is now closed” notification anymore…
This is a hard one…
