CoRE and Piston Rules Engine, first design steps

Each group has its own individual actions. Since each group’s conditions is slightly different than all of the others, than that group will be the only one to actually fire.

I went with a slightly different methods using the and-If piston type.

2 Likes

He could also use time is after 6:30pm :wink:

1 Like

I did that as well - however it seems like with individual actions its easier to troubleshoot if things go wrong … I got well someone called it complex rules and this makes it simple to track really and it works fine … but agree - there are multiple ways to solve it - hence I said here is one option :slight_smile: starting to liking it really once you get your head around …

@ady624 - how does the recent change for 0-360 impact my existing rules - is there a table that shows the conversion or do I just need to divide by 3.6 to get the right HSL code?

3 Likes

If you entered hues in % then multiply by 3.6 to get angle

I like that. If (this) or (that) or (that) Then [nothing]. It’s like, if this, then forget about it… Anybody wants me to create a command that would execute a random task on a random device? Just for fun? :slight_smile: Or a “Fail now” command? :slight_smile: Or the random version, “Fail sometime today”, of course… I can only imagine the irony of the “Fail now” command failing to execute…

2 Likes

@ady624 basically its the missing capability in any ST app - unlimited options including action … very simple and very effective for my use-cases … unfortunately I now need to remove all ST outlets and replace them with Aeon Labs to do more advanced use-cases …

@r4ndom - the ST outlets are also configurable. The DTH does not expose the configuration options, but they exist. Look around for an enhanced version of the DTH…

Dude, that’s already built into the ST platform! No need for redundant programming!

2 Likes

To quote a Mel Brooks movie: “Yes, but unlike other Robin Hoods, I can speak with an English accent.”

The only difference on my implementation is that I could, technically, fail failing. Whereas ST doesn’t have that extra level :slight_smile:

@r4nd0m - try this:

Go to your Device Type Handlers in the IDE. Add a new device handler from template, find the SmartPower Outlet. Name it whatever you want, I like calling it “Enhanced (original name)”. Find the powerConfig method and find these lines:

//power config for devices with min reporting interval as 1 seconds and reporting interval if no activity as 10min (600s)
//min change in value is 01
def powerConfig() {
    [
        "zdo bind 0x${device.deviceNetworkId} 1 ${endpointId} 0x0B04 {${device.zigbeeId}} {}", "delay 200",
        "zcl global send-me-a-report 0x0B04 0x050B 0x29 1 600 {05 00}",                //The send-me-a-report is custom to the attribute type for CentraLite
        "send 0x${device.deviceNetworkId} 1 ${endpointId}", "delay 500"
    ]
}

Spot that 0x29 1 600? Leave the 0x29 alone (represents the data type of the power value sent to the DTH). The next two numbers are of interest. 1 is the minimum reporting time in seconds, 600 is the idle report time (if nothing changes, it reports every 600 seconds, that’s 10 minutes). Change that 1 to 30 to begin with and then save. Publish. Go to Devices and find one of your outlets. Edit it and change its handler to the one you just created. Then go to the device on your phone and click settings, where it shows the label for the device and click Done. Then check to see if it now reports every 30 seconds. Then, of course, work that 30 second interval to your liking. Let me know how it worked out :slight_smile:

NOTE: you only have to change your device’s handler once. However, after changing the code a second time (say you want 15 instead of 30), you have to Publish and then go to your device and click on the settings gear, then Done.

So it turns out it’s even worse, not only that the default is 1 second, but someone at ST actually MEANT it that way, since they forcefully set it to 1 second every time you configure your device…

Click here for an explanation of what those numbers mean, courtesy of @JohnR

3 Likes

Many thanks for this, another piece of CoRE falls into place.

Following on from this, I also set the home to Night Mode, This will set at Midnight on the rare occasion we are out late. However, night mode is normally selected via a goodnight routine by pressing a button on my harmony remote. Will the above rule just switch it straight back to Home evening, if I don’t amend it?

When the goodnight routine runs, a virtual ‘goodnight’ switch goes on for 10 minutes, this enables me to disable certain light rules and override them with a ‘goodnight’ light rule. Once the goodnight switch goes off then lights will run ‘night’ rules if activated.

Could i use the fact that the goodnight switch has ‘turned’ on or off in last ‘x’ number of minutes to help?

You mean, “was on for less than 10 minutes”? Try it and let me know - it should work, although better routes may exist. Variables are the big missing piece right now. Namely setting a variable (which I am working on) and the Variable condition, where one could test a variable. Also Variable triggers, that will only work with @global variables, allowing pistons to “watch” variable value changes and act upon that. Once these three pieces are done, you’ll find out new ways of doing things. And (feel the urge to) delete all pistons and start over with an even more complex routine :slight_smile: Ye be warned.

:joy:

hmm if I get this correctly its not working really - the 600 is a timeout if there is no activity - but I need to limit the amount of messages sent when there is activity - for the Aeon Labs I was able to add 50w changes, 25% change before sending a changed message - I cant seem to find that in this code …

lol - message to self - read properly … will give it a go …

1 Like

This is just awesome. When it goes Beta and some documentation is ready I plan to jump in. At this point I am just looking to make simple if>then type rules so hopefully the simple mode will be simple enough for me to understand!

1 Like

Ok, for this section

OR

( Time is between 6:00pm and midnight
AND Each of the presence sensors present)

AND ‘Goodnight Switch’ was not on for at least 5 minutes

→ when TRUE {set mode Home Evening}

how does the bold section work, was not on for at least 5 minutes, when, last hour, last 24, ever…and when does it reset for rule to work next night?

I could used the did not change option but you can only select upto 60 minutes, i would need longer to cover all scenarios, as we quite often go to bed more than 60 minutes before midnight.

OR

( Time is between 6:00pm and midnight
AND Each of the presence sensors present)

AND ‘Goodnight Switch’ did not change in last 60 minutes

→ when TRUE {set mode Home Evening}

Well, depends on what you want you want to do. You can use the was on or the was not on and within each, you have for at least or for less than. Each combination of two can be done with a combination of the other two, so they’re kind of redundant, but there’s a reason: emulate the user’s thinking, let him think the way he wants rather than force him to negate things because he thinks the other way.

So switch was not on for at least 5 minutes means that the condition will become true 5 minutes after the switch is turned off. Is that what you want? Consider the “was on for at least 5 minutes” when logically evaluating the condition and then negate it to match the “was not on for at least 5 minutes”

Got you!, I just need a longer option than 60 minutes!

Which condition? The was? That’s the problem. Was looks at event logs - I am trying to keep resource usage to a minimum. What are you trying to achieve? The “did not change” is a trigger and I can extend that one, but the “was” I probably won’t.

Ok, having a problem here.

Using And-If piston mode.

Primary If -

Primary Then - blank

Secondary If -

The way I want it to work - the primary IF must be true AND the secondary IF must be true before the secondary group actions will occur.

What is happening - primary IF is false (pump is less than 1, pumping is off, master bedroom override is ON, motion is not active) this should be false anyway. Secondary IF is true, secondary group actions are firing when the motion sensor in primary becomes active.

It seems like it is ignoring the other the conditions in the primary IF.

What am I understanding incorrectly?