Announcement

Collapse
No announcement yet.

unexpected behavior

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

  • unexpected behavior

    I'm trying to get a hardwired motion detector (connected via ADIOcelot) to trigger an area device. The motion detector (md) for some reason reports to homeseer as ON, but C-max shows it as OFF (not sure why homeseer shows different status vs. C-max?? (I have adjusted parameters 2 & 3 in the Secu16, which control voltage limits for ON/OFF, I do not have the house code inverted in ADIOcelot)) Otherwise triggering the md works as expected in hs.

    Ultimately I want to have an X10 light switch control the lights for the room via the area device.

    So in mscMovment setup>managed devices, I select the md for managment and sensor type On/Off . . this immediately makes the md report as OFF in homeseer (not sure why changing the sensor type should change the status?) . . and changing the sensor type back to Off/On does not cause the device to change back to ON, but leaves it OFF (tripping the md at this point will resync homeseer and the md to it's regular ON=OK, OFF=TRIP behavior.)

    left in this configuration the light doesn't actually turn on until the md resets, and then only for 2-3 sec (ie: as long as there is motion the light won't come on, but does once motion stops, then goes off)

    the best I can do to get the desired end result is to set the device to Off/On which turns the light off after the time set in 'Time after ON til OFF Generated' but again the light doesn't actually turn on until the md resets (ie: as long as there is motion the light won't come on, but does once motion stops, for the set amount of time)

    all of this is with two events, one to turn on the lights when the area device turns on, and one to turn the lights off when the area device turns off, which should work the same in all of the above senarios if I'm reading the mcsMovement_Readme file correctly

    any ideas ? ?

    Thanks

    Pete C

  • #2
    I ran a test where I defined an area device and placed a single managed device in that area. I used A2 as the managed device and declared it to an ON-OFF type. I set the timing on the Area device to be 30 seconds ON to ON and 120 seconds OFF to OFF.

    The initial state of the Area device happened to be ON. I used palmpad to deliver a A2 OFF and there was no change in the Area device. I then delivered an A2 ON and in about 2 minutes the Area device turned OFF.

    I changed the Area device ON to ON time to 0 and delivered an A2 OFF and the Area device turned ON immediately.

    The above is the behavior that I expect.

    In your case you have a motion sensor that I assure you want to turn the Area device ON immediately after the motion sensor goes to OFF status (motion detected). This means your Area ON to ON will be 0.

    You want the Area device to go OFF perhaps 5 minutes after the last motion was detected so set the OFF to OFF time to 300 seconds. If during that 300 seconds motion is detected then the 300 second timer will restart at the motion sensor status ON to OFF transition time and the Area device will not turn OFF until 300 seconds past this new time.

    Comment


    • #3
      Been trying different settings for a few days now, so I'm sure that I have tried the senerio you describre, but will try again this evening, using your suggestions to make sure it's not 'operator error' . .

      in the meantime, should changing the 'sensor type' from Off/On to On/Off cause the md status to change from ON to OFF in hs ?

      . . it does (repeatable) with my md via ADIOcelot, this reversal then remains in effect causing the md to report as OFF=OK and ON=TRIP in hs as long as I have the device set to On/Off sensor type . .

      Comment


      • #4
        The sensor type setting affects the behavior the next time the source sensor state change is received. There is nothing in the plugin to try to synchronize internal and HS status when a sensor type changes. This logic occurs when the sensor state change event occurs.

        Does your motion sensor send OFF ON OFF ON OFF ON OFF when someone enters into its field of view or does it send OFF ON ON ON ON OFF. Homeseer only provides a callback to the plugin when the status changes or in the case of X10 it can be done on each ON or OFF. When you set your timing parameters you need to be aware that the plugin only sees OFF/ON and ON/OFF transistions.

        Comment


        • #5
          this is an older PIR, you can hear a relay click when tripped, it is hardwired to a SECU16, which is connected to a Leopard, then to HS via ADIOcelot . . I would think it's HS device changes to OFF when tripped, then remains OFF until no longer sensing motion, at which point it returns to ON, I don't think it repeatedly sends anything when tripped (I don't hear the realy clicking), . . unless ADIOcelot is doing something different . . the md does not register status changes within the HS log, so thats no help . .

          . . if changing the sensor type to On/Off causes the device's status to change from ON to OFF (if I click the option in mcsMovement>setup, and immediatly refresh the status page in another window, the device will have changed status, the md has not been tripped) won't that make it act like an Off/On type and cause a reverse in expected actions ? ?

          also, when reviewing the logs I notice this error after exiting mcsMovement>setup . .

          mcsMovement~!~EventExistsWithScript on line 130 Object doesn't support this property or method

          . . I have 'Run no Script' selected on all device tabs, for all devices ? ?

          Comment


          • #6
            Are you running the more recent version where I made changes to deal with the error message you received in another recent thread?

            You should not have any expectations from the device status immediately after you change the device type. You can only expect to see different behavior after the sensor, the plugin, and Homeseer all sync up upon the next sensor status change delivered to HS via ADIOcelot and then to mcsMovement as part of the callback.

            In general the ON-OFF type and the OFF-ON type will act in opposite. An ON-OFF device will trigger an Area device to be ON when the sensor report via HS goes from ON to OFF. An OFF-ON sensor will cause the Area device to go ON upon the OFF to ON transition of the sensor via HS.

            Comment


            • #7
              Originally posted by Michael McSharry View Post
              Are you running the more recent version where I made changes to deal with the error message you received in another recent thread?
              yes, I replaced the .ocx file in the homeseer directory . .


              You should not have any expectations from the device status immediately after you change the device type. You can only expect to see different behavior after the sensor, the plugin, and Homeseer all sync up upon the next sensor status change delivered to HS via ADIOcelot and then to mcsMovement as part of the callback.
              that's my problem, upon changing the device sensor type it changes status, which I don't expect to happen, but it does

              In general the ON-OFF type and the OFF-ON type will act in opposite. An ON-OFF device will trigger an Area device to be ON when the sensor report via HS goes from ON to OFF. An OFF-ON sensor will cause the Area device to go ON upon the OFF to ON transition of the sensor via HS.
              which is how the help file explanis it, but with the device changing status after simply changing it's sensor type, I think it's working the opposite . .

              got side tracked last night (had to change a clutch cylinder on my car), so I didn't get to work on this . . will try again tonight . .

              thanks again for your assistance . .

              Comment


              • #8
                got around to testing per your post . .

                . . created a kepad device P1 . . in mcsMovement(mcsM)>setup>managed devices I dblClicked to move the P1 device to the right side . . I change sensor type to On/Off . . and exit mcsM>setup . . open hs>status . . using a palpad I can control P1 as expected . .

                open mcsM>setup>area devices and select device P1 for area V2 . . exit mcsM>setup . . open hs>status . . P1 is OFF . . if I press P1/ON and refresh hs>status, P1 shows OFF, V2 shows Occupied and elapsed time has reset . . toggling P1 and refreshing hs>status always has P1 as OFF and V2 as Occupied, but an ON resets the elapsed time for V2 . .

                . . I would expect P1 to show ON and V2 to show Vacant after I send a P1/ON from the palmpad, but it doesn't . .

                open mcsM>setup>area devices and set 'Min Time OFF before going OFF' to 30 secs . . exit mcsM>setup . . open hs>status . . P1 is OFF, V2 shows Occupied . . if I press P1/ON and refresh hs>status, P1 shows ON, V2 still shows Occupied . .

                . . if I wait the 30 secs and refresh hs>status P1 is OFF, V2 shows Occupied and elapsed time has reset . .

                not sure what is going on . . any ideas ? ?

                Comment


                • #9
                  This was a hard one to track down. I forget why I was forcing all devices that comprise an Area to be at the correct state when the Area devices changes state. It is as if I was allowing a user to reset all devices that comprise an area by setting the status of the area. In any case the latest version should handle the ON-OFF sensor in an area properly.

                  Comment


                  • #10
                    thanks . . took a while for me to figure out I wasn't doing it wrong too . .

                    will update this evening . . hopefully getting it to work will be easier now : )

                    Comment

                    Working...
                    X