IF THEN ELSE

[Schly]

OK, I've reading myself into circles on how to get if/then/else type statements to work. I thought I had it figured out and pulled my hair out until I got all the pieces worked out. Now I have something, but it's not working,

These are out of order. The trigger is in the middle and the two events are top and bottom. I don't know how to reorder things if there is a way.

What I want:

"Open the gate"

If: Gate is open
Then: "Gate is already open", Do nothing.

Else: Open Gate.

I intend to do the same thing with a Close Gate command as well.

I don't want to randomly have my gate opening when I think I'm closing it, or vice versa.

Here's what I've come up with but no matter what condition the gate is in, the gate triggers open or closed.

For my open/closed sensor, 0 = closed and 255 = open.

[Schly]

I think I just realized I did "Then" Statements in my two child events instead of And If events. Is that right?

EDIT, no, I'm looking at the main trigger. I think that may be where my issue is. I'm so confused.

[ericg]

Unfortunately, I think the solution to your problem depends on information you haven't supplied. Perhaps I can offer some general comments that you might find useful.

Either you (the event designer) or the person that defined the gate's electronic interface has to deal with eight possible situations:

1. You want the gate to be closed, and it is presently open.
2. You want the gate to be closed, and it is presently in the process of opening.
3. You want the gate to be closed, and it is presently in the process of closing.
4. You want the gate to be closed, and it is presently already closed.
5. You want the gate to be open, and it is presently closed.
6. You want the gate to be open, and it is presently in the process of opening.
7. You want the gate to be open, and it is presently in the process of closing.
8. You want the gate to be open, and it is presently already open.

Because gates take a relatively long time (often 30 seconds or more), the solution must allow for the possibility that a new command might come along before the previous one has fully completed. It's not like turning a light on or off.

A well designed electronics control package makes it simple for you. My system doesn't have a gate, so I created a virtual device to represent one. Maybe the gate electronics allows you to command Off or On whenever you wish, regardless of the current state of the gate. That would be ideal, because then you can command On or Off, confident that, sooner or later, the gate position will conform to your command. In that case, you could control the gate with these two simple events:

<Command gate to open:>
IF This event is MANUALLY triggered
THEN Set Device Unknown Unknown Gate to Open

<Command gate to close:>
IF This event is MANUALLY triggered
THEN Set Device Unknown Unknown Gate to Closed

It is possible, however, that when you installed your gate device, they set up a more complex device specification. For instance, there might be a parent device which does very little, a child device which tells you the current status of the gate (opened, closed, opening, or closing), and possibly another child device that you use to control the gate position. In that case, your event design would depend on the definitions of these subdevices.

Without more information about your specific device interface, that's about all I can offer.

[Schly]

Unfortunately, I think the solution to your problem depends on information you haven't supplied. Perhaps I can offer some general comments that you might find useful.

Either you (the event designer) or the person that defined the gate's electronic interface has to deal with eight possible situations:

1. You want the gate to be closed, and it is presently open.
2. You want the gate to be closed, and it is presently in the process of opening.
3. You want the gate to be closed, and it is presently in the process of closing.
4. You want the gate to be closed, and it is presently already closed.
5. You want the gate to be open, and it is presently closed.
6. You want the gate to be open, and it is presently in the process of opening.
7. You want the gate to be open, and it is presently in the process of closing.
8. You want the gate to be open, and it is presently already open.

Because gates take a relatively long time (often 30 seconds or more), the solution must allow for the possibility that a new command might come along before the previous one has fully completed. It's not like turning a light on or off.

A well designed electronics control package makes it simple for you. My system doesn't have a gate, so I created a virtual device to represent one. Maybe the gate electronics allows you to command Off or On whenever you wish, regardless of the current state of the gate. That would be ideal, because then you can command On or Off, confident that, sooner or later, the gate position will conform to your command. In that case, you could control the gate with these two simple events:

<Command gate to open:>
IF This event is MANUALLY triggered
THEN Set Device Unknown Unknown Gate to Open

<Command gate to close:>
IF This event is MANUALLY triggered
THEN Set Device Unknown Unknown Gate to Closed

It is possible, however, that when you installed your gate device, they set up a more complex device specification. For instance, there might be a parent device which does very little, a child device which tells you the current status of the gate (opened, closed, opening, or closing), and possibly another child device that you use to control the gate position. In that case, your event design would depend on the definitions of these subdevices.

Without more information about your specific device interface, that's about all I can offer.

I should have mentioned that the gate is controlled by a simple MIMO lite with a magnetic contact switch for open/closed status.

[logman]

In a situation like this, I usually try to confirm the position of the controlled device with either position limit sensors or open/close sensors as opposed to relying solely on the controlled device reported status.

You don't mention if your gate is hinged or moves on a roller track, but you should be able to make this work with either setup.

You can use 2 plain vanilla open/close z-wave sensors positioned to report at the extreme limits of travel. This assumes your gate is within Z-Wave range of your Homeseer controller. If not, you can use position limit switches (open/closed) hard-wired and buried underground back to the house to where you can then connect them to z-wave or Zigbee dry contact sensors.

Stay with me because this gets a bit confusing.

Sensor 1 is positioned to report "sensor closed" when the gate is fully closed.
Sensor 2 is positioned to report "sensor closed" when the gate is fully open.

With the above configuration, this is what you will see in Homeseer:

Gate fully open: Sensor 1 "open", Sensor 2 "closed"
Gate fully closed: Sensor 1 "closed", Sensor 2 "open"
Gate traveling: Sensor 1 "open", Sensor 2 "open".
Gate stopped during travel prior to reaching either limit: Sensor 1 "open", Sensor 2 "open".

By having the 2 points of reference at each travel limit, you now know in advance what the position of the gate is prior to sending your control command. You can also monitor how long each sensor has been "open" and if both have been open longer than it takes for your gate to travel from limit to limit, then you know the gate either hit an obstruction or lost power.

If you want to get really fancy, you can add another sensor in the middle of the travel stroke that will briefly report "closed" as the gate passes midway between open and closed. At all other times this sensor should report "open". This gives you earlier confirmation your command was received and the gate is moving. (On a large roller gate you can add multiple sensors that report along the travel path.)

Last step then is to create a virtual device in Homeseer that represents the gate status. Based upon the sensors statuses you can create events to toggle this device between Open, Closed, and Traveling and use custom gate graphics to represent each position.

--Barry

[ericg]

logman, very nice! I'll be saving this for when I eventually add HS control to a couple of my own gates.

[Schly]

In a situation like this, I usually try to confirm the position of the controlled device with either position limit sensors or open/close sensors as opposed to relying solely on the controlled device reported status.

You don't mention if your gate is hinged or moves on a roller track, but you should be able to make this work with either setup.

You can use 2 plain vanilla open/close z-wave sensors positioned to report at the extreme limits of travel. This assumes your gate is within Z-Wave range of your Homeseer controller. If not, you can use position limit switches (open/closed) hard-wired and buried underground back to the house to where you can then connect them to z-wave or Zigbee dry contact sensors.

Stay with me because this gets a bit confusing.

Sensor 1 is positioned to report "sensor closed" when the gate is fully closed.
Sensor 2 is positioned to report "sensor closed" when the gate is fully open.

With the above configuration, this is what you will see in Homeseer:

Gate fully open: Sensor 1 "open", Sensor 2 "closed"
Gate fully closed: Sensor 1 "closed", Sensor 2 "open"
Gate traveling: Sensor 1 "open", Sensor 2 "open".
Gate stopped during travel prior to reaching either limit: Sensor 1 "open", Sensor 2 "open".

By having the 2 points of reference at each travel limit, you now know in advance what the position of the gate is prior to sending your control command. You can also monitor how long each sensor has been "open" and if both have been open longer than it takes for your gate to travel from limit to limit, then you know the gate either hit an obstruction or lost power.

If you want to get really fancy, you can add another sensor in the middle of the travel stroke that will briefly report "closed" as the gate passes midway between open and closed. At all other times this sensor should report "open". This gives you earlier confirmation your command was received and the gate is moving. (On a large roller gate you can add multiple sensors that report along the travel path.)

Last step then is to create a virtual device in Homeseer that represents the gate status. Based upon the sensors statuses you can create events to toggle this device between Open, Closed, and Traveling and use custom gate graphics to represent each position.

--Barry

This is great input, but I don’t think it’s going to help me in my situation. I already know my gate position. HS3 reports it to me as “open” or “closed”, which is enough information.

What i I want to do is, when I’m in a hurry and don’t have time to look at the app, have Alexa tell me the gate position if I try to run a command that would change the state form what I already want it.

i can look at the app, and see that the gate is open. I can then say “Alexa, start gate”, and the gate will close. If I look in HS3, I can see the gate is closed at that point.

I want to, without looking at the app, send a close command, “Alexa, close the gate.” and have it close ONLY if the gate is currently open. If it’s already closed, I want it to verbally report back to me “gate is already closed”. This second step is what’s giving me problems. I can certainly create an event that will only run if the gate sensor value is “not zero(closed)”.

Adding the second part where it reports that the gate is already closed is the “ELSE” statement that I’m having trouble with.

[ericg]

This may be one of those situations where a common understanding of the problem is more difficult than the solution.

I now understand that you need events that respond to Alexa requests to open or close your gate, and that we should ignore the possibility that your requests might occur while the gate is in motion. I.e., open or close requests are given when the gate is in either a static open or closed position. In addition, you specify that you want a verbal response that the action was performed. Finally, if the command matches the current gate status, you want Alexa to report that the gate is already in the requested position. If we agree that this is what you want, I think you can handle gate closure requests with the following three events:

<Close the gate:>
IF This event is MANUALLY triggered
AND IF Garage Gate is greater than a custom value of 50
WAIT 1 second
THEN Set Garage Gate to Off
THEN Speak Gate has been closed

<Gate already closed:>
IF This event is MANUALLY triggered
AND IF Garage Gate has a value equal to 0
THEN Speak Gate is already closed

I don't have Alexa, so I am unfamiliar with the details of the Alexa interface to HS3. However, I believe that whatever Alexa plug-in you are using will allow you to link the verbal command to trigger an event that you specify. Assuming I am right, when you tell Alexa to close the gate, you'll want to execute an event that looks like this:

<Alexa says to close the gate:>
IF <Alexa causes this event to run>
THEN If the Event Conditions are True Run Event <event group> Close the Gate
THEN If the Event Conditions are True Run Event <event group> Gate Already Closed

It is very important that the two THEN action items above are qualified with the check box "If the event conditions are true".

I have not explained the WAIT one second action in the first event above. When you hear that Alexa wants to close the gate, the "Alexa says ..." event will trigger one of the first two events above. When you have multiple THEN actions appearing consecutively in a group, you can't be sure of the sequence in which they will be executed. (It's the nature of the HS3 event processing engine.) In this case, execution of the "Close the gate" event before the "Gate already closed" event would be disastrous, because both events would be triggered, and Alexa would wind up contradicting herself.

The additional events you would need to handle Alexa's request to open the gate are essentially a mirror image of the above.

I've tried to mimic your nomenclature as closely as possible. When you get a chance, you might want to tweak your device definitions to make the events and the device status pages a little more readable. For instance, you could replace "greater than a custom value of 50" with "Open", etc.

I'll end on a note of humility. I'm a relatively new Seer myself, and it's pretty easy to make mistakes on event advice that hasn't been tested. Furthermore, I don't have Alexa, so I can't see the whole picture. But I'm hoping this helps. Good luck!

[ericg]

Uncle Michael, I'm wondering whether perhaps I've given Schly some bad advice in my post #8 in this thread. The thread title "IF THEN ELSE" is yet another indication of the difficulty many of us have creating related event definitions.

In this case, Schly appears to be using a "Garage Gate" device for both status and control. The only solution I could think of that satisfies the stated need requires multiple concurrent events that both test the device status and control the device value. Would you agree that there is a need to anticipate and provide for a possible race condition? And regardless, are you aware of any documentation (either HomeSeer or forum) that addresses this question?

Thanks.

[Schly]

This may be one of those situations where a common understanding of the problem is more difficult than the solution.

I now understand that you need events that respond to Alexa requests to open or close your gate, and that we should ignore the possibility that your requests might occur while the gate is in motion. I.e., open or close requests are given when the gate is in either a static open or closed position. In addition, you specify that you want a verbal response that the action was performed. Finally, if the command matches the current gate status, you want Alexa to report that the gate is already in the requested position. If we agree that this is what you want, I think you can handle gate closure requests with the following three events:

<Close the gate:>
IF This event is MANUALLY triggered
AND IF Garage Gate is greater than a custom value of 50
WAIT 1 second
THEN Set Garage Gate to Off
THEN Speak Gate has been closed

<Gate already closed:>
IF This event is MANUALLY triggered
AND IF Garage Gate has a value equal to 0
THEN Speak Gate is already closed

I don't have Alexa, so I am unfamiliar with the details of the Alexa interface to HS3. However, I believe that whatever Alexa plug-in you are using will allow you to link the verbal command to trigger an event that you specify. Assuming I am right, when you tell Alexa to close the gate, you'll want to execute an event that looks like this:

<Alexa says to close the gate:>
IF <Alexa causes this event to run>
THEN If the Event Conditions are True Run Event <event group> Close the Gate
THEN If the Event Conditions are True Run Event <event group> Gate Already Closed

It is very important that the two THEN action items above are qualified with the check box "If the event conditions are true".

I have not explained the WAIT one second action in the first event above. When you hear that Alexa wants to close the gate, the "Alexa says ..." event will trigger one of the first two events above. When you have multiple THEN actions appearing consecutively in a group, you can't be sure of the sequence in which they will be executed. (It's the nature of the HS3 event processing engine.) In this case, execution of the "Close the gate" event before the "Gate already closed" event would be disastrous, because both events would be triggered, and Alexa would wind up contradicting herself.

The additional events you would need to handle Alexa's request to open the gate are essentially a mirror image of the above.

I've tried to mimic your nomenclature as closely as possible. When you get a chance, you might want to tweak your device definitions to make the events and the device status pages a little more readable. For instance, you could replace "greater than a custom value of 50" with "Open", etc.

I'll end on a note of humility. I'm a relatively new Seer myself, and it's pretty easy to make mistakes on event advice that hasn't been tested. Furthermore, I don't have Alexa, so I can't see the whole picture. But I'm hoping this helps. Good luck!

This is what I’m going for. And it reads very similarly to the image I posted that shows my attempt. Is it possible that not having the one second delay is triggering the gate to move regardless of its current status?

[ericg]

These are out of order. The trigger is in the middle and the two events are top and bottom. I don't know how to reorder things if there is a way.

I didn't respond to this because I wasn't (and still am not) sure what you meant. I agree that what you posted is very similar (for open) to what I suggested (for close). But I am concerned about your "trigger in the middle." You want Alexa to fire the event you have named "Open The gate" (the bottom one). When that event executes, it will fire one, but not both of the other two events.

The delay I suggested is to prevent Alexa from reporting both that the gate has been opened, and that it was already open. The rationale is as follows: When "Open The gate" event executes because of Alexa's prodding, that event will ask the event processor to execute two more events, provided that their AND IF conditions are satisfied. One of the events runs if the gate reports Open status, and the other one runs if the gate reports Closed status. There is no way to tell which of the two action statements (the THEN actions in the "Open The gate" event) will be evaluated first for triggering by the HS event engine. A problem arises (I suspect) if the "Gate Open Trigger" event gets evaluated and triggered just a tiny bit before the "Gate Already open" event is evaluated for possible event triggering. The "Gate Open Trigger" event runs because the gate was closed. But that same event sets the device status to Open, in anticipation of the result. If the HS event engine comes along just a moment later to evaluate whether "Gate Already open" should run, it will determine, yes, this event should run, because device Garage Gate was set to Open by the "Gate Open Trigger" event just milliseconds earlier. If both events run, that won't affect actual gate motion, but it will make Alexa report both that the gate has been opened, and also that it was already open. The one second delay was to ensure that the "Gate Already open" event trigger evaluation would occur before the Gate Open Trigger" event had a chance to change the value of device Garage Gate. This concern was the substance of a verification request to Uncle Michael I made in this thread's post #9.

My major concern to you is that you have the Alexa "open gate" command triggering your event "Open The gate", and not either of the other two. (The display order of event definitions in an event group is immaterial. HS3 automatically sorts and displays them in alphabetical order, according to the names you give them.)

Are we making progress?

[Schly]

I didn't respond to this because I wasn't (and still am not) sure what you meant. I agree that what you posted is very similar (for open) to what I suggested (for close). But I am concerned about your "trigger in the middle." You want Alexa to fire the event you have named "Open The gate" (the bottom one). When that event executes, it will fire one, but not both of the other two events.

The delay I suggested is to prevent Alexa from reporting both that the gate has been opened, and that it was already open. The rationale is as follows: When "Open The gate" event executes because of Alexa's prodding, that event will ask the event processor to execute two more events, provided that their AND IF conditions are satisfied. One of the events runs if the gate reports Open status, and the other one runs if the gate reports Closed status. There is no way to tell which of the two action statements (the THEN actions in the "Open The gate" event) will be evaluated first for triggering by the HS event engine. A problem arises (I suspect) if the "Gate Open Trigger" event gets evaluated and triggered just a tiny bit before the "Gate Already open" event is evaluated for possible event triggering. The "Gate Open Trigger" event runs because the gate was closed. But that same event sets the device status to Open, in anticipation of the result. If the HS event engine comes along just a moment later to evaluate whether "Gate Already open" should run, it will determine, yes, this event should run, because device Garage Gate was set to Open by the "Gate Open Trigger" event just milliseconds earlier. If both events run, that won't affect actual gate motion, but it will make Alexa report both that the gate has been opened, and also that it was already open. The one second delay was to ensure that the "Gate Already open" event trigger evaluation would occur before the Gate Open Trigger" event had a chance to change the value of device Garage Gate. This concern was the substance of a verification request to Uncle Michael I made in this thread's post #9.

My major concern to you is that you have the Alexa "open gate" command triggering your event "Open The gate", and not either of the other two. (The display order of event definitions in an event group is immaterial. HS3 automatically sorts and displays them in alphabetical order, according to the names you give them.)

Are we making progress?

I think we’re on the same page now. I have to sit down and work on it. It’s very hot here today and I’m in and out doing yard work instead of working on this, but I really appreciate the assistance and I’ll try to play with it a little more as soon as I can.

EDIT: To answer your question about order, yes, that’s what I meant. The event in the middle is the event that is used to trigger either the one above it or the one below it, that’s all.

[Uncle Michael]

Uncle Michael, I'm wondering whether perhaps I've given Schly some bad advice in my post #8 in this thread. The thread title "IF THEN ELSE" is yet another indication of the difficulty many of us have creating related event definitions.

I've been following this thread, but am still unclear about the specific problem(s) that remain. I think you and logman have been helping to clarify the details of the setup and the OP's requirements.

Would you agree that there is a need to anticipate and provide for a possible race condition? And regardless, are you aware of any documentation (either HomeSeer or forum) that addresses this question?

I am still too unsure of the details to have an opinion on the possibility of a race condition. I am also unaware of specific documentation, but Randy has done a pretty thorough job of explaining how to do contingent calls to events in various posts, some in the Event Clinic and some scattered in other threads, but it is clearly not intuitive to most users, and especially confusing for those who see the problem through the paradigm of standard if/then/else logic.

[Uncle Michael]

This post is primarily intended to test my understanding of the problem. Suggested events are meant as examples to illustrate my points, not necessarily as solutions to the actual problem.

What I think I understand:

• The gate position is known (by system).
• The gate direction when commanded is known.
• Gate change command is to Alexa. If so, an audible response of gate status is required.

What I think is required.

• An open gate command will trigger an event with the following actions
  • If the Event Conditions are True, Run Event <Gate Already Open>
    • Where Event <Gate Already Open> is
      • If This Event is Manually Triggered
      • And If <Gate is Open>
      • Then <Announce, "The gate is already open">
  • If the Event Conditions are True, Run Event <Open Gate>
    • Where Event <Open Gate> is
      • If This Event is Manually Triggered
      • And If <Gate is Closed>
      • Then <Open Gate> [This can be an action or another event]
      • Then <Announce, "Opening gate.">
• A close gate command will trigger an event with the following actions
  • If the Event Conditions are True, Run Event <Gate Already Closed>
    • Where Event <Gate Already Closed> is
      • If This Event is Manually Triggered
      • And If <Gate is Closed>
      • Then <Announce, "The gate is already closed">
  • If the Event Conditions are True, Run Event <Close Gate>
    • Where Event <Close Gate> is
      • If This Event is Manually Triggered
      • And If <Gate is Open>
      • Then <Close Gate> [This can be an action or another event]
      • Then <Announce, "Closing gate.">

What is missing?

[Schly]

This post is primarily intended to test my understanding of the problem. Suggested events are meant as examples to illustrate my points, not necessarily as solutions to the actual problem.

What I think I understand:

• The gate position is known (by system).
• The gate direction when commanded is known.
• Gate change command is to Alexa. If so, an audible response of gate status is required.

What I think is required.

• An open gate command will trigger an event with the following actions
  • If the Event Conditions are True, Run Event <Gate Already Open>
    • Where Event <Gate Already Open> is
      • If This Event is Manually Triggered
      • And If <Gate is Open>
      • Then <Announce, "The gate is already open">
  • If the Event Conditions are True, Run Event <Open Gate>
    • Where Event <Open Gate> is
      • If This Event is Manually Triggered
      • And If <Gate is Closed>
      • Then <Open Gate> [This can be an action or another event]
      • Then <Announce, "Opening gate.">
• A close gate command will trigger an event with the following actions
  • If the Event Conditions are True, Run Event <Gate Already Closed>
    • Where Event <Gate Already Closed> is
      • If This Event is Manually Triggered
      • And If <Gate is Closed>
      • Then <Announce, "The gate is already closed">
  • If the Event Conditions are True, Run Event <Close Gate>
    • Where Event <Close Gate> is
      • If This Event is Manually Triggered
      • And If <Gate is Open>
      • Then <Close Gate> [This can be an action or another event]
      • Then <Announce, "Closing gate.">

What is missing?

This is exactly what I'm trying to do.