Announcement

Collapse
No announcement yet.

mcsMQTT - High CPU Utilization

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

  • mcsMQTT - High CPU Utilization

    I am experiencing high cpu utilization with the mcsMQTT plugin. It generally stays around 92-94% with the total CPU utilization at 98%. When i disable the plugin the CPU utilization reduces to a normal amount. Is there anything i can do to reduce the utilization of this plugin?

    8 GB Memory, (Intel Core 2 Duo P8400) 2.27 GHz Processor - 2 Cores (1 socket)

    Current Date/Time: 2/28/2018 12:44:01 PM
    HomeSeer Version: HS3 Standard Edition 3.0.0.368
    Operating System: Microsoft Windows 10 Enterprise - Work Station
    System Uptime: 3 Days 0 Hours 5 Minutes 24 Seconds
    IP Address:
    Number of Devices: 137
    Number of Events: 60
    Available Threads: 200

    Enabled Plug-Ins
    3.0.0.33: EasyTrigger
    3.7.0.0: Harmony Hub
    3.0.0.29: iTunesDAAP
    3.0.8.1: mcsMQTT
    1.2.2.0: SceneMaster
    3.0.0.76: weatherXML
    3.0.1.130: Z-Wave

  • #2
    Check your task manager to see if more than one instance of the plugin is running. I've seen this happen when it doesn't start initially and you then try to restart it.

    Z

    Comment


    • #3
      Did you resolve the high CPU use?

      When using htop on Odroid C1/Linux I see it is using between 0% and 2% CPU with about the same being used by HS. On Windows laptop Task Manager shows similar for both. I have about half dozen clients that are publishing during this evaluation.

      The CPU use will be a function of the number of HS devices that are changing value, especially those who have been selected for publication. It is also a function of the number of publications by the MQTT broker sent to mcsMQTT.

      A provision was added in 3.0.8.0 to control topic discovery which will have the effect of reducing the messages sent between broker and mcsMQTT. It is a radio button option toward the top of the setup.

      Comment


      • #4
        Tonight i made changes to the mcsMQTT config page to enable "Listen for only Accepted messages" and "Disable New Topic Recognition". When i enabled them the CPU did drop, however the plugin didn't update the devices in a timely manor. I disabled the option and re-enabled them again. It seems to now be keeping pace.

        My CPU is running at 13% and mcsMQTT is running around 2-5%.

        I will let you know if i run into any additional issues. I greatly appreciate your assistance.

        Since i have your ear - in regards to REGEX - i have had a hard time trying to figure out how to strip the quotes from the MQTT data being written to the devices. For example, how do i strip out the quotes for

        "/api/media_player_proxy/media_player.master_bedroom_speaker?token=b0b37dc76a3ca8c3b0 b0cafa03107515b4e44caec3c2a0efb6d7db552e4117dc&cache=7e99e06 f97f6c13d"

        I have tried:


        [a-zA-Z0-9\/?=&._]

        [^\"*]

        (["'])(??=(\\?))\2.)*?\1

        with no success.

        I have also looked at the Microsoft documentation referenced in your documentation dated in 2018 - i cant figure it out. Any assistance would be appreciated.

        Thanks!!

        Comment


        • #5
          I suspect the update rate change is related more to the broker than it is to mcsMQTT. It could be that with a longer list of specific topics it takes the broker longer to forward a message to mcsMQTT than if it knows every topic is forwarded. There is no specific requirement that I am aware for latency between when broker receives a topic until when it distributes it to subscribers.

          To remove the quote, can't you just put the quote in the search box, leave the replace box blank and leave the extract checkbox unchecked. It would be like the first example included with mcsMQTT manual.

          Comment


          • #6
            As another thought if you want to investigate further then mcsMQTT debug checkbox can be used and in the /data folder the debug file will show the timing of each message from the interrupt provided from the OS. Even closer to the hardware would be using Wireshark to capture port 1883 traffic. In verbose mode the broker also displays details where message timing may be able to be determined.

            Comment


            • #7
              Regarding the quote - I appreciate your help. It worked. I was over-complicating how to make the change.

              I will give the debug recommendation a try. Thank You for your help.

              Comment

              Working...
              X