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

Thanks for all the replies guys.
I only use modes for away and home. I don’t bother with evenig etc. But hey, thats just me. :smirk:
I have another lux sensor which I am going to use to play with the rules.
I am only using CoRE for very simple rules and to be honest can get away with Smart Lighting and numerous rules but I must confess I am a ‘tinkerer’…

Theoretically yes. But the way I have to two motion sensors located, the second one sees you only about three steps after the first one. In fact, I had one instance while testing it where I went up the stairs very quickly and didn’t get a response from the lights. When I checked the logs, the info from the top sensor reached the hub (or at least was processed) before the info from the bottom sensor. I basically created a physical ‘race’ situation and the sensors were recorded out of order, so the piston thought I was coming down the stairs…and since the lights hadn’t been turned on, the ‘off’ command didn’t do anything. Going up the stairs at a normal rate, I’ve not seen this issue, although I’m sure lag could cause this to occur again.

Since the action intervals on the motion sensors are the same, and the delay between the bottom and top sensors seeing me is literally just a couple of seconds, the second person would have to be in the couple of seconds window…on the ‘inactive’ end of the sensor window…to fail the lights. But it could happen! Life’s imperfect…

I suppose I could build in some conditions to help reduce this likelihood, but unless I see more regular failures I won’t.

1 Like

Only mentioned as I have similar setup and that was my worry!

1 Like

Michael, you can add three tasks to the same THEN statement and restrict each one to a certain mode. Go to each action and look below for Restrictions. That simplifies your IF statements a lot since you’ll be taking the mode out of them and applying it to the actions themselves, just like @Jonpho explained above.

Can someone explain custom commands to me? Not sure what they are and whether I could utilise!? I did see them in RM too, but never got round to investigating further before it was withdrawn.

@Jonpho, real world devices connect to ST via what’s called a Device Type Handler, also known as DTH or sometimes referred to as DH. This DTH is the code that allows communication to the device (commands) or from the device (attributes). Now, the DTH revolves around what ST defined as capabilities (find the list of capabilities here). Each DTH (and therefore the underlying physical device behind it) has to have one or more capabilities that describe the device. Each capability may bring its own commands (for communication to the device) and attributes (for communication from the device). Sometimes, devices can do more than what the limited capabilities offer. One example is the Hue being able to alert or startLoop (self driven color changing loop, ST doesn’t have to constantly order new colors). These two “commands” have no presence in any of the capabilities described by ST, which makes them “custom” commands. Now, CoRE has gone a bit further and pre-defined some of these custom commands so that users have easier access to them. You’ll see that “startLoop” for a Hue light is shown as if it were a standard command, but it really is a “custom” command. Now, CoRE can’t know of all possible commands of all devices, but the device itself can list the commands it supports. This is how CoRE gains access to the list and it will display the standard (including CoRE pre-defined custom commands) with an empty dot, virtual commands (commands that augment ST, but are not device based, or combined commands such as Toggle and Adjust) with a full dot, and the “custom” commands with a little empty arrow up sign (someone called it a house, I guess that describes it better). This allows you, the user, to use commands that are not understood by the ST ecosystem and that wouldn’t be available to SmartApps that abide by the capabilities list (Smart Lights, for instance). One thing to note here, is that many of these “custom” commands take parameters. This is unknown to CoRE and possibly to the user as well, so a little bit of documenting needs to be done before one can use that custom command. CoRE now allows you to add simple parameters to the command, but you’d have to know what parameters (data type and value), their order, and most importantly, their meaning. But at least you have a way to use it :slight_smile:

NOTE: Same goes for “custom” attributes. These are pieces of information that the device itself can provide, but no capability describes yet. Just like with custom commands, you’d have to know what the attribute does and how to interpret its values. So far, CoRE assumes all custom attributes are strings and compares them as such.

2 Likes

I’ve updated my previous two examples to use Latching vs Simple as they allow for a more robust “motion active” response. Here’s a third example for my bedroom:

Piston Mode: Latching

If…

–Bedroom Motion Sensor -> motion is active

AND

(Mode is one of Home, Evening)

AND

(Each of Bedroom Light, Erin’s Lamp, Mike’s Lamp or Bedroom Light Motion Disable -> Switch is off)

Then…

If mode is Home
–Using Bedroom Light

  • Set Level to 100%

If mode is Evening
–Using Bedroom Light

  • Set Level to 10%

But if…

–Bedroom Motion Sensor -> motion is inactive

Then…

–Using Bedroom Light (Cancel on piston state change)

  • Wait 10 minutes
  • Turn off
  • Turn on after 1000ms
  • Wait 1 minutes
  • Turn off
3 Likes

And a multi mode single light rule for three different level’s throughout the day:

Piston Mode: Latching

If…

–Upstairs Hall Motion Sensor -> motion is active

Then…

If mode is Home
–Using Upstairs Hall Light

  • Set level to 100%

If mode is Evening
–Using Upstairs Hall Light

  • Set level to 10%

If mode is Night
–Using Upstairs Hall Light

  • Set level to 1%

But if…

–Upstairs Hall Motion Sensor -> motion is inactive

Then…

–Using Upstairs Hall Light

  • Wait 2 minutes
  • Turn off
2 Likes

This seems to work easily for multidoor/motion light activation. My hope is someone can vet these for accuracy and put them in the Wiki maybe?

Piston Mode: Latching

If…

–Any of Door1, Door2, Door3

OR

–Garage Motion Sensor -> motion is active

Then…

–Using Garage Light

  • Turn on

But if…

–Garage Motion Sensor -> motion is inactive

Then…

–Using Garage Light (Cancel on piston state change)

  • Wait 5 minutes
  • Turn off
  • Turn on after 1000ms
  • Wait 1 minutes
  • Turn off
2 Likes

(Mode is Home OR Mode is Evening) can be replaced with Mode is one of [Home, Evening]

2 Likes

Looking for some help on what seems like it should be simple, but isn’t quite working correctly.

I want my front door lock to lock if the front door has been closed for 5 minutes and the door isn’t locked. The 5 minute timer should start from when the door closes, and should reset if the door opens and start again from zero once the door closes.

I’ve tried a couple of options but the door always locks immediately on close; it doesn’t wait the 5 minutes.

There are SO many options to choose from in this app and unless I’m mistaken, there’s no documentation or user guide, hence my post here.

Appreciate any help.

Thanks.

Most likely, you added an action with the Wait and a second action with the Close. Add both to a single action, you can keep adding tasks to the same action, so add Wait 5 minutes, Close to one single action. Also enable cancel on piston state change for that action.

Thanks for the reply. Yes you’re correct, I had the Wait and the Lock as separate actions.

I don’t see how to add the Wait and the Lock tasks in the same action. It seems you can only access the Wait option if you turn on the ‘Control location mode, smart home Mongol and more’ option, which then removes the ability to add the Lock task (or any of the other ‘standard’ tasks.

Ami missing something?

Control the lock. You can add any location-related, including Wait tasks in there. The “Control SHM, etc.” is just a placeholder to allow those actions without having to control any device.

@ady624 - do you actually expose all debug information eg scheduling timers, removal of timer due to trigger/condition being met while timer expires, re-adding of new timer as well as cancellations by triggers/conditions? in a way this can be tracked? or is this even possible? so it can be fully traced in the event you want to debug what the issue is? eg giving jobs associated pointers or anything like that?

Not sure I get what you mean, but if you enable debug and allow debug messages too, your logs will be flooded with info… it will be so flooded it will skip lines…

Ah ok got it, thanks. Does this look right (I wont be able to test until tonight)?

You enabled the “execute on piston change only”. Nothing wrong with that, but look down for Task Cancellation Policy and enable that one… cancel on piston state change. That will ensure that if the door is opened within those 3 minutes, the lock is cancelled. You don’t want the door locking while open…

OK thanks. And disable the “execute on piston change only”? Whats the difference between the two?

The “Execute on piston change only” is useful when you have more conditions, all working towards the piston state being true or false. If you have three conditions with OR between them, if anyone is true, your piston is true. The difference is that if you enable that, you’ll only execute the action once, when the piston changes from false to true. Any subsequent evaluation that keeps the piston true won’t run the action. In your case, you’re okay, there are only two cases, open and closed, and the piston follows them.