CoRE and Piston Rules Engine, first design steps

Yep…

1 Like

Uh oh! ! ! ! @ady624… The challenge… Make the binary system behave in a non binary way! Should be easy!

2 Likes

1 watt, is this for 120 Volts AC?
If so that’s a pretty small load, can it even read current that low?
Have you tried increasing your threshold (say 5 watts or something)?
I think the WeMo defaults to 5 watts as its threshold.

1 Like

This is an aeon dsc6106 switch. It can detect 0.1 watts.
I’m also using the iris smart outlet with zigbee and zwave repeater.

Both can detect the power draw above and below 1w.

1 Like

Yep same here - what I did though as I had the ZLL/Hue and the ZigBee RGBW device handler chosen by my bulbs - I set all to ZigBee RGBW and reset/re-attach them not removing them just re-attach them, ID changes but that was easy to deal with - no errors since …

1 Like

I am using the SmartPower outlet as a power meter but what I did, I changed the device handler to report less frequently - on a minute basis - and use a vSwitch that is being turned on/off when the condition changes - reduces fluctuation and reports less messages - so the piston monitors the other conditions and the virtual switch - works flawlessly for me now prior it was a matter of too many changes and on/off …


What you need to do though - after changing the power meter device handler reset and re-attach the meter - not removing it from ST so it takes all settings correctly …

1 Like

Is this in a normal run or only when simulating?!

I already gave @bamarayne the solution:

Latching piston

If door changes to open and (extra conditions) then
Turn light on

But if (same exact conditions as for If)
Wait 1 min
Turn light off

Why do you need the light to turn off at door close? You are walking in already… The piston above would turn the light off with a delay after you open the door to come in.

An alternative solution is

Simple piston
If door is open >>> when true set number variable openDoor = 1 - {openDoor}
and
time is between sunrise and sunset >>> when true set variable openDoor = 0 (this ensures we do not turn the light on at day)
and (
Door is open
and
variable door is 1
) >>> when true turn light on
And (
Door is closed
And
Variable doorOpen = 0
) >>> when true turn light off

They should both work :wink:

UPDATE: see below for a working example

v0.0.04f.20160527 (note: problem has been on all versions to date)
SmartThings: Platform v1
Device: Samsung Galaxy S4

I am just starting to get into this new rules engine and noticed a problem creating a CoRE piston.

Simple rule;

Creating Condition #1
if [Acceleration Sensor] is active…

Problem: When pressing done I receive a red caution popup "Please fill out all required fields"
The only way I can bypass this error is to turn on “Negate condition” and then press DONE

Once it saves then I must go back into Condition #1 and turn off the “Negate condition” option and press done again. Then I can continue with the rest of the rule.

1 Like

Known issue with Android, could just hit the back button without having to do negate

3 Likes

@bamarayne v0.0.051.20160528 - Alpha test version - More fixes for casting and variable condition description

Still getting the error? Is it a simulation? Can I see the piston so I can simulate?

v0.0.052.20160528 - Alpha test version - Fixed a bug where last executed task was not correctly removed

@Toy4Rick I’ve tested this piston and it works exactly as you need it:

setVariable is scheduled and executed after ALL conditions have been evaluated, which explains the 1s in the conditions…

1 Like

@ady624

Yes, still getting the errors in both simulate and real life. I tried changing it from a trigger to a condition and still no good.

Do you want this screenshots here or pm’d ?

@r4nd0m - thank you, but that is a with around which is something in I’m trying to avoid. Also, being in alpha version, finding and removing bugs is name of the game. If this is a bug in the core app, it could affect other areas if the code. If it’s in my system, then I need to figure it out and fix it.

1 Like

@ady624 Thanks for the Doggie Door Light Pistons. I will get into them today.

In all reality, the Pistons are both pretty simple in design while very smartly developed and integrated, thanks a ton

Rick

It just helps with how the system works - if the power changes it creates an event so if tou have slight changes it will always trigger, hence you’ll have plenty of events and triggers firing all the time which will make it difficult to work predictably - in addition all the messages may flood rhe hub/system - I used the SmartPower initially and saw this as my TV constantly changes the consumption on all changes which triggered all the time … So the rules didnt work - bu adding a virtual switch and some leeway this has become predictable I have to admit though not exactly what I wanted as it could take a few seconds for the rule to trogger when the actual conditions change but I prefer it this way - compare it to an ethernet port flapping on a switch - you want the port to be stable …

Its not a bug its how things work check the annoucements in the app and your logs and you’ll see what I mean

I understand what your saying about the fluctuations… But that is not the issue here. When my pump is off, the meter is ALWAYS below 1 watt. When it is on, it is ALWAYS above 1 watt. My threshold is 1w. - when power is above one way, do stuff. When power is below 1 watt, do other stuff.

This is most definitely a bug. Either in my system or in the app. I would rather find it and fix it, than with around it.

Edit - I know this is a bug because I had this exact sane scenario in rule machine for four months, it ran perfectly.

1 Like

Well 0.9,0.8 etc will trigger thats the issue it wont trigger when hitting 1w only thats the issue with this system as it will evaluate the rules I think Brice suppressed those and only evaluated if it was an actual definitive match - so he had end conditions if not true as per conditions set …

Sorry, but that is not correct. The threshold is one watt. Above it does one thing and below does another. I can make this work, I’ve got it working, but there is a bug in the evaluation.

Anyway, it’s not the system… It’s a problem either in the so, in my side, or the platform.

1 Like

@ady624. Here is the piston. Read from top down.













Maybe it’s the “power was”… Will look there.