Announcement

Collapse
No announcement yet.

Constant Rebuilding VR commands due to configuration change

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

    Constant Rebuilding VR commands due to configuration change

    Hi Nathan

    The Speaker application shows what is below and is using bandwidth as well as other issues. I have found when I turn off the napco plugin this stops any solution to this issue??

    THANX
    MITCH

    /29/2018 2:15:24 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:15:28 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:16:28 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:16:31 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:16:54 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:20:31 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:20:34 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:20:35 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:20:57 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:22:55 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:23:03 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:23:04 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:23:33 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:23:34 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:23:38 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:24:34 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:24:38 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:25:00 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:25:07 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:25:08 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:25:10 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:28:38 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:28:41 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:29:03 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:31:13 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:31:14 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:31:16 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:31:18 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:31:22 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:31:27 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:31:28 PM:Rebuilding VR commands due to configuration change
    6/29/2018 2:31:35 PM:Rebuilding VR commands due to configuration change

    #2
    someone else had the same issue

    DigitalMatrix reported this issue a month ago and I see there is no resolution posted

    please get back to us on this

    Comment


      #3
      Mitch,

      I think maybe you're referring to this post by DigitalMatrix back in 2015 about this topic? I did some additional searching today which led to other posts related to other plugins. It appears that any device value/string change causes this behavior in the speaker client. Also seems possible any event changing might trigger this. HST (Rich) has indicated it's not a problem but how the system works, per other posts.
      The Napco plugin updates device values from both direct events like zone open/close and also from bus updates. My thought is those bus updates change device values leading to that behavior from the speaker client? Those bus updates are valid and it's how the system works. If this is truly causing excessive overhead, I think we'd need to quantify that. It's not a behavior limited to the Napco plugin.


      Nathan
      HS 3.0.0.435 (PRO)
      Hardware: Napco GEM-P9600 | VenstarT1800 w/Insteon 2441V adapter | Insteon PLM
      Plugins HS3: Napco Gemini (mine) | Insteon Thermostat (mine) | Insteon Plug-in (mnsandler) | HSTouch Server (HST)
      Platform: Windows 10 Pro 64bit, core2 duo 2.0Ghz, 4GB memory
      http://www.kazteel.com/

      Comment


        #4
        it causes many problems

        first let me say I have not had this issue with other plugins but I have not tried them all.
        having this issue not only causes unnecessary bandwidth use on the network but is also creates the issue that if a voice notification is missed and you go to look it is scrolled away before you can find it.

        Tyler at HS told me to post the initial issue I told him I think it is a HS issue and not a plug in issue but he insisted that I get you in the loop. I would talk to Richard and see if there is a way to stop this behavior

        THANX
        MITCH

        Comment


          #5
          Hi Mitch,

          I guess you can consider me in the loop but I'm not sure what can be done for this. The Napco plugin doesn't do anything related to the speaker client. It may be updating virtual device values more often than other plugins due to the Napco bus updates but that's how it's designed to work. I'm not currently able to test this but will as soon as I can to see if I can get similar speaker client logs.

          Nathan
          Last edited by nfrobertson; July 7, 2018, 12:40 PM.
          HS 3.0.0.435 (PRO)
          Hardware: Napco GEM-P9600 | VenstarT1800 w/Insteon 2441V adapter | Insteon PLM
          Plugins HS3: Napco Gemini (mine) | Insteon Thermostat (mine) | Insteon Plug-in (mnsandler) | HSTouch Server (HST)
          Platform: Windows 10 Pro 64bit, core2 duo 2.0Ghz, 4GB memory
          http://www.kazteel.com/

          Comment


            #6
            Mitch,

            I'm back and testing the Napco plugin v3.0.2.1 using HS3 3.0.0.435 (windows) I can see the keypad bus updates every minute in the log. I can open a zone and see the zone device change and also see the zone-faulted messages on the keypad bus coming into the Napco plugin. I can Arm and Disarm the area which updates every zone device. I have played with the speaker client including setting it to listen and told it to run some manual trigger events and that's all working.

            What I so far can't cause to happen is the issue you're reporting "Rebuilding VR commands due to configuration change"

            At this point I assume we need to start looking at the events you have created and what intersection there may be between the Napco plugin, through the events in HS3, to the speaker client? Napco has special triggers/conditions. are you using those in events that then have an action related to the speaker client somehow? Could you try leaving the Napco plugin running, but disable events related to it to see if the message stops after a particular event is disabled?

            Have you changed any virtual device settings on any of the virtual devices controlled by the Napco plugin that might cause different speaker client behavior?

            Nathan
            HS 3.0.0.435 (PRO)
            Hardware: Napco GEM-P9600 | VenstarT1800 w/Insteon 2441V adapter | Insteon PLM
            Plugins HS3: Napco Gemini (mine) | Insteon Thermostat (mine) | Insteon Plug-in (mnsandler) | HSTouch Server (HST)
            Platform: Windows 10 Pro 64bit, core2 duo 2.0Ghz, 4GB memory
            http://www.kazteel.com/

            Comment

            Working...
            X