No announcement yet.

mcsMovement question... "Quorum"?

  • Filter
  • Time
  • Show
Clear All
new posts

  • mcsMovement question... "Quorum"?

    Michael, and anyone else,

    I'm looking to add the concept of a "quorum" to Homeseer, and wanted to see if anyone had any thoughts on this.

    Basically, I want to be able to track when it gets dark out (whether it's during the day under adverse weather conditions, or during the evening, where the "dark" transition is more a function of cloud cover), and also when it gets light out (where you have to be careful about MS13/MS14 motion sensors saying "oh, hey, it just got light out" when a bright light turns on in a dark room), and am thinking about the concept of a "quorum" to accurately determine when to transition.

    I have a couple dozen motion sensors that I have in various parts of my property (some in the house, some in the outbuildings, some mounted outside the house). The general idea is that I need to latch a state change after more than one sensor has transitioned from light to dark or dark to light, to make sure that it's not just a single sensor that is either inadvertently covered or is illuminated by artificial light.

    mcsMovement is a great way to pool light sensors, such that if any _one_ triggers, an action is taken. But I don't want to rely on one of them. Is there a way to wait until _two or more_ in a group triggers before an action is taken?


  • #2

    I was thinking about this over the last few...well weeks since we met. I'm actually wondering if you could weight the sensors?

    So, if a sensor trips (ON or OFF) and an associated light is on or off it's weighting is really small. Sensors that are can not easily be influenced (by "human" lighting) should have a larger weighting. THEN if you add up the value of each sensor, the total must meet a threshold to either turn ON or off.

    This way if lights are being turned on "after the latch" you can "automatically" adjust for lights coming on (as the total value would drop...BUT it would drop by a small amount as there was a light on in that room).
    Tasker, to a person who does like walking up to a Crack Treatment facility with a truck full of 3lb bags of crack. Then for each person that walks in and out smack them in the face with an open bag.


    • #3
      The weighted average idea is good and the logic to implement is easy, but the user interface is the harder part. What I did do was add a parameter which is the quorum threshold for the Area device. This number devices need to be ON before the Area device is ON. The Area device continues to go off when all devices are OFF

      See it the attached V1.14.0 works for what you want.
      Last edited by Michael McSharry; August 10th, 2009, 04:55 PM.


      • #4
        Cool, thanks!

        Yes, the weighting option is certainly one way to approach it. I've been mulling over the best way to deal with this problem, and weighting isn't something that had occurred to me. But Michael, thanks for adding a quorum setting. It's maybe a little less elegant, but certainly simpler.

        Now I just need to make sure that I have all of the sensors properly categorized (inside vs. outside, ones that toggle when there's daylight, ones that might inadvertently toggle when inside lights turn on), and go from there.

        Maybe what I'll do is add virtual devices, and when a sensor goes dark, toggle the virtual device. When a sensor goes light, maybe only toggle it if it's not the type of sensor that can be fooled. The count can easily get out of sync at that point, though.

        But what just occurred to me is that maybe it's ok after all to include the foolable sensors in the quorum -- the quorum can't be reached until all of the sensors return to their previous state, which includes the foolable and non-foolable. So even if the foolable sensors transition, it isn't really "light" out again until the non-foolable sensors also transition.



        • #5
          Ok, I installed the updated mcsMovement. Thanks again!

          Question... Is this anything to be concerned about?

          <TABLE cellSpacing=2 cellPadding=0 width="100%" border=0><TBODY><TR><TD class=LOGDateTime1 noWrap align=left>8/9/2009 9:21:34 PM </TD><TD class=LOGType1 align=left colSpan=3>Plug-In </TD><TD class=LOGEntry1 align=left colSpan=8>Initializing Plug-in: mcsMovement</TD></TR><TR><TD class=LOGDateTime0 noWrap align=left>8/9/2009 9:21:34 PM </TD><TD class=LOGType0 align=left colSpan=3>COM Plugin </TD><TD class=LOGEntry0 align=left colSpan=8>Calling InitIO</TD></TR><TR><TD class=LOGDateTime1 noWrap align=left>8/9/2009 9:21:38 PM </TD><TD class=LOGType1 align=left colSpan=3>mcsMovement </TD><TD class=LOGEntry1 align=left colSpan=8>BuildDeviceDictionary on line 610 This key is already associated with an element of this collection</TD></TR><TR><TD class=LOGDateTime0 noWrap align=left>8/9/2009 9:21:45 PM </TD><TD class=LOGType0 align=left colSpan=3>Plug-In </TD><TD class=LOGEntry0 align=left colSpan=8>Finished initializing plug-in mcsMovement</TD></TR></TBODY></TABLE>

          Edited to add: Yeah, apparently it is, because mcsMovement doesn't work. I fell back to the previously installed version (Sep '08), and it loaded correctly this time.

          Last edited by The Keeper; August 9th, 2009, 08:49 PM.


          • #6
            Try this one. V1.14.1
            Attached Files


            • #7
              Thanks, it was able to load successfully, and mcsMovement functions. I'll be updating the algorithm a bit more over the next week or so, and will see if I can get something implemented shortly.