I'm wondering if anybody else is having some issues with HS3 crashing, after running mcsMQTT and a large number of messages are sent in.
I have an energy monitor that sends ~50 messages at a time every 6 seconds, plus a few other updates from other sensors.
I had narrowed it down the crashing issue to mcsMQTT and the inflow of messages because when I disable my MQTT server; everything works fine.
The crashing involves HS3 crashing completely with some other plugins in Windows. It needs a complete restart of the HS3 application (but not the computer/OS). The crashing is slightly random, but happens most of the time (more than 3/4 of the time). The crashing happens with much higher certainty (90%+) when discover new topics (subscription to #) is selected. In either case, usually if it had happened once, then it is quite likely to happen again if I repeat the action of entering the mcsMQTT config after a restart of HS3; the best way to avoid this is just to leave it alone for a while, and give it a shot or disable the MQTT server first.
HS3 is running on 64bit Windows 8.1 Pro, with 8GB RAM on a Intel NUC with Core i5 processor. CPU utilization is usually quite low (Avg 10-%, 3-4% typical with 30-40% bursts every few seconds). Disk is relatively good too, SSD with no significant transaction queue. One thing to note is that the MQTT server runs on the same computer in a virtual machine within VMWare Workstation, along with the client software that polls the energy monitor. So each poll of the energy monitor, sends a bunch of updates to a database, plus all the updates to MQTT which is then pulled into HS3 vs mcsMQTT. There is another database that polls MQTT for the same data and stores everything; in other words a small chain reaction occurs from each update. There are about 530 devices within the HS3 list, includes virtual, some are status, MQTT, plugins, parent devices, etc.
In mcsMQTT my queue is set to 30, and I have disabled discover new topics. If I don't touch the settings page, it will run fine for a long time. However, HS3 still feels a bit more twitchy than usual. If I do something like an Zwave Optimize or Full Optimize for a device, it may crash (maybe about 20% of the time).
It feels like there is a timing/delay issue at hand here; that something is not happening when it's expected to (because of a delay from a flood of messages), and the computer just gives up.
Any help or experience to share would be appreciated.
Some stats attached below.
Message Receive Queue
Current Queue Depth
0
Max Queue Depth
34
Average Receive Processing Milliseconds
39
Average Receive Milliseconds
221
I have an energy monitor that sends ~50 messages at a time every 6 seconds, plus a few other updates from other sensors.
I had narrowed it down the crashing issue to mcsMQTT and the inflow of messages because when I disable my MQTT server; everything works fine.
The crashing involves HS3 crashing completely with some other plugins in Windows. It needs a complete restart of the HS3 application (but not the computer/OS). The crashing is slightly random, but happens most of the time (more than 3/4 of the time). The crashing happens with much higher certainty (90%+) when discover new topics (subscription to #) is selected. In either case, usually if it had happened once, then it is quite likely to happen again if I repeat the action of entering the mcsMQTT config after a restart of HS3; the best way to avoid this is just to leave it alone for a while, and give it a shot or disable the MQTT server first.
HS3 is running on 64bit Windows 8.1 Pro, with 8GB RAM on a Intel NUC with Core i5 processor. CPU utilization is usually quite low (Avg 10-%, 3-4% typical with 30-40% bursts every few seconds). Disk is relatively good too, SSD with no significant transaction queue. One thing to note is that the MQTT server runs on the same computer in a virtual machine within VMWare Workstation, along with the client software that polls the energy monitor. So each poll of the energy monitor, sends a bunch of updates to a database, plus all the updates to MQTT which is then pulled into HS3 vs mcsMQTT. There is another database that polls MQTT for the same data and stores everything; in other words a small chain reaction occurs from each update. There are about 530 devices within the HS3 list, includes virtual, some are status, MQTT, plugins, parent devices, etc.
In mcsMQTT my queue is set to 30, and I have disabled discover new topics. If I don't touch the settings page, it will run fine for a long time. However, HS3 still feels a bit more twitchy than usual. If I do something like an Zwave Optimize or Full Optimize for a device, it may crash (maybe about 20% of the time).
It feels like there is a timing/delay issue at hand here; that something is not happening when it's expected to (because of a delay from a flood of messages), and the computer just gives up.
Any help or experience to share would be appreciated.
Some stats attached below.
Message Receive Queue
Current Queue Depth
0
Max Queue Depth
34
Average Receive Processing Milliseconds
39
Average Receive Milliseconds
221
Comment