I just switched to using the ISY portal node server for occupancy monitoring, and I'm having trouble replicating what used to work for me when I was using simple Locative calls to set ISY state variables.
 
Here's the program I have right now. Essentially I want the outside lights to come on (it's a single Insteon 2477S device, not a scene) if it's dark outside, if the lights aren't already on, and I arrive in my neighborhood geofence.

Arrive home - [ID 0005][Parent 0008]
If
        From    Sunset  + 15 minutes
        To      Sunrise (same day)
    And 'Outside / Outside Lights' Status is Off
    And 'Neighborhood / iPhone' Occupied is True

Then
        Run Program 'Outside lights on arrival' (Then Path)

Else
   - No Actions - (To add one, press 'Action')

The "Outside lights on arrival" program is disabled and looks like this:

Outside lights on arrival - [ID 0007][Parent 0008][Not Enabled]
If
   - No Conditions - (To add one, press 'Schedule' or 'Condition')

Then
        Set 'Outside / Outside Lights' On
        Wait  10 minutes
        Set 'Outside / Outside Lights' Off

Else
   - No Actions - (To add one, press 'Action')

I'm still trying to wrap my head around the event-drive programming paradigm of the ISY. I'd appreciate any pointers.

The only thing I see funny is the "same day" condiition for sunrise. Perhap you should try sunrise on the "next day"?

Good catch. I'm guessing that could be messing up the trigger.

Very likely, yes. May be triggering fine, though, but always evaluating false.

The lights came on when I got home tonight. Now the problem is that they click off after 10 minutes and then go right back on again. I think I need to set a variable somewhere to manage that unless someone has a more elegant solution. 

 

In my previous solution that was using Locative only, the state variables that Locative triggered worked perfectly. Now the line that refers to the neighborhood being occupied is always true when I'm home.

Most likely it is the condition

 

"And 'Outside / Outside Lights' Status is Off"

 

That is retriggering the first program. Despite common usage, I dont believe it serves much purpose in most cases and I would remove it.

 

Unless you want an excuse to play around with variables, none are required here and, in my estimation, simply add complesity.

I still don't think this is working quite right. Let me check my understanding of how the following program triggers. I may be misunderstanding something fundamental.

Tim arrives home - [ID 0006][Parent 0008]
If
        From    Sunset  + 15 minutes
        To      Sunrise (next day)
    And 'Neighborhood / Tim iPhone' Occupied is True

Then
        Run Program 'Outside lights on arrival' (Then Path)

Else
   - No Actions - (To add one, press 'Action')

My understanding is that the "if" part of this program will be evaluated when one of the following events occurs:

• The ISY's time is Sunset + 15 minutes
• The ISY's time is Sunrise (next day)
• My iPhone enters the geofence I've defined as my "neighborhood"

Obviously, the "and" requires that the time constraint and occupancy both evaluate as true to trigger the "then" clause.

 

I should not be surprised, then, when the outside lights turn on at Sunset+15 if I'm sitting in my living room at the time. That's not what I attended with this program though. I only want the outside lights to turn on as I approach my house in my car after dark. I don't need the outside lights on if I'm already in the house.

 

So I'm back to the idea that I may need to set a state variable when the occupancy state changes. My program would change to look for that state variable between sunset+15 and sunrise, say $sTimArrivedHome = 1, turn on the lights, set $sTimArrivedHome = 0, wait 10 minutes, and turn the light off.

 

Does that make sense?

Hi Tim,

 

Yes, that makes sense with one modification on time constraints: it's From and To and NOT exactly at those to times as your bullets connote.

 

As you suggested, what you need to do is to have a variable for away that's set when you go away. Then the condition should include that in the And:

And Away = 1

 

With kind regards,

Michel

Yes, that makes sense with one modification on time constraints: it's From and To and NOT exactly at those to times as your bullets connote.

 

 

Thanks for the reply. So you're saying that the ISY evaluates the "if" portion of that program continually during the specified time interval? That wouldn't change the observed behavior I cited, but it is a big difference from what I thought was happening. I could have sworn I'd read somewhere that those only get evaluated at the beginning and end. (But I'll take your word for it as someone who should probably know.)

Thanks for the reply. So you're saying that the ISY evaluates the "if" portion of that program continually during the specified time interval? That wouldn't change the observed behavior I cited, but it is a big difference from what I thought was happening. I could have sworn I'd read somewhere that those only get evaluated at the beginning and end. (But I'll take your word for it as someone who should probably know.)

 

I'm a bit confused, too.  I think it's accurate to say that the schedule condition will evaluate to TRUE for the entire duration, but it will only trigger the program to run at the beginning or the end.  If you manually or programmatically execute the IF clause of the program, or if there are other conditions in the IF statement (like your geofence variable), they may also cause the IF clause to be evaluated.  At that point, the schedule condition will evaluate to TRUE or FALSE depending on whether you're within the time range or not.

Yes, that's more like what I expected it to be.

Hi Guys,

 

Two cases:

1. The condition is made up of only From and To. In that case the program is evaluated only at From and at To

2. Otherwise, the program is evaluated every time one or more of the conditions change WITHIN the From and the To

 

With kind regards,

Michel

Two cases:

1. The condition is made up of only From and To. In that case the program is evaluated only at From and at To

2. Otherwise, the program is evaluated every time one or more of the conditions change WITHIN the From and the To

 

 

That makes sense. Thanks for the clarification, Michel.