Announcement

Collapse
No announcement yet.

Odd script errors that I can't quite track down...

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Odd script errors that I can't quite track down...

    Michael, or anyone else,

    Does anyone have any suggestions as to how to figure out what the problem is here? I've seen it before, but only occasionally, and generally it would only happen once, so I just let it go. Now it's happening every time there's movement in the affected area.

    I added a bunch of area sensors to mcsMovement, and specified them as "Off/On" types, which is what I use for most of my door-type inputs, and now all of the ones I added result in this:


    <TABLE cellSpacing=2 cellPadding=0 width="100%" border=0><TBODY><TR><TD class=LOGDateTime0 noWrap align=left>8/14/2009 8:00:53 AM </TD><TD class=LOGType0 align=left colSpan=3>LogMotionMain </TD><TD class=LOGEntry0 align=left colSpan=8>House Second Floor Occupancy, Type:2, IsOn</TD></TR><TR><TD class=LOGDateTime1 noWrap align=left>8/14/2009 8:00:53 AM </TD><TD class=LOGType1 align=left colSpan=3>mcsMovement </TD><TD class=LOGEntry1 align=left colSpan=8>Script Run Error Object variable or With block variable not set / 0 - @ Line 0 col 0 on line 40 Object variable or With block variable not set</TD></TR><TR><TD class=LOGDateTime0 noWrap align=left>8/14/2009 8:00:54 AM </TD><TD class=LOGType0 align=left colSpan=3>LogMotionMain </TD><TD class=LOGEntry0 align=left colSpan=8>House First Floor Occupancy, Type:2, IsOn</TD></TR><TR><TD class=LOGDateTime1 noWrap align=left>8/14/2009 8:00:54 AM </TD><TD class=LOGType1 align=left colSpan=3>mcsMovement </TD><TD class=LOGEntry1 align=left colSpan=8>Script Run Error Object variable or With block variable not set / 0 - @ Line 0 col 0 on line 40 Object variable or With block variable not set</TD></TR></TBODY></TABLE>

    Any suggestions?

    I added both of those occupancy sensors to the movement.txt file.

    Thanks,
    Chris

  • #2
    Ok, looks like I figured it out. It was because I had set up the area devices as "On/Off" devices when I should have set them up as "Off/On" devices.

    And I'm trying to think of the implications behind this statement:
    A dusk or OnOff sensor when OFF will cause an area device to the ON state.

    I haven't used a dusk sensor with mcsMovement yet, but I'm getting pretty close to figuring out the algorithm for the quorum feature. The trick is more a function of dealing with sensors that misbehave in some way -- meaning motion sensors that either fell over or were covered at some point during the day, or maybe a dusk/light transition occurred but the RF signal was not received for whatever reason.

    Anyway, Michael, could you please confirm what will happen? When an X10 "ON" is received from a dusk sensor, then that means that the sensor thinks it's dark out. How is that state change translated by mcsMovement? Is a received X10 "ON" from a dusk sensor treated as an "ON" state change in mcsMovement? If there's only one managed dusk device in an area, will a received dusk sensor "ON" cause the area device to go "OFF"?

    What are the implications for the quorum? Do the specified number of dusk sensors need to go "OFF" (meaning it's light) before the area device goes "ON"? And all dusk sensors need to go "ON" (meaning it's dark) again before the area device goes "OFF" again?


    Thanks,
    Chris


    Comment


    • #3
      The script errors should not be a function of the sensor type declaration. Do you have any of the run script options slected on the page for the managed, movement, or area sensor associated with the device?

      Once you declare a sensor to be of dusk/dawn type then then instant mcsMovement received the X10 it will invert the sensor state received. From that point on it is treated with normal logic. If two dusk/dawn sensors that are declared as dusk/dawn in mcsMovement are in an Area then the Area status will be true if either X10 sensor has last reported dawn (OFF).

      Comment


      • #4
        Yes, actually, all of my devices call "movement.txt" with the subroutine "main". Once inside there, I figure out what type of sensor it is, and then whether it's currently on or off. Then various subroutines are called based on that determination. I was handling the "OffOnSensor" type, but not the "OnOffSensor" type, so when I switched, the new area devices were handled.

        Ok, good to know that the dusk sensors simply have their status flipped before processing the state. Makes sense. I can work with that.

        Thanks,
        Chris

        Comment


        • #5
          Ok, I guess I lied. I'm still seeing the errors for those area devices. Maybe it's not every time, so that might be why I thought I fixed the problem.

          You're allowed to manage area devices, right?

          I have seen this problem, off and on, for a couple years, but it was usually only when I loaded then closed mcsMovement's setup interface.

          Every managed device goes to movement.txt with main, and I think I probably used your movement.txt file as a basis.

          This is what's at line 40 of the script (out of 1356 lines; so it takes quite a while to load/close), by the way:
          " if hs.isOnByName("Flags Flag -- Ignore On Sensor") then"
          but I know mcsMovement precompiles the script, so I'm wondering if the line numbers don't match up in that case...

          Thanks,
          Chris

          Edited to add: I just turned off the optimized script, and had it run from HS, and it didn't change the behavior. It's still complaining about line 40.

          Comment


          • #6
            I suspect that Area devices and Movement devices cannot also be Managed devices. While I did not think it through it could lead to circular logic.

            Comment


            • #7
              AAAAAaaahhhh, ok, that makes sense then.

              Basically, what I was doing was abstracting the sensors from the occupancy (area) devices. And then from there, I was going to start basing certain behaviors on whether or not there's any occupancy in any of the areas, which would also be abstracted.

              Ok, not a big deal, I can easily create more flag devices. When an unmanaged area device changes state, then I'd have homeseer itself copy that state to a managed device which would be included inside another area device.

              Thanks for the clarification.

              Chris

              Comment


              • #8
                I guess we both forgot that it looks like the area devices are implicitly supported by mcsmovement, insofaras the movement.txt script file with the routine of "main" is called when one of the area devices triggers, even if it's not managed. (Or at least that's what it looks like, anyway -- the only way the script file could be called is if mcsmovement is doing it on its own volition.)

                Chris

                Comment


                • #9
                  Yes that makes sense that movement and area changes will trigger the script. Are you indicating that this is causing a problem?

                  Comment


                  • #10
                    No, actually, no problem at all. I just wasn't expecting it. Basically, as long as the behavior is deterministic and not random, I can work with just about anything.

                    (Any further thoughts on managing area devices, or should I just set up homeseer events to toggle the states? The latter is ok, if you want to leave it that way.)

                    Thanks,
                    Chris

                    Comment

                    Working...
                    X