CoRE Piston condition evaluation true but not executed


I have a garage where I put in a motion sensor, a door sensor and a light. I want the light to go on when the door is opened or when there is motion. I want it to turn off when the door is closed and there has not been motion for 2 minutes.

Rule 1 (On), Basic mode:
motion changes to active
contact changes to open
light turn on

This works

Rule 2 (Off) Basic mode:
motion did not change in the last 2 minutes
motion is inactive
contact is closed
light turn off

The strange thing is that the rule evaluates to true but the action is not executed.
If I simulate the piston, it is executed
If I only open the door without trigger the motion sensor and close it again, the piston is executed and the light goes off
If there has been motion however, it is not executed, even not after the motion has stopped for more than 10 minutes. I checked several times, it does say 2 minutes.
I checked the motion sensor recent activities when I thought it should have turned off the light and the sensor is in motion has stopped and it has been there for more than 2 minutes (it does not even do anything after 10 minutues).
The piston is RUNNING, current state: true, CPU:0% MEM:10%

Any help much appreciated. After some basic playing around with CoRE, this is my first ‘real life’ implementation.

(Robin) #2

Can you post green snapshots of your actual pistons rather than typing in the summary… this will help with debugging as we can check things like event subscriptions.

You might have better luck with a single piston such as:

motion IS active
door IS open
turn on light
wait 2 minutes
turn off light


Thanks for the reply. I will try to get the screenshots. Meanwhile I tried your suggestion but the result is not what I want. With your suggested piston, the light goes off 2 minutes after there is motion or the door is opened. I want the light to go off if the door is closed and there hasn’t been any motion for 2 minutes. I just tried your suggestion and it left me in the dark after 2 minutes :slight_smile:

(Ron Talley) #4

This is what I use.

This also covers if the door was opened but no one actually went into garage, if for some reason a trigger didn’t work and, regular turn off after 3 minutes of no motion.


My pistons. I use normal CoRE, net webCoRE yet.


This looks like what I want. Could you post the code as text please instead of an image?


Time for someone to switch over to webCoRE :slight_smile:

He can’t change the format of the Piston. That’s how it’s formatted directly in webCoRE. If you install webCoRE instead of the old CoRE, you can restore his Piston to your WebCoRE with the 4 digit code listed and then modify it to your liking.

(Robin) #8

Ahhh… you’re using old CoRE lol… it has a different default cancellation policy so yes, you would have been left in the dark!

Either upgrade to webCoRE or scroll to the bottom of the wait command in old CoRE and change TCP to ‘on condition change only’

(Ron Talley) #9

Just like @WB70 mentioned and is why one of the many reasons to switch over to webCoRE, well and many other wonderful reasons!

I also define my devices at the top of the pistons so only thing you would have to do is select the devices and they will populate wherever those devices were throughout the Piston. Then its just a matter of tweaking for your needs.

I still have PLENTY of regular CoRE Pistons that work just fine.


Also be careful to check that you have the red lightning bolt next to each “rule” within your piston. It looks to me like if you have both of those statements in the same piston the first would work and the second wouldn’t because there are only conditions and no triggers. If they were in separate pistons, webcore would recognize the conditions and use them as triggers. Basically, in WebCore, you have to have at least one trigger (red lightning bolt) per state ment or it won’t fire.

(Robin) #11

Actually… in webCoRE a bunch of conditions will behave as triggers, when no tigger is assigned.

So two seperate IF statements, each containing conditions, will fire side by side no problem.


Yeah…isn’t that what I said? If both of those statements are in the same piston, the second would have no triggers. If they were in separate piston, it would because it translates the conditions into triggers.

(Robin) #13

Yes… if you assign a trigger, the conditions won’t subscribe and only the trigger will fire the piston, the piston will THEN evaluate the state of the conditions on firing.


This is what i was trying to get at, since the OP stated that he has two statements.

See, no lightning bolt on the second statement.
You can have more than one statement per piston but your conditions to triggers functionality only works when there are no triggers in the piston. Which is exactly what i said. Isn’t it easier to just use triggers only? I got very confused when trying to use the conditions becoming triggers idea and it ended up causing a whole bunch of issues.

(Robin) #15

On the contrary… I almost exclusivley use conditions… triggers cause issues with ‘waits’

If I want a part of a piston to act independently I use ‘on events’


Yeah…but you are a LOT more experienced with WebCore than 100 users combined!!! LOL I’m talking about for us mere mortals.

(Ron Talley) #17

Took me a while to get a grasp on triggers vs conditions and how to use them effectively. I have man Pistons that only use conditions and many that use a combination of triggers and conditions.

If I can write a Piston and avoid triggers I go that route first.

@RobinWinbourne is a beast when it comes to webCoRE!

(Robin) #18

Shame I don’t have a hub or any devices lol… my tennants certainly appreciate my setup though!

(Ron Talley) #19

I forgot all about that! Wow, you still on the outs? How much longer?


I couldn’t agree more. I don’t if “beast” does him justice though. Maybe the Q of WebCore (I’m stuck on Star Trek references today).

I would say that avoiding triggers all together might work for you but not everyone’s brain works that way. When I started writing pistons it just made a lot more sense to me to use triggers only. That way I never had to wonder where the little lightning bolt was gonna show up when I hit save. If you use it more, and can reliably figure that out in your head, then conditions only are probably really easy to use. But again, not all of us are THAT smart and I’ve seen people get caught up on this a LOT. So, it might work easier for some people to use Triggers only instead.

I dunno…when I started using WebCore, the documentation made a big deal out of the difference between conditions and triggers…but then conditions can be triggers? My head just started to hurt.