Announcement

Collapse
No announcement yet.

Excessive CPU and Excessive MQTT Topics

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

    #16
    Very good. I will look at your files tomorrow. I also have some of you suggestions implemented for publish topics and tool tips and test those out tomorrow as well.

    Comment


      #17
      Your debug shows a significant amount of HS3 device change events being generated. What I did was streamlined this processing and discarded most immediately. While the timing was only 10 milliseconds for each event its frequency could add up quickly to some real cpu use. You can evaluate 2.10.0.0 to see if the steady state cpu use has improved.

      Along with this change I also provided the user the ability to better control the published topic and payload for HS3 device changes. The rightmost column now contains three checkboxes for Accepted non-plugin devices. This will determine if the payload will be the DeviceValue, the DeviceString, or the Status (text) based on the DeviceValue. If only the DeviceString changed and DeviceString was not selected via checkbox then no published message would be sent. The same is true for Value/Status and DeviceValue change. Previoulsy Status was not available and value and string were always sent based upon the Device property change.

      On a related item I implemented your change to allow the user to control the non-plugin topics being published. They default to the prior nomenclature, but can be anything just like the plugin devices can be set to anything for the topic.

      Both of these changes only become visible when a device has been Accepted. I tried to dynamically make the options available upon selecting Accept checkbox, but still have no success with dynamic update via Ajax of div tags. It means that a rebuild/refresh is needed after a set of devices have been Accepted. I did post for other developers ideas on why my dynamic updates are not working.

      I removed the last section that allowed entry of new topics and HS3 devices. It really became redundant with the improved integration with the non-plugin devices.

      Tool tips were also added per your suggestion.

      I looked at the timing for page builds in two environments. One was a old laptop running Intel T2080@1.67Ghz. The other was an Odroid C1 SBC which is similar to a RPi3 and likely about the same as the T2080. What is shows it that there is significant time building the filters, populating a sort dataset and sorting the main table. The actual rendering of the page whas pretty quick. The times in seconds is shown for the two test cases. One with 257 and one with 508 rows.

      Code:
      	1.7Mhz Dual Core Intel T2080
      	        | Page Timing Start  
      1.425	| Page Timing Filters Done  
      0.268	| Page Timing Sorted Table Built  
      1.861	| Page Timing Sort Done  
      0.47	        | Page Timing Page Built row count= 257  
      	
      	
      	Odroid C1
      	        | Page Timing Start  
      2.354	| Page Timing Filters Done  
      2.591	| Page Timing Sorted Table Built  
      2.943	| Page Timing Sort Done  
      1.915	| Page Timing Page Built row count= 508

      Comment


        #18
        Upgraded to 2.10.0.0 and deleted the existing databases. The plugin page appears to be more responsive, by a second or two, which is great. If Show Only Accepted is checked, the page loads in about a second. If unchecked it loads in about 27 to 29 seconds. That's a step in the right direction. Would be nice if there is anything that could be done to reduce the load on all topics.

        All non-plugin devices have HS Device IDs, good work on that!

        Tooltips look great too.

        One thing I noticed is that it takes the plugin 45 seconds to initialize at startup. Is this normal? Below is the startup entry from the HS log. Is there anything that can be done about that?

        Code:
        Plugin mcsMQTT started successfully in 45328 milliseconds
        Here are the startup logs from other plugins for reference.

        Code:
        Plugin Pushover 3P started successfully in 38 milliseconds
        Plugin APCUPSD started successfully in 2971 milliseconds
        Plugin MeiHarmonyHub started successfully in 1127 milliseconds
        Plugin UltraWeatherWU3 started successfully in 4824 milliseconds
        Plugin Z-Wave started successfully in 2767 milliseconds
        Plugin Ecobee started successfully in 263 milliseconds
        Plugin DoorBird started successfully in 202 milliseconds
        Plugin RFXCOM started successfully in 2853 milliseconds
        Plugin Device History started successfully in 1483 milliseconds
        Plugin EasyTrigger started successfully in 3835 milliseconds
        Plugin SDJ-Health started successfully in 176 milliseconds
        Plugin Blue-Iris started successfully in 1355 milliseconds
        Overall CPU load looks good as well. Screenshot attached.
        Attached Files

        Comment


          #19
          I do not think there is too much I can do with the setup page load times and still present the data in an organized manner. The best strategy there is to use filters pulldowns and checkboxes to reduce the volume of information that needs to be displayed. I will look to see if anything meaningful can be done in this area. The debug output still contains the timing breakdown of the page build/render segments that I showed timing above. Take a look to see your breakdown. If there is a big hitter then it provides focus for optimization.

          mcsMQTT has visibility into all HS devices so at some time it will need to look to see what devices do exist. It is likely that this could be made a user action to refresh the HS device list as it will not occur that often. There is already a button on the setup page to do that. I will see what can be done to reduce the initial big hit for initialization.

          Where do you find the startup times that you showed in the last post? I do not have that info in the HS3 Log page other than a more gross level of 11 seconds in my case on Odroid C1.
          Code:
          Mar-15 12:37:39 AM	 	Plug-In	Finished initializing plug-in mcsMQTT
          Mar-15 12:37:39 AM	 	mcsMQTT	MQTT Broker Connection Accepted
          Mar-15 12:37:28 AM	 	mcsMQTT	Version 3.0.10.1 Registered with Homeseer
          Mar-15 12:37:28 AM	 	Info	Plugin mcsMQTT has connected. IP:127.0.0.1:34545

          Comment


            #20

            Comment


              #21
              I saw the same here Matt very first time I installed and used it.

              HS3 Pro V.423 running on an Ubuntu 16.04 64bit / iSeries 3 / 16Gb went to a crawl (HS3 pegged at 100% utilization)
              I did get a long list of HS devices but no variables were created.

              I did not care for the Homeseer devices such that I played with it until all I saw was my new test RPi 1-Wire hub.

              Just loaded new version from this morning and see: (which is closer to a minute here)

              Mar-15 9:57:43 AM Plug-In Finished initializing plug-in mcsMQTT
              Mar-15 9:57:43 AM Info Plugin mcsMQTT has connected. IP:127.0.0.1:59158
              Mar-15 9:57:44 AM Starting Plug-In Initializing plugin mcsMQTT ...
              Mar-15 9:57:44 AM mcsMQTT Version 3.0.10.0 Registered with Homeseer
              Mar-15 9:57:47 AM mcsMQTT MQTT Broker Connection Accepted
              Mar-15 9:57:47 AM Starting Plug-In Plugin mcsMQTT started successfully in 3630 milliseconds

              Shut down V.10 and updated to V.11.

              Install/Update of package mcsMQTT was successful.

              Mar-15 10:04:58 AM Plug-In Finished initializing plug-in mcsMQTT
              Mar-15 10:04:58 AM Info Plugin mcsMQTT has connected. IP:127.0.0.1:60258
              Mar-15 10:04:58 AM Starting Plug-In Initializing plugin mcsMQTT ...
              Mar-15 10:04:58 AM mcsMQTT Version 3.0.10.1 Registered with Homeseer
              Mar-15 10:05:01 AM mcsMQTT MQTT Broker Connection Accepted
              Mar-15 10:05:01 AM Starting Plug-In Plugin mcsMQTT started successfully in 3640 milliseconds

              Prior was the Omni Plugin that was slow loading...(know here I am mixing apples and oranges).

              Mar-15 10:09:47 AM Plug-In Finished initializing plug-in OMNI
              Mar-15 10:09:48 AM Info Plugin OMNI has connected. IP:127.0.0.1:32784
              Mar-15 10:09:48 AM Starting Plug-In Initializing plugin OMNI ...
              Mar-15 10:09:50 AM Starting Plug-In Plugin OMNI started successfully in 2046 milliseconds

              Will give it a first time run on Homeseer Lite running on the Pine64 2Gb computer.

              First time starting it...looking at HTop...hit CPU at around 50%...then settled down.

              Mar-15 10:34:05 AM Info Plugin mcsMQTT has connected. IP:127.0.0.1:44087
              Mar-15 10:34:05 AM Starting Plug-In Initializing plugin mcsMQTT ...
              Mar-15 10:34:05 AM mcsMQTT Version 3.0.10.1 Registered with Homeseer
              Mar-15 10:34:39 AM Starting Plug-In Plugin mcsMQTT started successfully in 34054 milliseconds

              [ATTACH]67473[/ATTACH]

              This instance is not configured yet. Turned it on and off a few times here. Running Ubuntu 16.04 64 bit on Pine64 ARM CPU with 2Gb of RAM.

              Mar-15 10:42:01 AM Plug-In Finished initializing plug-in mcsMQTT
              Mar-15 10:42:03 AM Info Plugin mcsMQTT has connected. IP:127.0.0.1:44136
              Mar-15 10:42:03 AM Starting Plug-In Initializing plugin mcsMQTT ...
              Mar-15 10:42:03 AM mcsMQTT Version 3.0.10.1 Registered with Homeseer
              Mar-15 10:42:39 AM Starting Plug-In Plugin mcsMQTT started successfully in 36397 milliseconds
              Last edited by Pete; March 15, 2018, 10:44 AM.
              - Pete

              Auto mator
              Homeseer 3 Pro - 3.0.0.548 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU 16Gb
              Homeseer Zee2 (Lite) - 3.0.0.548 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro
              HS4 Lite - Ubuntu 22.04 / Lenovo Tiny M900 / 32Gb Ram

              HS4 Pro - V4.1.18.1 - Ubuntu 22.04 / Lenova Tiny M900 / 32Gb Ram
              HSTouch on Intel tabletop tablets (Jogglers) - Asus AIO - Windows 11

              X10, UPB, Zigbee, ZWave and Wifi MQTT automation-Tasmota-Espurna. OmniPro 2, Russound zoned audio, Alexa, Cheaper RFID, W800 and Home Assistant

              Comment


                #22

                Comment


                  #23
                  Start up times are all different.

                  Next one that I looked at is:

                  Mar-15 10:49:31 AM Plug-In Finished initializing plug-in weatherXML
                  Mar-15 10:49:32 AM Info Plugin weatherXML has connected. IP:127.0.0.1:44178
                  Mar-15 10:49:32 AM Starting Plug-In Initializing plugin weatherXML ...
                  Mar-15 10:49:41 AM Starting Plug-In Plugin weatherXML started successfully in 8588 milliseconds

                  Running HS3 Lite (zee2 OS) here on the Pine64 2Gb computer and tested previously on the XiS Xi5A dual AMD with 2Gb ...both running Ubuntu 16.04 64 bit.

                  One Homeseer user has updated his SEL to running Ubuntu 16.04 64 bit...thinking the SEL you are running is doing Ubuntu 14.04 32bit.

                  The other HS user just moved HS3 to another computer and then updated his SEL to Ubuntu 16.04 or 16.10 running in 64bit mode with most current version of Mono (which also runs in 64bit mode).

                  Way long time ago tested the Intel Baytrail with 2Gb of RAM running Ubuntu 64bit (natively ran Windows 10 32 bit) and it did well.

                  Thinking the Pine64 2Gb computer was the first ARM computer to run Ubuntu in 64bit mode. Newer Rock64 4Gb computer can use built in eMMC rather than microSD.

                  Unlike Windows you do not have to do much to get Linux HS3 running in 64bit mode (well it is still a 32bit program).
                  - Pete

                  Auto mator
                  Homeseer 3 Pro - 3.0.0.548 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU 16Gb
                  Homeseer Zee2 (Lite) - 3.0.0.548 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro
                  HS4 Lite - Ubuntu 22.04 / Lenovo Tiny M900 / 32Gb Ram

                  HS4 Pro - V4.1.18.1 - Ubuntu 22.04 / Lenova Tiny M900 / 32Gb Ram
                  HSTouch on Intel tabletop tablets (Jogglers) - Asus AIO - Windows 11

                  X10, UPB, Zigbee, ZWave and Wifi MQTT automation-Tasmota-Espurna. OmniPro 2, Russound zoned audio, Alexa, Cheaper RFID, W800 and Home Assistant

                  Comment


                    #24
                    Originally posted by Pete View Post
                    thinking the SEL you are running is doing Ubuntu 14.04 32bit.
                    My SEL is Ubuntu 16.04 64 bit and Mono is 5.0.1.1 and it seems to run quite well. Tried using the latest version of Mono but it did not display asp pages properly and reverted to 5.0.1.1. The SEL hardware (Gigabyte Brix) is well designed/built and it has enough processing power, ram, and storage to handle nearly all but the most demanding HS tasks, like processing multiple CCTV feeds, but who wants HS to do that anyway when there are much better solutions like BlueIris.

                    I believe the speed issue with the mcsMQTT PI is the enumeration of all devices at PI startup and a large number of topics automatically generated and displayed in the PI config page. Both enumerating and displaying put excessive load on the system when the info isn’t really necessary for most use cases. I realize only accepted topics can be displayed, which improves the config page load time considerably, but there are considerable advantages to not enumerating all devices.
                    • It would reduce PI start times from 30-45 seconds to just a few seconds.
                    • Most people will think something is wrong with the PI config page takes 30 seconds to load.
                    • The PI config page will not be populated with unnecessary topics, making it much easier to find the one you want.
                    • Users with low power HS machines will not see a performance hit.


                    What I think might not be realized is that quite a few HS users use a Raspberry PI or mini pc that cannot spare CPU cycles to enumerate and display hundreds of devices. It’s unnecessary work being tasked to the CPU when many users don’t have gobs of CPU cycles to spare.

                    Here's a more detailed explanation:

                    I believe most people will have an external maker device (Arduino, Wemos, NodeMCU, ESP8266, ESP32, etc.) that they want to “integrate” with HomeSeer. Some will want to send or receive MQTT payloads for HS devices (non mcsMQTT plugin), for instance, send an MQTT payload when a Z-wave device has changed or control a Z-Wave device via MQTT. If they do it will be only specific HS devices, not all of them.

                    I believe what’s happening now is that at PI startup ALL HS devices (zwave, other plugin devices, virtual devices, etc.) are enumerated, searched for specific vspairs, checked if are an external plugin device, and automatically imported to this plugin. All HS devices! This puts an unnecessary load on HS when the plugin starts and when all of this info is displayed in the PI config page, especially when you only want a handful of devices to be used with MQTT.

                    My suggestion is this, if a user wants to send and receive MQTT for a non-plugin device (zwave, virtual, etc.) why not have the user select which device needs MQTT instead of enumerating all devices? A simple drop-down selection box in the PI config page to select non-plugin (zwave, virtual, etc.) devices to add to MQTT would suffice. Then this small list could be used instead of enumerating and displaying every single HS device.

                    This is just my feeling and it might not be shared by the PI author but IMO it makes sense to not waste computing resources unnecessarily.

                    Comment


                      #25
                      Apologies Matt. Here helped an SEL user a few months back that was running first-second generation of the SEL which ran Ubuntu 14.X 32 bit. I assumed that HST never upgraded the SEL based on helping the Homeseer user. Just found out yesterday that the S6 is no longer running W7E rather now it's running W10.

                      Yes mentioned earlier here that the mcsMQTT plugin resembled the mcsxAP stuff with very first time running of the plugin.

                      I understand your comments above. I do not understand MQTT enough to comment other than it resembles Michael's xAP to me as I used xAP for a very long time here. First time running xAP saw hundreds of xAP devices generated (but not Homeseer devices) which is exactly what I saw with the first time I ran mcsMQTT. No Homeseer devices were created and the HS3 GUI crawled and really didn't refresh for a very long time.

                      I am not really sure that the mcsMQTT plug in for Linux is Raspberry Pi specific as here been testing Homeseer 3 lite on ARM, AMD and Intel CPUs, Wheezy, Jessie, Stretch, Ubuntu 32 bit or Ubuntu 64 bit. Here only change really has been to update Mono to current release. Personally Linux is Linux is Linux and mono is mono is mono no matter what hardware it runs on. The Zee 2 Homeseer lite is identical to Homeseer Pro / Standard except for allowed number of plugins. Every change that Rich has done to HS3 is the same whether it's Linux or Windows.

                      The RPi's have done well and I am in learning mode relating to your comments Matt and the new mcsMQTT plugin.
                      - Pete

                      Auto mator
                      Homeseer 3 Pro - 3.0.0.548 (Linux) - Ubuntu 18.04/W7e 64 bit Intel Haswell CPU 16Gb
                      Homeseer Zee2 (Lite) - 3.0.0.548 (Linux) - Ubuntu 18.04/W7e - CherryTrail x5-Z8350 BeeLink 4Gb BT3 Pro
                      HS4 Lite - Ubuntu 22.04 / Lenovo Tiny M900 / 32Gb Ram

                      HS4 Pro - V4.1.18.1 - Ubuntu 22.04 / Lenova Tiny M900 / 32Gb Ram
                      HSTouch on Intel tabletop tablets (Jogglers) - Asus AIO - Windows 11

                      X10, UPB, Zigbee, ZWave and Wifi MQTT automation-Tasmota-Espurna. OmniPro 2, Russound zoned audio, Alexa, Cheaper RFID, W800 and Home Assistant

                      Comment


                        #26
                        I have made significant progress with cpu utilization and have extended operation to making enumeration optional just as discovery on the receive side it. More testing to be done.

                        Page load time 344 ms for 260 rows vs. the previous of about 4000 ms.
                        Startup time is 614 ms vs. over 10000 ms previously.

                        Should have is available tomorrow for others to assess.

                        Comment


                          #27
                          Sounds great! Looking forward to trying it 😀

                          Comment


                            #28
                            Originally posted by Michael McSharry View Post
                            I have made significant progress with cpu utilization and have extended operation to making enumeration optional just as discovery on the receive side it. More testing to be done.

                            Page load time 344 ms for 260 rows vs. the previous of about 4000 ms.
                            Startup time is 614 ms vs. over 10000 ms previously.

                            Should have is available tomorrow for others to assess.
                            wow nice , thumbs up!

                            Comment


                              #29
                              V3.1.0.0 has been posted to updater. The manual needs an update as the UI has changed somewhat and additional features are available.

                              At the end of the setup are two tables to do manual entry of Topic-HSDevice associations. The plugin will now create the association with the "A"ccept checkbox from the main table (no change from before) or can be done by entry of all the specific components that form the association using the manual tables.

                              Enumeration/Discover of HS devices to populate the Acceptance Table is now an option. The MQTT Topic discovery option was added a few releases ago and still works in the same way.

                              On my 600 device Odroid C1 my timing is 1.4 seconds for startup and 0.3 seconds for page rendering. The timings jump around somewhat as the CPU is not dedicated, but shared with other processes running.

                              Comment


                                #30
                                Great job Michael! You've done an amazing job. Load times for the plugin and config page are dramatically lower. Thanks for your hard work.

                                I noticed that the debug log is still written to when debugging us unchecked, not really that huge of an issue.

                                The only other thing I noticed is that I had an issue where the PI needed to be restarted to send messages. Not sure if the issue was my broker or not. Should the PI automatically reconnect to the broker if communication is interrupted?

                                Code:
                                Plugin mcsMQTT started successfully in 1020 milliseconds

                                Comment

                                Working...
                                X