Smart Handling of ISY Motion events

[Sendero]

After working with Dean on http://www.charmedquark.com/vb_forum/sho...hp?t=12664 , I think it may be related to my processing of ISY motion events.

For each Insteon Motion sensor, ISY creates 3 nodes:
<Name>-Dusk.Dawn
<Name>-Low Bat
<Name>-Sensor

I am trying to make my system easily flexible such that I can have new motion sensors trigger a scene without having to add code for each one. So, my approach was to name a sensor as "FamilyRoomMotion" and then have a scene of "FamilyRoomMotion-Scene".

In the ISY Event handler I want to just strip off the "-Sensor" from the triggering sensor name so I can then append "-Scene" and activate the scene. However, I've noticed that I'm getting events for some "Dusk.Dawn" from motion sensors. So, when I hard code removing 7 characters from the name and then append "-Scene" I end up with a non-existant field and errors in the event handler. My concern is that those errors lead to ISY disconnecting.

How can I quickly and easily check that the event is actually a motion triggered event and not a low bat or dusk/dawn? I wish there was a string.endswith("-Sensor") that I could use but I can't find anything like that.

Suggestions?

[Dean Roddey]

One problem is that I didn't realize that those three fields aren't all motion sensor fields. So they are getting marked as motion sensors (if I remember correctly from what I saw.) That needs to be addressed in the ISY driver, though guidance from the ISY users here would be welcome on that. Are you guys seeing those fields show up as motion sensors?

One issue is that period in Dusk.Dawn. I THINK that should get replaced with an underscore by the ISY driver. If not, then it's going to cause some wierdness probably, because there can't be periods in a field name (because the period is used to separate the moniker from the field part.)

But, in the meantime, the thing to do would be to check for the incoming field name ending with -Sensor. So, in your triggered event filters, you could check the 'reg ex' check box on the field name and set the comparison value to:

*.-Sensor

That would then only let through any that end with -Sensor. Then you could know for sure that it's safe to just strip off that bit.

[Sendero]

Fixed the string to be ".*-Sensor"

Thanks! I'll see if that fixes my not connected issues.

[Dean Roddey]

Be sure to indicate it's a regular expression, else it'll try to literally match that.

[Sendero]

(Dean - Feel free to move to the error thread if that is more appropriate location)

Even with all that, I'm still getting the error on some runs of the motion handler.



Just before that in the logs I see success


Event Handler Code

Code:

TrigEvent::GetMotionInfo
    P1=LVar:MotionState
    P2=LVar:MotionNumber
    P3=LVar:MotionName

If System::Equals
    P1=%(LVar:MotionState)
    P2=start
    P3=No Case

LocalVars::GetLength
    P1=LVar:MotionName
    P2=LVar:MotionNameLen

LocalVars::Subtract
    P1=LVar:MotionNameLen
    P2=13

LocalVars::GetSubString
    P1=LVar:MotionName
    P2=0
    P3=%(LVar:MotionNameLen)
    P4=LVar:MotionSceneName

Devices::FieldRead
    P1=ISY.LGHT#Sw_%(LVar:MotionSceneName)
    P2=LVar:SceneSwitchValue
    P3=True

If System::Equals
    P1=%(LVar:SceneSwitchValue)
    P2=False
    P3=No Case

Devices::TimedFldChange
    P1=ISY.SCNE#%(LVar:MotionSceneName)Motion-Scene
    P2=On
    P3=Off
    P4=30

End
End

[Dean Roddey]

I don't think it's related to the event ultimately. Is there anything prior to that in the logs showing where the ISY lost its connection? It would almost have to be just shortly before that, else it would have had to be offline for some amount of time and that doesn't seem like it's happening.

Get me a full dump and e-mail it to me. Open the CQC Command Prompt and do:

CIDLogAdmin fulldump /OutFile=whatever.txt

Send me that whatever. txt file.

[Sendero]

OK, I've set driver back to verbose logging and will wait for another repro.

[Dean Roddey]

My guess is that whatever is happening is happening quickly. I.e. something comes in that freaks out the driver, it cycles, and it's back up within a fairly small number of seconds. The issue is how often it's happening, and what is causing it. Other folks aren't seeing this, so presumably it's something to do with your particular ISY configuration. It's hard to say how often it's happening since the only time you know is when you happen to trigger an event at the time when its in between.

You know, this just reminded me that the 5.0 interface has no way to view driver statistics. That has never gotten ported forward. I need to do that, since then we could just let you note the current stats for reconnects, then leave it for a while, then come back and see how much its gone up. That would tell us how often it's happening.

[Sendero]

Just sent you the log file.

I'm also going to go figure out where the ISY is physically in my house and see about moving it to another network connection/location to see if that helps.

On the events triggering it - I'm wondering how many others out there are using Insteon motion sensing to trigger lights.

[Dean Roddey]

From the initial info there's nothing to indicate anything other than that the ISY just dropped the connection. There's only two examples so far captured so it's hard to be sure of any pattern, but there wasn't anything going on that I can see. It just looks like the ISY dropped it.

That connection is passive on our end, we are just listening for events. So I wonder if there's some sort of timeout or something, but that would seem odd for a connection that is known to be passive and it's a TCP level connection so they know we are still there and connected. In one case it had just sent us an event about 20 seconds before the connection dropped.

I guess it could be inactivity on our end in terms of sending out commands, though that's on a separate connection.

But, anyhoo, let's capture some more examples to see if there's any timing pattern or anything like that.