Announcement

Collapse
No announcement yet.

Plug in start-up

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

  • Plug in start-up

    When the plug-in starts, it goes out and polls each device (I think). This process seems to take a very long time: right now, for example, I started the plug in over 20 minutes ago and it appears to be on device id 78. So basically there is a 30 minute window whenever I start HS that your plugin is polling devices.

    Two questions:
    1. Is this normal? Should it be taking 20 seconds or so per device?
    2. Other than high CPU usage (both for HS3 and HSPI_UPBSPUD), is there any implication? Anything that won't work right during this 20 or 30 minute period?

  • #2
    1. Yes this is the expected behaviour. The plugin poll each device at startup to sync HS device status with the real UPB devices. If a device can't be reached, it retries a maximum of 5 times.
    That being said I could add a setting to make this initial polling optional.

    2. I don't think there is any other implication

    Comment


    • #3
      It now seems to be taking nearly 2 minutes per device . . . And during that time commands to other devices seem to be stalled ... I had some lights turn on and off an hour after the plugin restarted (stopped it to run upstart). If the polling can be done as a background activity where other CAPI requests are bumped to the top of the queue, that would be fine, but with over 80 devices, it takes something like 2 hours now for everything to get initialized and the plug-in to start behaving normally.

      So I guess that is a long way of saying that's an option to disable the start-up polling would be appreciated.

      Here is a log file snippet of the 2-minute interval for one of the devices:
      Aug-03 7:25:52 PM UPBSpud DEBUG UPB_MGR:: STATE_QUEUE:: Sending state query for device Driveway Light (8)
      Aug-03 7:25:40 PM UPBSpud DEBUG PIM_SEND:: UPB Device ACK'd current message (ID=7)
      Aug-03 7:25:40 PM UPBSpud DEBUG PIM_SEND:: Message ID 7 confirmed sent successfully
      Aug-03 7:25:32 PM UPBSpud DEBUG PIM_SEND:: PIM ACK'd current message (ID=7)
      Aug-03 7:25:24 PM UPBSpud DEBUG PIM_SEND:: ABOUT_TO_SEND[07141B07FF3094 ]
      Aug-03 7:25:16 PM UPBSpud DEBUG PIM_SEND:: Sending Message ID 7 to PIM, retry count=1
      Aug-03 7:25:06 PM UPBSpud DEBUG PIM_SEND:: UPB Device ACK'd current message (ID=7)
      Aug-03 7:25:06 PM UPBSpud DEBUG PIM_SEND:: Timeout waiting for PIM response -- now trying to send command again
      Aug-03 7:25:02 PM Z-Wave Device: Node 13 Z-Wave Luminance 2 Set to 0 (%)
      Aug-03 7:25:01 PM Z-Wave Device: HSM200 Garage Luminance Set to 14 (%)
      Aug-03 7:24:56 PM UPBSpud DEBUG PIM_SEND:: PIM ACK'd current message (ID=7)
      Aug-03 7:24:48 PM UPBSpud DEBUG PIM_SEND:: ABOUT_TO_SEND[07141B07FF3094 ]
      Aug-03 7:24:40 PM UPBSpud DEBUG PIM_SEND:: Sending Message ID 7 to PIM, retry count=0
      Aug-03 7:24:32 PM UPBSpud DEBUG PIM_SEND:: Extracted next message to send from queue (ID 7)
      Aug-03 7:24:19 PM UPBSpud DEBUG PIM_SEND:: Resuming sending after waiting a refreshing 600ms
      Aug-03 7:24:19 PM UPBSpud DEBUG PIM_RCVR:: Received UPB command [PU08051BFF0686004D]
      Aug-03 7:24:11 PM UPBSpud DEBUG PIM_SEND:: Pausing because last command expected a reply
      Aug-03 7:23:59 PM UPBSpud DEBUG UPB_MGR:: passing queueMessage for UPB message to media-adapter
      Aug-03 7:23:50 PM UPBSpud DEBUG DEVICE[6]:: Level changing on channel 0 from -1 to 0
      Aug-03 7:23:50 PM UPBSpud DEBUG UPB_MGR:: STATE_QUEUE:: Sending state query for device China Cabinet (7)

      One more update --- after a while it started overlapping things and got a little faster, but in the end it took well over an hour to poll 83 devices.

      Pete
      Last edited by pete@malibubeach.com; August 3rd, 2015, 10:17 PM. Reason: Add log file snippet

      Comment


      • #4
        done in version 3.0.0.23, there is now a checkbox in the config page to disable the initial polling.

        Comment


        • #5
          Originally posted by pete@malibubeach.com View Post
          When the plug-in starts, it goes out and polls each device (I think). This process seems to take a very long time: right now, for example, I started the plug in over 20 minutes ago and it appears to be on device id 78. So basically there is a 30 minute window whenever I start HS that your plugin is polling devices.

          Two questions:
          1. Is this normal? Should it be taking 20 seconds or so per device?
          2. Other than high CPU usage (both for HS3 and HSPI_UPBSPUD), is there any implication? Anything that won't work right during this 20 or 30 minute period?
          Hi Pete,

          I have not noticed this issue at all with my installation. I have exactly 40 UPB Devices right now in UpStart. 8 of those are Sprinkler Zones for a Rain8UPB controller that time out with 5 retries each due to it not being a proper UPB Device so they take a bit longer to update. That said, all 40 devices are finished updating in less than 2-3 minutes. While it's nice to have the option to disable the initial polling of the devices (thanks for that suggestion, thanks to Spud for implementing it), I would be more concerned with why it would take so long for your UPB network to essentially sync it's status with the plug-in. Curious if you running on a Raspberry Pi or something or have Signal Interference on your UPB Network....


          -Travis

          Comment


          • #6
            I have a phase repeater in my network --- I thought I needed it a while back (but the problem at the time was a dead switch that was sucking up the UPB signals). I'm going to try uninstalling and reinstalling the more normal phase coupler that used to be there. I'll see if that changes anything.

            BTW, my system is running on a HomeTroller series 4( I think). Not the fastest box in the world but it should be very adequate.

            I appreciate the input--- 3 minutes (or 6 minutes for my 83 devices) would be fine.

            Pete

            Comment

            Working...
            X