www.homeseer.com    
 

Go Back   HomeSeer Message Board > 3rd Party Plug-Ins/Scripts > Plug-ins by Author > Click Here for List of Author Forums > MCS Plug-Ins and Scripts > mcsMQTT (3P)

mcsMQTT (3P) Discussion of mcsMQTT plug-in

Reply
 
Thread Tools Display Modes
  #1  
Old March 13th, 2018, 09:46 AM
mwolter mwolter is offline
Seer Deluxe
 
Join Date: Feb 2017
Location: San Diego
Posts: 261
Excessive CPU and Excessive MQTT Topics

Hello,
I started a nodeMCU project that communicates with HomeSeer via MQTT and noticed several issues with the mcsMQTT plugin. Maybe it's my setup? Is it not recommended to have mosquitto installed on the HS machine? I'm using Ubuntu Server x64 16.04.03 and Mono 5.0.1.1. System info and picures are attached below.

Here's a list of what I've found.

Excessive CPU load.
The mcsMQTT process uses the most CPU resources of any process on my machine. Even the HomeSeer Console process. After I successfully configured my project last night in Arduino, I took a look at the HS machine and the CPU was pegged at 100%, when it's typically under 10%. I rebooted the PC and the load went down but it was still over 60%. As of this morning, it's down to about 25%, but that's still very high. This brings me to the next issue.

Excessive MQTT Topics
After I rebooted last night I found excessive topics listed in the mcsMQTT plugin page. There is a topic for every HomeSeer device on my system. This includes all Z-Wave and virtual devices. Is this by design? There are 300 of them and the page takes quite a while to load.

Removing Topics Deletes the HS Device
So after finding these extra topics, I started removing them and it actually deleted the device in HomeSeer! For example, when I removed the topic for a Z-Wave light, it actually removed the HS device for the light in HS device management and I lost all control of the device. I didn't realize it was doing this until all topics were removed and when I went to device management, I had only like 10 devices when there should be 300!!! I lost all control of my HS system and had to restore a backup.

Publish Label / Number Radio Buttons do not always appear
Of all the issues, this one cost me the most time because on the original topic I was using for testing, this did not appear. I was testing turning on and off a led on the nodeMCU and it worked fine sending a 1 or 0. So I then added On and Off buttons but the led wouldn't work with On and Off. In the nodeMCU serial console I noticed it was receiving the string On and Off. This was a total pain to program for and took several hours to figure out how to convert a Byte value to Char then to String so it could be parsed by the nodeMCU. After having the issue above with the excessive devices, I notice some of the devices have a radio button to publish either the label or the number. I then noticed that if I refreshed the mcsMQTT page, the devices that had the radio buttons would change. So I did this quite a few times until my test device had them and enabled number. I then tested this and sure enough, pressing the On button sends a 1 and Off sends a 0. This would have saved me hours!!!!

Please see my attached pictures of the CPU load, excessive topics, and topics that do not have radio buttons. Is there something I did wrong? This was very frustrating and I'm super lucky to have had a working backup to revert to otherwise this would have been a disaster. I have since removed all traces of this plugin from my system but would like to use it again if the bugs can be worked out.

Current Date/Time: 3/13/2018 6:41:39 AM
HomeSeer Version: HS3 Pro Edition 3.0.0.420
Linux version: Linux hometrollerSEL 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux System Uptime: 0 Days 4 Hours 40 Minutes 49 Seconds
IP Address: 192.168.8.2
Number of Devices: 300
Number of Events: 138
Available Threads: 199
HSTouch Enabled: True
Event Threads: 1
Event Trigger Eval Queue: 0
Event Trigger Priority Eval Queue: 0
Device Exec Queue: 0
HSTouch Event Queue: 0
Email Send Queue: 0
Anti Virus Installed:

Enabled Plug-Ins
3.3.0.0: APCUPSD
3.1.1.24385: Blue-Iris
1.2.2.0: Device History
0.0.0.19: DoorBird
3.0.0.43: EasyTrigger
3.0.0.22: Ecobee
3.0.9.2: mcsMQTT
3.0.1.4: MeiHarmonyHub
0.0.0.38: Pushover 3P
30.0.0.36: RFXCOM
3.0.5.6: SDJ-Health
3.0.6542.35207: UltraWeatherWU3
3.0.1.199: Z-Wave
Attached Images
   
Reply With Quote
  #2  
Old March 13th, 2018, 01:07 PM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
No recommendation as to where mosquitto is running.

Excessive CPU load. CPU load should be a function of the number of MQTT topics being managed by broker and the rate of HS3 device change. To isolate for your situation the first step I suggest is after setting up your desired topics then disable discovery (subscribe only to accepted topic) which is a radio button setting. Further investigation can be done with timestamp debug to see where the utilization is occurring. Do you want to work with me on this investigation?

Excessive MQTT Topics. Remove the checkbox on showing non-plugin devices after you have identified the HS3 devices that you want to have publish. There is also a display filter that allows you to narrow down specific topics and payloads as well as a checkbox to display only Accepted topics. After I have done my "topic editing" I will use the Display only Accepted checkbox and then later when I want to change something I will use the filter and uncheck this checkbox.

Removing Topics Deletes the HS Device. The intention is that it remove the devices created by mcsMQTT plugin. If it is also removing other plugin devices then I need to fix it.

Publish Label / Number Radio Buttons do not always appear. 0/1, on/off, open/close are all treated as two-state devices. The labels setup as value/graphic/status pairs are based upon the payload at the time the topic is Accepted. These provide the option to publish either the 0/1 value or the vgp value. If the payload is different then publishing the label option is not provided and either DeviceValue or DeviceString will be published for numeric and non-numeric topic payloads. I tried to describe this behavior in the manual. The intention was to make the MQTT/HS3 bridge as natural as possible with the minimum amount of effort by the user.
Reply With Quote
  #3  
Old March 13th, 2018, 01:22 PM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
I looked at the source code when an Accepted devices has the Accepted checkbox removed. For the devices that are considered SEND devices it removes the device from the list of HS3 devices that are published, but it does not delete the device. For the devices that are considered RECEIVE devices it will delete the device. The RECEIVE devices should only be the ones that were created by mcsMQTT as a result of Accepting a topic received from the broker.

There is also a Remove checkbox that only affects the displayed topics. In essence it is a topic by topic filter while the pulldowns toward the top are like wildcards to reduce the number of topics displayed. The Remove checkbox should also not delete any HS3 devices.

Can you provide more guidance on what you did to cause your zwave device to be deleted?
Reply With Quote
  #4  
Old March 13th, 2018, 04:30 PM
mwolter mwolter is offline
Seer Deluxe
 
Join Date: Feb 2017
Location: San Diego
Posts: 261
Hi Michael, thanks for the response. I see a lot of potential with this plugin and would like to help resolve some of these issues if you're interested. Your instruction manual is great but a lot of people would probably benefit if the plugin was a little more intuitive. Please see my recommendations below in blue.

Auto Generated Topics
All of the topics listed in the attached screenshots and 99% of the total topics were created by the plugin. Only a small number of the auto-generated topics corresponding to HS devices did not have the accept box checked. I would say about 10% didn't have the accept box automatically checked. Instead of having it automatically make a topic for every HS device, could a drop down be used to select the device and a topic is then generated, instead of having all devices auto-generated? This would help reduce confusion, clutter and CPU load.

Deleted Z-Wave Devices
So for the Z-Wave devices that were deleted, all that I did was uncheck the A box and check the R box, click the reload button and it removed the Z-Wave HS devices. Is there a way to have it delete the HS device ONLY if it was created by mcsMQTT?

Label / Number Radios
In my case, the MQTT device sent a "Hello World" payload to the topic on startup. So this is probably why the radios never showed. Is it possible to have the Label / Number radios always show? Would help reduce confusion.

Buttons Above Topics
What are the buttons directly above the topics for? For instance hat do the A and R buttons do? I assumed they were for sorting but couldn't find any info on them. Is it possible to have an infobox appear when hovering over the buttons?

Initial Setup Observation
This is a little difficult to explain and probably more difficult to follow but I'll try to explain what I saw and did while setting it up. Hopefully this helps.

After installing the plugin, clicking the plugin setup page was already sluggish. It took probably 10 seconds to load. All other pages on HS load within one to two seconds. When it loaded there were no topics listed. Only after connecting to the broker and having an MQTT device publish a topic was a topic listed in the center portion of the plugin. The only topics displayed were created by received topics from the broker, there were no HS devices listed. I selected the A box for the new topic, clicked reload and it created an HS device. Keep in mind the payload was "Hello World" so it didn't show the radios.

I then tested the sending of a payload by entering 1 in the text box for the HS device and clicking submit. The payload was received by the nodeMCU and it turned on and off the LED. I then created On and Off buttons with On = 1 and Off = 0 and noticed the device did not operate. I then went through the process of changing the code to have the device recognize text strings, which wasn't easy.

After the buttons were working, I then noticed the CPU was pegged on the HS machine. I rebooted it and the load went down but was still high. I then went to the mcsMQTT setup page and it took about a minute to load. Once loaded all HS devices were listed as topics with many of them (probably ~300) having the A box checked. I then unchecked the A and checked the R on all of them (it took forever) then went to the main HS screen and all but about 20 devices were deleted.

At this point, I restored a backup and rebooted which brought back all HS devices but the plugin was still enabled and it created all of the topics again, with many of the A boxes selected. I then disabled and deleted the plugin and performed another restore. Now my system is back to as it was before installing mcsMQTT and CPU load is under 10%.
Reply With Quote
  #5  
Old March 13th, 2018, 05:23 PM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
I added some millisecond-level timing around HS3 events and MQTT messaging. The data below is running on Odroid C1 which is the same class as a RPi3. It is not exact for timing, but gives an idea. In my case my CPU utilization is in the 0 to 5% range when viewing with htop on DietPi/Jessie.

I uploaded 3.0.9.3 which contains the timing output to \data\mcsMQTT_debug.txt when Debug is enabled.

Here is a ballpark for the throughput demands for certain tasks. It seems the recursive JSON loads is the biggest hitter so if one has much of this data being published and not being used by HS3 then disabling discovery may have some cpu benefits.

HS3 event change to non-accepted not published (160-149 = 11 milliseconds)
HS3 event change to value published (910-881 = 29 milliseconds)
MQTT topic received for non-acccepted topic (223-193 = 30 milliseconds)
MQTT topic received to HS3 value updated (398-325 = 73 milliseconds)
MQTT JSON received with 9 payload items (325-059 = 266 milliseconds)
Reply With Quote
  #6  
Old March 13th, 2018, 06:43 PM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
Quote:
Auto Generated Topics
All of the topics listed in the attached screenshots and 99% of the total topics were created by the plugin. Only a small number of the auto-generated topics corresponding to HS devices did not have the accept box checked. I would say about 10% didn't have the accept box automatically checked. Instead of having it automatically make a topic for every HS device, could a drop down be used to select the device and a topic is then generated, instead of having all devices auto-generated? This would help reduce confusion, clutter and CPU load.
Something is wrong if the Accept checkbox is being automatically selected. There is intentional redundancy in the retained setup information. This was done as an integrity check and to allow a user to take his mcsMQTT database and have the mcsMQTT environment moved to another HS3 instance.

During plugin startup it enumerates all HS3 devices. It assures consistency between the database and the device's PED. It will create HS3 devices for Accepted ones in the database that were not found during enumeration. The only devices that should be in the database are the ones owned by mcsMQTT and those non-plugin devices that have been Accepted.

If somehow a non-plugin devices finds its way into the mcsMQTT database then it will become accepted during initialization. I don't yet understand how this could happen or if this is the mechanism by which they were automatically accepted in your case. I will have to polk around to try to recreated the scenario.

Quote:
Deleted Z-Wave Devices
So for the Z-Wave devices that were deleted, all that I did was uncheck the A box and check the R box, click the reload button and it removed the Z-Wave HS devices. Is there a way to have it delete the HS device ONLY if it was created by mcsMQTT?
This is a logical extension of a device thought to be a RECEIVE (mcsMQTT) device and then properly responding to a user action to unAccept it. In the back of my head an explicit check on the Interface property of the device would prevent this situation, but would rather address the root cause than patch the symptom.


Quote:
Label / Number Radios
In my case, the MQTT device sent a "Hello World" payload to the topic on startup. So this is probably why the radios never showed. Is it possible to have the Label / Number radios always show? Would help reduce confusion.
The labels are associated with the CAPI control type property of the device being "HomeSeerAPI.Enums.CAPIControlType.Button". If it is not a button then there is no label to publish so the option to publish label vs. value does not exist. This property is set when the device is created and it is based upon the payload containing open, closed, on, or off.

I am not totally clear on what you would like to have seen to avoid your original issue that caused you additional work. There is logic in the HTML on mcsMQTT setup with <div> tags to dynamically build cells based upon user selections. For example, when Accept is selected then the additional options of send topic and label/number are shown. I have not have had success on making it work and was not important enough for the time to investigate.

Quote:
Buttons Above Topics
What are the buttons directly above the topics for? For instance hat do the A and R buttons do? I assumed they were for sorting but couldn't find any info on them. Is it possible to have an infobox appear when hovering over the buttons?
They are intended to be sort buttons as you suspected. I will research to see what needs to be done to add tool tips.

Quote:
Initial Setup Observation
This is a little difficult to explain and probably more difficult to follow but I'll try to explain what I saw and did while setting it up. Hopefully this helps.
After installing the plugin, clicking the plugin setup page was already sluggish. It took probably 10 seconds to load.
In my case the setup page with only show accepted option loads in about the same time as the HS3 Device Management page.... a few seconds. A full page is about 10 seconds and likely is a function of the number of devices. I can do some timing debug to better understand the time. From the early HS days it was known that VB string concatenation is very slow so StringBuilder is used for that function. I know that when accessing the HS API I always call in the current hs object which can be slow, but the tradeoff is assuring the data being referenced is always current. I consider this most important during the setup selections.
Reply With Quote
  #7  
Old March 13th, 2018, 07:07 PM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
In the \data folder each version of mcsMQTT.db is backed up. Do you still have them so I can observe some of history that might help explain why the auto acceptance was happening?
Reply With Quote
  #8  
Old March 13th, 2018, 09:10 PM
mwolter mwolter is offline
Seer Deluxe
 
Join Date: Feb 2017
Location: San Diego
Posts: 261
Yes, what's the best way to get it to you? Does it contain sensitive info?

I fired up a virtual machine with HS and loaded mcsMQTT, rebooted and it created accepted topics for each HS device. Below is a screenshot.

Sure would be nice to have some way to selectively create topics for HS devices.
Attached Images
 
Reply With Quote
  #9  
Old March 13th, 2018, 10:57 PM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
Nothing sensitive other than your mqtt payloads. The debug file would also be useful. Posting zip file here should work. Odd that nobody else has seen this behavior. Using the latest from the updated would be best since the debug output changed to support timing analysis.

Your screenshot does show the plugin is treating these as received topics/devices. If they are in the database then it supports my theory, but why/how they are out there without being accepted is still a mystery.

Since HS is sourcing the topics why does it matter what the topic is? It should not be hard to provide user ability to edit the default. The downside is that this info cannot be put in the device’s PED since the device is owned by another plugin.
Reply With Quote
  #10  
Old March 13th, 2018, 11:18 PM
mwolter mwolter is offline
Seer Deluxe
 
Join Date: Feb 2017
Location: San Diego
Posts: 261
Not to change the topic, interested in not having so many unaccepted topics. Seems logical to only make the topics that will actually be used and reduce the clutter. Since they're not automatically created, this would also prevent them from being automatically accepted and make new topics a whole lot easier to find. I think it would also be much more intuitive for a new user.

Auto or not, either way is fine. Would prefer to not have them automatically created, that's all.

So checked my live HS system and all databases and logs were deleted. I have the databases from my virtual system and attached them. Let me know if you need them from a live system and I'll see about installing the plugin on my main system again.
Attached Files
File Type: zip Archive.zip (14.9 KB, 4 views)
Reply With Quote
  #11  
Old March 14th, 2018, 12:29 AM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
The intended design is to act as a firewall where rules allow penetration. If you do not want discovery and only manually enter the subscription topics then set the radio button to disable discovery. You can then enter the desired subscriptions one by one. The downside to this is that there will be no payload at time of Accept so it will show up as a status only device. This may be something I can let be edited or at this time you can get the desired effect by Accepting the manually entered topic, allow the broker to forward when it is published and then UnAccept followed by Accept to create a new device with payload available and then control options presented.

My personal preference is to see what is out there and use the pulldown filters to focus on subjects of interest at any given time. It helps with debugging and understanding system behavior when topics are close, but not exact. It also means I do not know what a node publishes apriori and may select one of multiple equivalent topics that best suit my need.

The two databases show no Accepted devices, but your screenshot showed them. The second clue is that the Device Reference should always be positive for existing HS3 devices. In one of the two almost all Ref values are -1.

Is your virtual machine also bogged down with mcsMQTT. Have you used the debug to collect some data to understand timing?
Reply With Quote
  #12  
Old March 14th, 2018, 12:50 AM
mwolter mwolter is offline
Seer Deluxe
 
Join Date: Feb 2017
Location: San Diego
Posts: 261
Enabled debugging and rebooted several times. On all but one reboot new topics were shown and auto accepted. See screenshots and logs.
Attached Images
  
Attached Files
File Type: zip Archive 2.zip (45.3 KB, 3 views)
Reply With Quote
  #13  
Old March 14th, 2018, 01:00 AM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
I believe I ran down the cause of the auto accept. It is corrected in 3.9.0.4 from updater. I will look at you debug to double check and look at some of the timing.

p.s. the debug output is /data/mcsMQTT_Debug.txt
Reply With Quote
  #14  
Old March 14th, 2018, 01:45 AM
mwolter mwolter is offline
Seer Deluxe
 
Join Date: Feb 2017
Location: San Diego
Posts: 261
Great, I’ll give it a try. Forgot to mention that there was high cpu usage on the virtual machine as well and notice it went down considerably after a few reboots.
Reply With Quote
  #15  
Old March 14th, 2018, 02:49 AM
mwolter mwolter is offline
Seer Deluxe
 
Join Date: Feb 2017
Location: San Diego
Posts: 261
Tested 3.9.0.4 on the VM and it appeared to have resolved the auto accept and the CPU load was low. I then installed it on my live system and it didn't populate the HS device topics until a reboot.

Once it populated them the PI page load time went from about 3 seconds to about 30 seconds. When Show Only Accepted is checked, the page load time is about seven seconds. Attached the debug from the live system in case you want to look into the timing.

It appears all of the HS devices are listed but there several still have a ref of -1. Are the topics with ref -1 an issue?

Congrats! The auto accept has been resolved and the CPU load appears to be lower. Thanks for fixing this so quickly!
Attached Files
File Type: zip mcsMQTT Debug-3.txt.zip (48.7 KB, 4 views)
Reply With Quote
  #16  
Old March 14th, 2018, 03:22 AM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
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.
Reply With Quote
  #17  
Old March 14th, 2018, 09:01 PM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
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
Reply With Quote
  #18  
Old March 15th, 2018, 02:51 AM
mwolter mwolter is offline
Seer Deluxe
 
Join Date: Feb 2017
Location: San Diego
Posts: 261
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 Images
 
Reply With Quote
  #19  
Old March 15th, 2018, 04:01 AM
Michael McSharry's Avatar
Michael McSharry Michael McSharry is offline
OverSeer
 
Join Date: Jul 2001
Location: North Bend, WA, USA
Posts: 13,710
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
Reply With Quote
  #20  
Old March 15th, 2018, 10:31 AM
mwolter mwolter is offline
Seer Deluxe
 
Join Date: Feb 2017
Location: San Diego
Posts: 261
Thanks Michael, would be great if you could look into the load time. Seems a simple fix would be to not have the plugin search for or have visibility into all devices, just the ones a user selects. I know this isn’t what you want to do but it would solve the slow startup and slow PI page load times.

This is a feature of the new HS beta. .423 has been extremely stable for me, recommend giving it a try. It has quite a few new and useful features some are behind the scenes, but HS now supports https on the web GUI and a few other things.
Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Excessive Log Entries tome10 HS3 / HS3PRO Discussion 2 November 4th, 2017 06:06 PM
Excessive CPU usage pete@malibubeach.com VWS 13 April 10th, 2017 11:38 AM
Excessive logging Pnord HS3 / HS3PRO Discussion 2 November 30th, 2016 08:31 AM
Excessive Logging tome10 HS3 / HS3PRO Discussion 7 October 12th, 2016 02:54 PM
Isssues with excessive CPU use donstephens Personal Computers 38 September 3rd, 2016 01:28 PM


All times are GMT -4. The time now is 06:34 PM.


Copyright HomeSeer Technologies, LLC