Announcement

Collapse
No announcement yet.

Event firing twice

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

    Event firing twice

    I have two problems that I hope you can solve:
    1. My UPD devices are set to send the events twice (as recommended), but the plug-in does not seem to recognize them as two transmissions of the same command, so the event fires twice. So I have one button that I want to treat as a toggle. Since the event fires twice, the device is quickly turned on and then off. (it is actually two different events with different trigger conditions, so I cannot simply set the 'do not run again for x seconds' parameter). It is a US2-40 switch with an 8-button keypad. Not sure if it is smart enough to know how to activate on one push and deactivate on the next--I'll try that, but it would be better if the plug-in recognized the second occurrence of the same command and ignored it.
    2. This is not the plug-in, but I hope your experience can point me to the culprit. Everytime I push the a button on the device above the event triggers, but I also get four log messages complaining that it got a command for an unknown link #209. There is no link 209 (I even searched the .upe file to make sure something hadn't slipped in there). The interesting thing is that when I run UPstart and look at its log, immediately after it receives the correct link command there is a second log entry saying UPstart is sending a command (and repeating it 4 times) to link 209. Obviously, UPstart is not running when the plugin is running, but something is sending those commands---any ideas what it might be?

    This is the log line from UPstart:
    1,07/12/2015 16:57:14,4/4,27,Indicate,255,,,-209,,,
    "Indicate" is the command.


    Thanks for any help!

    Pete
    Last edited by pete@malibubeach.com; July 12, 2015, 06:48 PM.

    #2
    I can sort of solve both problems in an unsatisfactory manner:
    1. I can set the switch to toggle between activate and deactivate; set up event to distinguish between the two and set the event to not be allowed to re-run for 3 seconds. The problem with this is that there is no way to determine or set the state of each button (on this articular device) as far as I can tell. So, for example, if I turn on the pool filter elsewhere, or it goes on automatically, I have to push this button twice to get it to sent a deactivate. I can write a script that will deal with this but I was hoping for an easier answer.

    2. The link event for link 209 are somehow the result of having a 2-phase repeater---if I remove the power to the phase repeater, these errors go away. I need the phase coupler, so I guess I live with the errors, or I may try another phase coupler that I have sitting around.

    Comment


      #3
      1. Could you send me some debug logs of the two transmissions being received, as well as your .upe file, I can probably fix the plugin so that they are being treated as the same message. Thanks.

      2. Sorry I have no experience with 2-phase repeater.

      Comment


        #4
        Not much to see, but hopefully this helps---reading from the bottom up the first activate triggered an event (and turned on the water to fill the pool). I am not sure why there is a 5 second delay. When I push the same button while UPstart is running, it records a single entry (and says 2 transmissions received). I cannot tell for sure, but I don't think they are really 5 seconds apart (but I could be wrong). And if they are really 5 seconds apart, I have no idea why the four messages caused by the phase repeater wait until after the 2nd message.

        The final four lines (at the top of the log below) are the result of pushing a different button which is not attached to an event at this time. (I did not include the four more extranious commands that I now attribute to the phase repeater)

        The device sending these is device number 83 --- upe file is attached.

        Jul-13 6:02:34 PM UPBSpud DEBUG LINK[105]:: Got Link ACTIVATE
        Jul-13 6:02:34 PM
        UPBSpud DEBUG PIM_RCVR:: Received UPB command [PU89051B695320FFFF7D]
        Jul-13 6:02:29 PM
        UPBSpud DEBUG LINK[105]:: Got Link ACTIVATE
        Jul-13 6:02:29 PM
        UPBSpud DEBUG PIM_RCVR:: Received UPB command [PU89041B695320FFFF7E]

        Jul-13 5:43:44 PM
        UPBSpud DEBUG PIM_RCVR:: Unable to find LINK with ID 209
        Jul-13 5:43:44 PM
        UPBSpud DEBUG PIM_RCVR:: Received UPB command [PU880F1BD1FF260058]
        Jul-13 5:43:44 PM
        UPBSpud DEBUG PIM_RCVR:: Unable to find LINK with ID 209
        Jul-13 5:43:44 PM
        UPBSpud DEBUG PIM_RCVR:: Received UPB command [PU880E1BD1FF260059]
        Jul-13 5:43:44 PM
        UPBSpud DEBUG PIM_RCVR:: Unable to find LINK with ID 209
        Jul-13 5:43:44 PM
        UPBSpud DEBUG PIM_RCVR:: Received UPB command [PU880D1BD1FF26005A]
        Jul-13 5:43:44 PM
        UPBSpud DEBUG PIM_RCVR:: Unable to find LINK with ID 209
        Jul-13 5:43:44 PM
        UPBSpud DEBUG PIM_RCVR:: Received UPB command [PU880C1BD1FF26005B]
        Jul-13 5:43:38 PM
        mcsSprinklers R7(Rain8 Pool Fill) ON
        Jul-13 5:43:36 PM
        UPBSpud DEBUG LINK[98]:: Got Link ACTIVATE
        Jul-13 5:43:36 PM
        UPBSpud DEBUG PIM_RCVR:: Received UPB command [PU89051B625320FFFF84]
        Jul-13 5:43:36 PM
        Device Control Device: Rain8 Pool Fill to On (100)
        Jul-13 5:43:36 PM
        Event Event Trigger "Pool Keypad Button 1 - turn water on"
        Jul-13 5:43:31 PM
        UPBSpud DEBUG LINK[98]:: Got Link ACTIVATE
        Jul-13 5:43:31 PM
        UPBSpud DEBUG PIM_RCVR:: Received UPB command [PU89041B625320FFFF85]
        Attached Files

        Comment


          #5
          Did a little research

          So the second half of the second byte tells you how many times the message is being sent (1-4), and which transmission this is (1-4). So if you ever get one that is transmission # 2 or greater, and that same message was previously received, you should ignore it. I know this is easier said than done as it requires caching the inbound messages for some amount of time so you can check for duplicates. I'm sure the HS2 plug-in did this, as I have never encountered this issue before (so I expect the HS plug-in for HS3 probably dos it too. But, at this point, I have to much time invested in your plug-in (lots and lots of events) to switch easily, so hopefully you can resolve this. (And besides that you had a plug-in while HS sat on the sidelines ignoring UPB in favor of zWave)

          Pete

          Comment


            #6
            Originally posted by pete@malibubeach.com View Post
            So the second half of the second byte tells you how many times the message is being sent (1-4), and which transmission this is (1-4). So if you ever get one that is transmission # 2 or greater, and that same message was previously received, you should ignore it. I know this is easier said than done as it requires caching the inbound messages for some amount of time so you can check for duplicates. I'm sure the HS2 plug-in did this, as I have never encountered this issue before (so I expect the HS plug-in for HS3 probably dos it too. But, at this point, I have to much time invested in your plug-in (lots and lots of events) to switch easily, so hopefully you can resolve this. (And besides that you had a plug-in while HS sat on the sidelines ignoring UPB in favor of zWave)

            Pete
            I implemented this, please test version 3.0.0.19. You should see the following message at debug level when the same message was previously received:
            "Message already received and treated -- message ignored"

            Comment


              #7
              Thank you!!

              Thanks a lot for the quick response. That appears to solve the problem!!

              Pete

              Comment

              Working...
              X