[OBSOLETE] [BETA MILESTONE 1] CoRE (Community's own Rules Engine)

Please share when you get it to work I have 4 similar use case and would be nice if I don’t have to do the work :slight_smile: Loool

PS I am fighting the zwave 101 err, so I cannot do crap these days.

1 Like

The piston state. That’s where all different kind of pistons come into play. The state is calculated differently depending on the piston type. For the latching piston:

State changes to TRUE when state is FALSE and IF evaluates TRUE.
State changes to FALSE when state is TRUE and BUT IF evaluates TRUE

In essence, if both IF and BUT IF are true, the piston state flips (changes to TRUE if it was FALSE and vice-versa), if only one of the two condition sets is true, then the piston becomes the state associated with that one, if none of the two is true, the piston state does NOT change.

With this information in hand, you can plan for state changes.

If you are using measurements that change in time, every measurement change will result in an evaluation. Assuming that the state is currently TRUE, and the IF is true and the BUT IF is false, the state remains TRUE, the THEN actions execute, except those that have “Only execute on piston state change”. Those only run ONCE, when the piston state becomes true.

The TOS (Task Override Scope) does something else. If you have multiple actions controlling the same device (one in the IF’s THEN, one in the BUT IF’s THEN for example), you can choose to “override” all other pre-existing scheduled (pending) tasks for the involved devices, or you can just add to the schedule (by using TOS = None). If the IF THEN says Light turn on in 10 minutes and 2 minutes later, the BUT IF says light turn off, then this will happen:

TOS: None >>> light turns off, 8 minutes later, light turns on
TOS: Action >>> light turns off, 8 minutes later, light turns on (the two tasks were added by two distinct/different actions)
TOS: Local >>> light turns off - the turn on is canceled
TOS: Global >>> same as Local, but across all pistons (if any other piston was planning on doing something with that light, it won’t anymore) - the Global is not yet implemented, acts just like Local

To give you an example on when TOS Action is helpful:
You have an action that is executed on motion becoming inactive: Wait 10 minutes, Turn light off.
Motion becomes inactive, light is scheduled for turn off in 10 minutes. Motion becomes active again, and inactive again after 5 minutes. At this point, there is a scheduled turn off in the remaining 5 minutes. If TOS is Action (or above), that turn off in 5 minutes is canceled and replaced with a brand new one that will run in 10 minutes. Effectively resetting the timer. Use Action if you don’t want to interfere with commands from other actions. The action would then only override it’s own (Action scope) tasks. When using Local, an action asking a device to do a task overrides all tasks for the same device done by any action within the Local scope - the piston itself.

The Cancel on state change is different from TOS because it does NOT require another action to run to cancel it. The piston itself will cancel it if the piston state changes BEFORE the task is due. So this is - in a way - self contained, does not require another action. The TOS will not do anything unless the same or another action runs AGAIN and has the proper scope.

Hope this helps

#documentation

2 Likes

That definitely clarifies things. The TOS examples help me get my head around that, and the “only execute on piston state change” was something I’ve completely overlooked. Will report back my results, thank you again!

1 Like

Yrs, I got it to work. I finally figured out that it was my dth causing all of my problems. Once I received the device and added the such dth it worked great.

2 Likes

So when using TOS Local, and Execute on Piston Change Only, I should not need TCP of Cancel on Piston State Change correct?

They don’t mutually exclude each other.

TCP is a way to cancel an already existing task
OEPSC is a way to prevent a new task from being scheduled
TOS is a way to cancel an already existing task WHEN a new task is added

2 Likes

Can you explain to me in words what you’re trying to do? And I’ll explain the piston you need with the reasons and all.

@bamarayne there was also an error in the “enters/exits” triggers where the old value was not properly cast to the right type, causing that JavaCast error. The numerical triggers need the previous value in order to work correctly (i.e. detect the entering or the exiting or the drop or the raise, etc.)

Ok, well hold on. I’ll try this with another meter that I did not reset the dth on.

That would be awesome!

My office has a motion sensor, smart light, a virtual “disable motion switch” and an Aeon power strip with virtual power outlets for each outlet I monitor.

I want my light to come on when there’s motion obviously, but because I have a workbench out of view of my motion sensor I don’t want the light to turn off if power is above a certain threshold which means I’m actually working in the room. Once power drops below 120w and there is no motion, it’s safe to assume I’m not in there doing anything, so turn off the lights.

I originally tried with two outlets, one specific to my workbench, so there would be two that need to be under a certain limit to turn off, workbench<40w and computer<120w.

I have a second piston, called Game Time that will dim my light to 1% when the computer is using over 165w and the disable motion switch is off.

Everything validates If and Then against the disable motion switch so if I flick that, nothing will turn on or turn off.

What I’ve got so far:

Mike’s Office:

Game Time:

I just changed the piston I posted above to a different power meter and it works with no errors.

I guess it wasn’t just the dth…

1 Like

oops :slight_smile: he he, me again!

Quick question: I’m trying to set up a GOODBYE piston that should activate when the last presence sensor leaves (becomes not present), or routine ‘goodbye’ executes. But when I write it, if I set all the presence sensors leaving as a trigger, they aren’t all executing at the same time…so I write them as a condition…no biggie. But, if I use the routine execution (only available as a trigger) in an OR statement for the first IF action, the conditions (presence) won’t be reviewed until the trigger (routine change) fires…correct? How do I write it so that when the last person leave OR the goodbye routine executes, the piston fires?

@Rigging65, try this:

(
  Any of presence changes 
  AND
  Each of presence is not present
)
OR
Routine executed

This way you get the presence to trigger as well. The condition makes sure you have a true result only if all are away. You can use “changes” or “changes to not present”, it doesn’t really matter. The condition is the one that does the magic.

Also, if you plan on running the routine and then leave the house, you may want to enable the Execute on piston state change only… this way you don’t run the THEN statement twice.

So you have a motion sensor and a power meter. Use OR between them, then AND them against the override switch:

IF
(
    Motion is active
    OR
    Power is greater than 120W
)
AND
Override switch is off

THEN
{your three commands here}

BUT IF
Motion is inactive
AND
Power is less than 120W
AND
Override switch is off

THEN
  Using light
   > Wait 2 minutes
   > Turn off
1 Like

So I don’t need the TCP or state change only toggled?

You should not because you’re using actions on the same device on both the IF and the BUT IF, TOS will take care of it. Experiment…

1 Like

Thanks. That makes sense.

This seems to work exactly as expected. Will update if I find any issues with it. Modified my watt values a bit to fine tune the delay’s. Verified all If conditions trigger the lights on and prevent the light from turning off if any are true. Once all But If statements become true, light turns off per the Then, and cancellation works perfectly.

2 Likes

Sorry bumping this for possible help. I’ve tried additional set ups for pistons and can’t get this to work.

1 Like