CoRE and Piston Rules Engine, first design steps

I can’t seem to get this to fire. Im wanting to use a combo of 3 motion sensors before turning on a light.

If either my son or daughters motion sensor senses motion, AND the master bedroom senses motion, AND time is between X.

Do these things.

It doesn’t fire even if motion is detected. This is used in the event one of my children wake up and walk into the master bedroom. Their rooms are relatively close by so one motion sensor is NOT going inactive before the master bedroom sensor is active.

You have two triggers with an AND in between them. Only one trigger is true at any given time… You may want (trigger or trigger) and time. Or change the second first trigger into a condition, if it fits your requirements.

1 Like

I would write this like this - I think you need a conditional trigger

IF - (Mbr motion changes to active AND (girls motion is active OR boys motion is active) AND time is between x&y)
Then - do that other stuff

1 Like

Can I put in a vote for the three axis sensor - its nice to have something tactile like a cube (with a motion sensor inside) rather than constantly having to reach for your phone. We’d be able to build some pretty powerful pistons off the back of the device’s orientation.

Thanks.

1 Like

Coming soon

I think this is a DTH issue but wanted to mention it anyway as I don’t know enough to troubleshoot code on these.

I have a rule using power level as a condition, this works fine off my Aeon SmartStrip. I created another rule last night, using a ST outlet with the default handler. When the piston is evaluated, it will see the level is less than xx watts, and start the countdown as expected, but every time the smart plug sends an update it resets the countdown in CoRE. I’ve used if less than, between, and less than for x minutes and all do this, even though the level actually never goes out of the range expected for the piston to do it’s thing.

Logging on the smartplug vs my SmartStrip shows nothing different either, both show regular updates with values within my limits but one resets the piston, the other does not.

Can I use piston/core debugging to see what it sees? If so, which debug options should I use?

1 Like

Use a trigger, or use on piston/condition state change. Individual actions have condition state change only restrictions now

1 Like

Yeah, just saw Jason’s post in the Piston assistance thread, I’d seen him mention that before and totally forgot about it. Thank you Adrian!

1 Like

Yes, I had to go in the piston, tapped Done and it scheduled the job for this morning. I did update to the newest code today and I see that I have a schedule set for tonight.

Thank you for this, now I can clean up the variables I was playing with.

I meant to tag you on that question too, glad you saw it…

1 Like

I am implementing a simple Motion activated light. Basically, if motion is detected OR if the light is Turned on manually, then IF no motion is detected for 5 minutes, then Turn OFF. These two pistons seem to do what I want. Is there a preference for one vs. the other (maybe less demand on the Cloud)?

Having an issue with a piston triggering actions when a global variable it is not subscribed to changes. The global variable is @presenceSakowski , and the piston is only set to act when @timeMode changes. Let me know what you need if further investigation is required.

7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: debug ║║░░ Scheduling actions for condition #-1. State did NOT change. 7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: debug ║║░░ Scheduling actions for condition #0. State did NOT change. 7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: debug ║║░░ ♠ Function eval_cond_is for Ashley's presence [not present] is 'present' returned false 7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: debug ║║░░ Scheduling actions for condition #3. State did NOT change. 7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: debug ║║░░ ♠ Function eval_cond_is for Home's variable [Daytime] is 'Morning' returned false 7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: debug ║║░░ Primary IF block evaluation result is true 7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: debug ║║░░ Scheduling actions for condition #2. State did NOT change. 7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: debug ║║░░ ♣ Function eval_cond_is for Eric's presence [present] is 'present' returned true 7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: debug ║║░░ Scheduling actions for condition #1. State did NOT change. 7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: trace ║╚══ Processing event variable, value @presenceSakowski, generated on Sun Jun 12 15:21:34 UTC 2016, about 90ms ago (v0.0.086.20160611) 7d815687-68df-426a-97ac-00c2be2fbaef 10:21:34 AM: debug ╚═══ Received a primary block device event

@ady624

Now that most are using the Dashboard to post pics of their Piston, can you add the Piston type to the Dashboard? Maybe put it behind the first If or someplace easily seen

Thanks again for everything you have done, great app :slight_smile:
Rick

Rick, It’s already in the dashboard… Look closely :eyeglasses:

1 Like

Yes I see that on the main Dashboard, but not once you enter a Piston which is where we grab our screen shots, maybe I am overlooking it

:sunglasses:
Rick

Fellow CoRE enthusiasts… Let’s keep this thread to the alpha stage development and for troubleshooting bugs…

For piston questions and programming please post your questions here.

This app has grown exponentially and we must, for sanity’s sake, keep things in some kind of order.

Thank you

6 Likes

Gotcha! Yeah, it says simple on the first page and then in the piston it’s if and then…

Oops…sorry bout that

User modes. Dang it.

Here’s what I’m planning for:

Allow the user to add user modes in CoRE. Unlimited amount of user modes. Each user mode is described by a name and a list of possible values. So you can create a user mode called “Time of day” and give it values “Morning, Noon, Afternoon, Evening, Night”. Then via pistons, you can set your new user mode “Time of day” to any of the listed values. You’ll also be able to place conditions on the mode (restrictions will learn about these user modes too). Triggers will also exist to run a piston when a certain mode changes.

Any suggestions?

2 Likes

More Stuff?!?!?!?

1 Like