Large number of dropped MQTT messages during device list scan.

[medrapal]

Problem/Motivation

(Why the issue was filed)

EQMX shows a large number of dropped MQTT messages during a device list scan. I have about 70 devices and EQMX reports about 525 dropped MQTT messages during the scan. Device list scan works and I see current status for all devices in the list.

Expected behavior

Maybe zero? Or at least very few.

(What you expected to happen)

Actual behavior

(What actually happened)

Steps to reproduce

(How can someone else make/see it happen)

Proposed changes

To be fair, this is a low-priority issue as you can't seen any issues unless you happen to have EQMX installed (thank you for the great HA addon).

(If you have a proposed change, workaround or fix,
describe the rationale behind it)

[github-actions]

There hasn't been any activity on this issue recently, so we clean up some of the older and inactive issues.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by leaving a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thanks!

[inverse]

@medrapal If you upgrade to the latest version does your issue persist? I've added a pool size to the requests that the service issues so that it shouldn't spam the network with more than 50 requests by default.

This option is configurable in the config page too, as well as other options such as connect and read timeouts.

[medrapal]

I have updated Tasmoadmin to v0.31.0 and EMQX to v0.7.2 and still see the same issue. I do see the timeout adjustments in the Settings page and set the timeouts a little higher with no change in the symptoms. Here's a screenshot of the Dropped Messages graph in EMQX: [image: image.png] As soon as I start TasmotsAdmin UI, I see the spikes in dropped messages. When I close the TasmotAdmin UI, they drop back down to zero.

…

On Mon, Nov 18, 2024 at 4:14 AM Malachi Soord ***@***.***> wrote: @medrapal <https://github.com/medrapal> If you upgrade to the latest version does your issue persist? I've added a pool size to the requests that the service issues so that it shouldn't spam the network with more than 50 requests by default. This option is configurable in the config page too, as well as other options such as connect and read timeouts. — Reply to this email directly, view it on GitHub <#435 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC7AW3WJU3MLA2DSDFEXNQ32BHDZ5AVCNFSM6AAAAABQGOZTVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBSG4ZTOMRVGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Myron Drapal ***@***.***

[inverse]

Not an expert but do other activities on the network cause such packet loss? Or is it purely this scan?

[medrapal]

This only happens when Tasmota UI is active - the periodic status scan does this. When Tasmota UI is not active, the normal dropped packets are 1-2 every few minutes (not in the 500 range).

…

On Mon, Nov 18, 2024 at 2:54 PM Malachi Soord ***@***.***> wrote: Not an expert but do other activities on the network cause such packet loss? Or is it purely this scan? — Reply to this email directly, view it on GitHub <#435 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC7AW3VJCNIC6BMYYLRLKS32BJO3HAVCNFSM6AAAAABQGOZTVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBUGIYTCMJSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Myron Drapal ***@***.***

[inverse]

What happens when you set Request concurrency to something low?

[inverse]

Ahh I think I know what it could be. The JS on the frontend still issues a request for each device, and doesnt respect the concurrency that was applied to the backend. Check the network tab of your browser on that page.

Ill see what I can do, meanwhile try changing the Refreshtime to something higher.