Got to love htop. I learned a lot more about hs3s structure than I did just using ps to look at tasks when I put it in a mode that allows you to see the threads.
Announcement
Collapse
No announcement yet.
New Error on .460
Collapse
X
-
HomeSeer Version: HS3 Standard Edition 3.0.0.548
Linux version: Linux auto 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Number of Devices: 484 | Number of Events: 776
Enabled Plug-Ins: 3.0.0.13: AirplaySpeak | 2.0.61.0: BLBackup
3.0.0.70: EasyTrigger | 1.3.7006.42100: LiftMaster MyQ
4.2.3.0: mcsMQTT | 3.0.0.53: PHLocation2 | 0.0.0.47: Pushover 3P
3.0.0.16: RaspberryIO | 3.0.1.262: Z-Wave
Z-Net version: 1.0.23 for Inclusion Nodes
SmartStick+: 6.04 (ZDK 6.81.3) on Server
-
64 is String change
2048 is value set
16384 is run script special (plugin is notified if a string changes and a script was registered to run on the change)
The next version of HS3 has descriptive names for the event types.
There is no reason for this queue to fill and I have yet to find out which plugin is causing it. HS simply sends an event to whoever has registered for the event. It would be a plugin registering for this. The plugin should return immediately from this call but it appears some are taking a long time to process. The end result is that the event queue starts to fill.
I would disable plugins until this stops happening to see which plugins is causing it. I would happy to contact the plugin author.
In your case the 16384 is a rare event as that is a script that runs when a string changes. I would see which plugin is registering for that event and disable that one first.
The 500 limit is just a number to keep memory from growing out of control.
Originally posted by sparkman View Postrjh Hi Rich, can you provide clarity as to what the different Types mean in these warning messages? I'm trying to track down which of my plugins could be causing these issues as events and ImperiHome updates don't always seem to happen when they should.
The last three warnings I received are Type 64, 1024 and 16384, but I also see 32, and 2048. 16384 seems to be the most common one on my system. Can any more debugging info be provided to see what is in the queue? Having an adjustable queue size would be great as well. Is there a reason for the hard limit of 500?
Thanks
AlJan-04 11:46:47 AM Warning Dropping event callbacks due to full queue (Type: 64) (500 entries), system may be too busy, plugins and HSTouch may not receive all device updates Jan-04 9:22:39 AM Warning Dropping event callbacks due to full queue (Type: 1024) (500 entries), system may be too busy, plugins and HSTouch may not receive all device updates Jan-04 8:46:12 AM Warning Dropping event callbacks due to full queue (Type: 16384) (500 entries), system may be too busy, plugins and HSTouch may not receive all device updates
- Likes 1
Comment
-
rjh. Thanks Rich. On my system the main culprit appears to be the BLLED plugin. I've been communicating with Blade and he's released a new version which has improved the situation, but not eliminated it. With BLLED disabled, I do still see a few Type 32 messages at startup, but none otherwise. None of the other people that have posted which plugins they are running list BLLED as one of their plugins, so there are other plugins causing issues as well.HS 4.2.8.0: 2134 Devices 1252 Events
Z-Wave 3.0.10.0: 133 Nodes on one Z-Net
Comment
-
Guest
-
I have been disabling plugins but have not been able to pinpoint a culprit - perhaps it is more than one? My biggest issue is that I cannot consistently reproduce the situation - it doesn't happen at start-up (most of the time) as it does with others. Is there no way to have homeseer point a finger at a misbehaving plugin as an option in the log?
Comment
-
Guest
Originally posted by simonmason View PostI have been disabling plugins but have not been able to pinpoint a culprit - perhaps it is more than one? My biggest issue is that I cannot consistently reproduce the situation - it doesn't happen at start-up (most of the time) as it does with others. Is there no way to have homeseer point a finger at a misbehaving plugin as an option in the log?
same here. rjh
Comment
-
Originally posted by simonmason View PostI have been disabling plugins but have not been able to pinpoint a culprit - perhaps it is more than one? My biggest issue is that I cannot consistently reproduce the situation - it doesn't happen at start-up (most of the time) as it does with others. Is there no way to have homeseer point a finger at a misbehaving plugin as an option in the log?
So that said, one bad plugin can certainly cause this, but so can 8 kinda medium speed ones, that together feel like on bad one. Thats why this is difficult to track down, you an disable one plugin and the problem won't go away unless its a really bad one. CPU usage of the plugins (overall CPU time vs HSconsoles time) is a way to start, the ultimate answer is Rich keeping statistics on each plugin and dumping those when this error occurs.
Comment
-
To complicate things, it is not just which plugins are slow to handle events, but plugins that flood the system with device changes. Media plugins like Sonos continually update multiple devices for each media device as music is played, ie track position. Every plugin registered for events must handle all of these events. Not saying they shouldn't, just that it is the combination of event generators and event handlers.
If you run tenScripting with events enabled, you can dynamically watch all of the events being generated.
tenholde
Comment
-
Is there any way the maximum queue level could be adjusted for those of us who can handle the additional impact on memory? Mine normally runs at 1.3GB, so memory is not an issue here.
I have disabled almost every plugin, but still get between 40-50 warnings each time I start HS3.HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon
- Likes 1
Comment
-
Originally posted by rprade View PostIs there any way the maximum queue level could be adjusted for those of us who can handle the additional impact on memory? Mine normally runs at 1.3GB, so memory is not an issue here.
I have disabled almost every plugin, but still get between 40-50 warnings each time I start HS3.Billy
Comment
-
Guest
Originally posted by rprade View PostIs there any way the maximum queue level could be adjusted for those of us who can handle the additional impact on memory? Mine normally runs at 1.3GB, so memory is not an issue here.
I have disabled almost every plugin, but still get between 40-50 warnings each time I start HS3.
your suggestion would be the best. But that means a user changeable setting , and the user needs to know what he is doing?
Comment
-
You can always have a minimum value to which you cannot set the queue lower. But I agree why limit the upper end within reason unless there is a performance hit if it get too high.HomeSeer Version: HS3 Standard Edition 3.0.0.548
Linux version: Linux auto 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Number of Devices: 484 | Number of Events: 776
Enabled Plug-Ins: 3.0.0.13: AirplaySpeak | 2.0.61.0: BLBackup
3.0.0.70: EasyTrigger | 1.3.7006.42100: LiftMaster MyQ
4.2.3.0: mcsMQTT | 3.0.0.53: PHLocation2 | 0.0.0.47: Pushover 3P
3.0.0.16: RaspberryIO | 3.0.1.262: Z-Wave
Z-Net version: 1.0.23 for Inclusion Nodes
SmartStick+: 6.04 (ZDK 6.81.3) on Server
- Likes 1
Comment
-
Originally posted by MattLau View Post
This is what i implicitly asked for in my #59 post.
your suggestion would be the best. But that means a user changeable setting , and the user needs to know what he is doing?
HS4 Pro, 4.2.19.0 Windows 10 pro, Supermicro LP Xeon
- Likes 1
Comment
-
32 is a config change. I would not think that should happen often as it is normally a change in setup.
Originally posted by MattLau View Posttype 32 does happen a lot, what does it mean?
- Likes 1
Comment
Comment