Condition not resetting properly

Plugins & Plugin Development Program Logic (PLEG)
1

I’m beginning to sound like a broken record, but progress is being made.

For some reason my conditions are not being reset properly:

Triggers:
GarageDoorOpen	 Garage Main Door is tripped	false	2014-03-01 22:56:11.590	2014-03-01 22:56:31.578
IsNight	 Day or Night indicates Night time.	true	2014-03-01 22:55:16.633	2014-03-01 22:55:09.914
FDOpen	 Front Door Sensor is tripped	false	0	0

Conditions:
FPLightOff	No	(!IsNight and (IsNight; !IsNight))	false	2014-03-01 22:55:09.925	2014-03-01 22:55:16.654
FPLightDimOnClose	No	IsNight and !GarageDoorOpen and (GarageDoorOpen; !GarageDoorOpen) or IsNight and !FDOpen and (FDOpen; !FDOpen)	true	2014-03-01 22:55:16.659	2014-03-01 22:55:09.936
FPLightDimAtNight	No	IsNight and (!IsNight; IsNight)	true	2014-03-01 22:55:16.676	2014-03-01 22:55:09.938
FPLightOn	No	(IsNight and GarageDoorOpen and (!GarageDoorOpen; GarageDoorOpen)) or (IsNight and FDOpen and (!FDOpen; FDOpen))	false	2014-03-01 22:56:11.617	2014-03-01 22:56:31.615

Actions:
Actions for Condition: FPLightOff

Immediate

Device	Action	Arguments
Front Porch Lights	SetLoadLevelTarget	 newLoadlevelTarget=0


Actions for Condition: FPLightOn

Immediate

Device	Action	Arguments
Front Porch Lights	SetLoadLevelTarget	 newLoadlevelTarget=100

Actions for Condition: FPLightDimOnClose

Immediate

Device	Action	Arguments
Front Porch Lights	SetLoadLevelTarget	 newLoadlevelTarget=10
Actions for Condition: FPLightDimAtNight

Immediate

Device	Action	Arguments
Front Porch Lights	SetLoadLevelTarget	 newLoadlevelTarget=10

It boils down to this condition being TRUE all the time (at night) even when the garage door and front door are open (after having been closed):

IsNight and !GarageDoorOpen and (GarageDoorOpen; !GarageDoorOpen) or IsNight and !FDOpen and (FDOpen; !FDOpen)

I’m a slow learner. What do I have to add to this condition that will make it toggle to false when the door is actually open?

2

A big fat never mind… I figured it out. I was combining too many things in a single condition. Because I had both the garage door OR the front door set to dim the lights after closing, as long as one was closed, the statement was always true. I’m sure there’s a way to write the expression and have it work in a single condition, but not with my talent set. Splitting them up worked.

3

Your statements are a bit confusing…

What are you trying to do here:

(!IsNight and (IsNight; !IsNight))

IsNight will return true at night and false during the day. So (!IsNight and (IsNight; !IsNight)) is redundant and not necessary for your returning daytime, just use !IsNight.

This is a bit odd: !GarageDoorOpen and (GarageDoorOpen; !GarageDoorOpen)

It is saying return True if the garage A(is not open) and B(the garage door was opened before it was not open)

won’t B be true if A is true?

use IsNight and (!GrageDoorOpen or !FrontDoorOpen) to return true if it is night and either the front door is closed or the garage door is closed

For this: (IsNight and GarageDoorOpen and (!GarageDoorOpen; GarageDoorOpen)) or (IsNight and FDOpen and (!FDOpen; FDOpen))

use instead: IsNight and (FrontDoorOpened or GarageDoorOpen)

4

I’ll be the first to admit, most of this is not making much sense. But from what I gathered reading the PLEG basics PDF, I assume that this:

LightOn: GarageDoorOpen

Would mean LightOn is true if the GarageDoorOpen had ever been true - even though it may currently be false.

[b]LockDoor [/b]DoorClosed; AlarmSet < 10

LockDoor will become true if AlarmSet becomes true less than 10 seconds after DoorClosed becomes true. This is not a practical example, though, because it disregards the current state of DoorClosed and AlarmSet so would be true when AlarmSet becomes true even if DoorClosed was false - but had once been true.

LockDoor DoorClosed and AlarmSet and (DoorClosed; AlarmSet < 10)

I’m sure I’ve taken it too far, and perhaps that PLEG example deals only with time. But I get easily confused over the whole change of state vs. current state. I figure by having the ConditionA and (!ConditionA; ConditionA) I’m telling it to make sure it sees a change. I guess that’s not necessary?

5 
LightOn: GarageDoorOpen

This is invalid condition expression syntax … so its hard to understand what you mean by it.

I often use:
LightOn GarageDoorOpen

The bolded part is the condition name, the rest is the condition expression.
Others use:
LightOn = GarageDoorOpen

In the above cases LightOn would have the exact same value as GarageDoorOpen.
So LightOn would become true when GarageDoorOpen becomes true. And false when GarageDoorOpen becomes false.

If on the other hand you meant to use a semicolon:

LightOn ; GarageDoorOpen

This is a valid sequence expression. At some point in time the light was turned on. Also at some point in time the GarageDoor was opened.
If the GarageDoor was opened after the light was turned On … this will be true. In fact it does not matter if the light is currently on or off. Now you can close the Garage Door and this will still be true.
Open and close it multiple times and this value will stay true.

Now if the light is off and you turn it on this value will go false. Turn the light off and this value will stay false. Also it does not care if the Garage door is currently open or not!
What I am trying to say is this expression does not care about the values it’s components … but only the time at witch each was last became true. It’s confusing because when a component becomes true … it may change the value of this expression … but the component can change to false … and in that case it will NOT effect the value of this expression (Unless you use the ! syntax.)

Until you can understand the meaning of this syntax … you will be confused by logic that uses it. Normal boolean logic (AND, OR, NOT) allow you to create an expression about the current state of events. Sequence Expressions augment that and allow you to extend your logic based on how the individual terms transitioned to a particular state. The comparison between normal boolean and logic and extended (via sequence expression) is equivalent to the differences between checkers and 3D checkers.
[hr]

ConditionA and (!ConditionA; ConditionA)

The above is exactly equivalent to:

ConditionA

I will demonstrate through logic simplification:
CondtionA = (!CondiontA;ConditionA)

So you have:
ConditionA and CondionA

Which is equivalent to:

ConditionA
[b]
Now if you add a time constraint … that greatly changes the meaning:

ConditionA and (!ConditionA; ConditionA > 1:00)

This will only be true if ConditionA is true and it was previously off for at least 1 minute.

6

Thanks Richard. I appreciate you taking the time to detail all of this - especially even the most elementary aspects of the sequencing ( : v ; ). Fortunately, that I already determined. The colon was my way of delineating the defined condition name vs. the actual condition here on the post - not in the routine itself. I have never used a colon anywhere in the routines.

It’s not easy admitting I’m so clueless. But if there’s one thing I’ve learned, it’s if you don’t ask (even at the expense of looking the fool), you’ll never learn.

I clearly made the assumption that the sequence defining the door open after it was closed was necessary to trigger a true evaluation. That was based on the sequence example in your PLEG Basic.pdf - but what I failed to grasp is that the example was under “working with time”.

After pointing out that ConditionA is the same as ConditionaA and (!ConditionA; ConditionA), it’s starting to sink in. Unless I’m adding another variable, there is no need to be redundant - as the expression will be evaluated the same way.

Thanks.

7

BTW, it might be a placebo effect, but ever since stripping out all but two PLEG devices (I had about 7 or 8 instances each running one or two conditions), VERA seems to be considerably faster at executing actions.

8

that’s great. With my main vera, less is more when it comes to performance.

9

Thanks for your comments too BDL. About the alternate condition expression you suggest. Using that routine, wouldn’t it always be true if it’s night, and the front door is always closed? In other words, it would never toggle to false unless both the garage door AND the front door were opened at the same time. Thus, with it staying TRUE all the time, the condition would never toggle - and therefore never trigger an action. This is what was causing my initial grief (and the purpose behind the original post).

You see, once the GD opens, it triggers the other condition which turns the lights on full bright. Yet, this dimming condition is ALSO STILL TRUE (since the FD is still closed). Then, when the GD closes, the condition calling for full bright goes to false, but this condition triggering dim, doesn’t trigger at all, as it never toggled off of TRUE.

I’m thinking I need the OR to be an AND. After all, if either door is open, the lights should be on full. By having it listed as:

IsNight and (!GrageDoorOpen AND !FrontDoorOpen)

The statement will always be false unless BOTH doors are closed - which really makes more practical sense anyway. Funny how talking (writing) this stuff out helps to make me understand it better.

10

Thanks for your comments too BDL. About the alternate condition expression you suggest. Using that routine, wouldn’t it always be true if it’s night, and the front door is always closed? In other words, it would never toggle to false unless both the garage door AND the front door were opened at the same time. Thus, with it staying TRUE all the time, the condition would never toggle - and therefore never trigger an action. This is what was causing my initial grief (and the purpose behind the original post).

You see, once the GD opens, it triggers the other condition which turns the lights on full bright. Yet, this dimming condition is ALSO STILL TRUE (since the FD is still closed). Then, when the GD closes, the condition calling for full bright goes to false, but this condition triggering dim, doesn’t trigger at all, as it never toggled off of TRUE.

I’m thinking I need the OR to be an AND. After all, if either door is open, the lights should be on full. By having it listed as:

IsNight and (!GrageDoorOpen AND !FrontDoorOpen)

The statement will always be false unless BOTH doors are closed - which really makes more practical sense anyway. Funny how talking (writing) this stuff out helps to make me understand it better.[/quote]

So, I believe I understand what you are doing. So, using this example (which still needs refinement for you to love the way it works, I imagine) lets review.

IsNight and (!GrageDoorOpen or !FrontDoorOpen)

This expression will return TRUE if

  1. it is night
  2. Either the Garage door is not open OR the the front door is not open

This is interesting, considering that you are using the negative condition (!GarageDoorOpen) to execute the action. Is it your intention to turn on a light in the case that a door closes?

changing to this:

IsNight and (!GrageDoorOpen AND !FrontDoorOpen)

This expression will return TRUE if:

  1. it is night time
  2. Both the garage door and the front door are not open

So, I imagine you wish to turn on the lights if either of the doors are opened and it is night correct?

I would use this,

TurnLightOn = IsNight AND (FrontDoorOpen or GarageDoorOpen)

but, recognize that if either door is open, and then the sun sets, the light goes on. (remember Richard’s notes on syntax, I like to use the “=” way to express the condition name and its expression)

In this expression, we are using conditional (boolian) logic, not sequences and recalling their times. Plus, doors tend to change status often, so it is not likely that a door will once opened, remain open indefinitely like a schedule that trips one and never does again. The GarageDoorOpen trigger is enough to fire the action without mucking up the logic, testing for times and whatnot. Realize that PLEG works from EVENTS, which by definition is the change of status of a trigger, schedule, property, or condition.

Expanding on this a bit,

You may not want to turn on the light, if for example the light was on already. I add the (!LightOn) expression to make sure that I am not interfering with some other PLEG actions, or scenes:

TurnLightOn = !LightOn AND IsNight AND (FrontDoorOpen or GarageDoorOpen)

This in essence won’t bother to turn on the light, in the case that it was on when the garage door was opened. Important later on if you have other expressions switching on/off that same light.

I hope this is helpful. Keep the questions coming.

11

Very helpful. Thanks. My conditions are a bit unconventional. The front porch (FP) light has its own condition that has it come on at 10% at night. And the off at daytime. That works just fine.

I then have another condition that states if either the front door (FD) or garage door (GD) are opened at night, then the lights go to 100%.

But when FD and GD close, the light should go “off” by reducing back to 10% if it’s night. SO, yes, it’s an odd scenario, but I’m actually having the light ON when the doors close. Just not as much “on” as when they’re open :slight_smile:

In any case, the dim on/off w/day/night works perfect. As does the 100% when either FD or GD open. It was really only the condition where I had specified EITHER FD or GD closed would make the condition true.

Since my FD is hardly ever opened, having the condition list it as an OR, made the conditional virtually always true (at night). That’s why it wouldn’t reset when I closed the GD. I’ve now changed it to AND, and it works perfectly.

I love the !LightOn addition - so that the condition only fires if the light wasn’t already on. That’s a great way to keep different routines from stepping on each other’s toes - which I’m particularly good at doing.

Thank you both for your patience and support. It makes all the difference to someone who would otherwise have given up a long time ago.

12

Much clearer now, yes. And I am glad it is working very happily.

So, you want to turn the light back to 10% immediately when the door is closed, or would you like it to stay at 100% for some period of time, and then return to 10%?

I can imagine you are leaving the house through the front door at night. You open the door and the outdoor lights are raised up to 100% right away and stay there until you can make you way to your car, or walk across the street to your neighbor’s house. After some time to allow that (10minutes) they return to this 10% state.

13

Nah, 10% is bright enough to still navigate. Besides, it’s cool to see my column lights go dim as the door closes and I drive away. Makes me feel/look “automated” to my neighbors. If only they knew how my pea-brain struggled just to get it to do that :slight_smile:

14

Right, you forgot to mention that one other desired Event!