Loading ...
Sorry, an error occurred while loading the content.

Re: [mh] INSTEON motion sensor weirdness

Expand Messages
  • Eloy Paris
    Hi Kevin, ... It d be nice if a warning is sent to the log at insteon debugging level 2 or higher in this situation. It d prevent some head scratching. ...
    Message 1 of 11 , May 14, 2013
    • 0 Attachment
      Hi Kevin,

      On 05/14/2013 08:37 PM, krkeegan@... wrote:

      > On Tue, May 14, 2013 at 7:38 AM, Eloy Paris <peloy@...
      > <mailto:peloy@...>> wrote:
      >
      > 08:19:17 and 09:59:44 are examples.
      >
      >
      > OK 09:54:44 first. To start I see three messages received all at the
      > same time, 2 AllLink_Broadcasts and 1 Cleanup_Direct.
      > - The first AllLink_Broadcast is processed correctly
      > - The second AllLink_Broadcast is actually silently dropped by
      > Insteon_PLM around line 600. It will drop identical (including hop
      > counts) messages that are received in the same pass. (I had forgotten
      > this was in there).

      It'd be nice if a warning is sent to the log at insteon debugging level
      2 or higher in this situation. It'd prevent some head scratching.

      > - The Cleanup_Direct message is then processed. As we discussed before,
      > because it is the same pass, the set_receive loop is called again.
      >
      > A subsequent Cleanup_Direct message is received, this is caught as a
      > duplicate and is "deferred".
      >
      > I tested it out, and multiple calls to set_receive in the same pass will
      > cause a tied_event to fire multiple times. So it looks like we need to
      > prevent this. It should be relatively easy, we can add a check to see
      > if state is equal to state_final.
      >
      > This coding oversight is actually carried through multiple places in the
      > code. The duplicate should have been caught by
      > three separate processes, but it escape all of them for the same reason.

      Thanks for the detailed analysis, Kevin.

      It is not clear to me how many issues we have here, though -- there's
      the "multiple calls to set_receive in the same pass will cause a
      tied_event to fire multiple times" issue. But then you mention that a
      duplicate should have been caught by three separate processes -- is this
      still part of the same issue? Just wondering how many issues I should
      create Github issues for.

      Thanks again for your help with this (which by the way, is not really
      giving me any trouble, but I think it'd be nice to sort out so things
      are 100% clean).

      Cheers,

      Eloy Paris.-


      ------------------------------------------------------------------------------
      AlienVault Unified Security Management (USM) platform delivers complete
      security visibility with the essential security capabilities. Easily and
      efficiently configure, manage, and operate all of your security controls
      from a single console and one unified framework. Download a free trial.
      http://p.sf.net/sfu/alienvault_d2d
      ________________________________________________________
      To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
    Your message has been successfully submitted and would be delivered to recipients shortly.