All CoolMasterNet entities are repeatedly becoming unavailable/available

[ekutner]

The problem

Every few minutes (sometimes 2 minutes, sometime 30 or more) all the CoolMaster entities become "unavailable" and then exactly 1 minutes later they become available again and get their correct state. I believe that this only started happening in the last few months but I can't say exactly when.
My CoolMaster device and Home Assistant are connected to my network with cables, not wifi. I tried restarting the CoolMaster device and obviously HA was restarted many times during this period, but it didn't help.

What version of Home Assistant Core has the issue?

core-2025.5.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

CoolMasterNet

Link to integration documentation on our website

https://www.home-assistant.io/integrations/coolmaster/

Diagnostics information

No response

Example YAML snippet

Anything in the logs that might be useful for us?

The only relevant entries in the log look like these:

2025-06-26 23:30:39.658 ERROR (MainThread) [homeassistant.components.coolmaster.coordinator] Error fetching coolmaster data: 
2025-06-26 23:30:39.660 DEBUG (MainThread) [homeassistant.components.coolmaster.coordinator] Finished fetching coolmaster data in 1.020 seconds (success: False)
2025-06-26 23:31:39.689 INFO (MainThread) [homeassistant.components.coolmaster.coordinator] Fetching coolmaster data recovered
2025-06-26 23:31:39.690 DEBUG (MainThread) [homeassistant.components.coolmaster.coordinator] Finished fetching coolmaster data in 0.052 seconds (success: True)

There is no additional data after the "error fetching" line

Additional information

No response

[home-assistant]

Hey there @OnFreund, mind taking a look at this issue as it has been labeled with an integration (coolmaster) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of coolmaster can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign coolmaster Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

coolmaster documentation
coolmaster source
_{^{(message by IssueLinks)}}

[OnFreund]

Can you ping your coolmaster while it's unavailable? Connect over Telnet?

[ekutner]

It's nearly impossible to catch it at the exact time when the integration is getting the error but telnet worked fine and "stat2" command returned immediately when I tried just a few seconds after the entities became "unavailable". I also had ping -t running in the background and it didn't miss any pings. The only thing possibly unusual is that two non-consecutive ping responses, around the time of the error, took 13/14ms compared to the usual 1/2ms. I see those 13/14ms responses once in a while in the history, so maybe the device is doing something in the background and responds slower but it still responds. My guess is that a retry in case of a failure will probably solve the issue.

[OnFreund]

The delay from the HA side is over a second, not a few ms.
Is the ping running from HA or from a different computer?

[ekutner]

The previous test was indeed from a different computer on the same network but now I tried from the HA computer itself. The picture is a bit different with some pings taking 800-950ms but with 0 packet loss. That said, this behavior is happening all the time, every 10-12 seconds there are a couple of slow responses. Maybe the connection issue is happening when the integration tries to connect during one of these periods, but I have no way of verifying this. I also don't know why the HA box is having these slow-downs but it doesn't seem unique to pinging the Risco system, I tried pinging other network devices from the HA box and got similar results.
Here's a excerpt the includes a time when the connection failed with some pings before and after:

64 bytes from 192.168.11.3: seq=588 ttl=254 time=1.899 ms
64 bytes from 192.168.11.3: seq=589 ttl=254 time=470.519 ms
64 bytes from 192.168.11.3: seq=590 ttl=254 time=937.423 ms
64 bytes from 192.168.11.3: seq=591 ttl=254 time=1.835 ms
64 bytes from 192.168.11.3: seq=592 ttl=254 time=1.587 ms
64 bytes from 192.168.11.3: seq=593 ttl=254 time=1.631 ms
64 bytes from 192.168.11.3: seq=594 ttl=254 time=1.841 ms
64 bytes from 192.168.11.3: seq=595 ttl=254 time=1.774 ms
64 bytes from 192.168.11.3: seq=596 ttl=254 time=1.627 ms
64 bytes from 192.168.11.3: seq=597 ttl=254 time=1.913 ms
64 bytes from 192.168.11.3: seq=598 ttl=254 time=1.866 ms
64 bytes from 192.168.11.3: seq=599 ttl=254 time=2.522 ms
64 bytes from 192.168.11.3: seq=600 ttl=254 time=463.582 ms
64 bytes from 192.168.11.3: seq=601 ttl=254 time=927.839 ms
64 bytes from 192.168.11.3: seq=602 ttl=254 time=1.517 ms
64 bytes from 192.168.11.3: seq=603 ttl=254 time=1.780 ms
64 bytes from 192.168.11.3: seq=604 ttl=254 time=1.782 ms
64 bytes from 192.168.11.3: seq=605 ttl=254 time=1.771 ms
64 bytes from 192.168.11.3: seq=606 ttl=254 time=1.712 ms
64 bytes from 192.168.11.3: seq=607 ttl=254 time=1.550 ms
64 bytes from 192.168.11.3: seq=608 ttl=254 time=1.778 ms
64 bytes from 192.168.11.3: seq=609 ttl=254 time=1.721 ms
64 bytes from 192.168.11.3: seq=610 ttl=254 time=1.691 ms
64 bytes from 192.168.11.3: seq=611 ttl=254 time=455.320 ms
64 bytes from 192.168.11.3: seq=612 ttl=254 time=916.734 ms
64 bytes from 192.168.11.3: seq=613 ttl=254 time=1.679 ms
64 bytes from 192.168.11.3: seq=614 ttl=254 time=1.878 ms
64 bytes from 192.168.11.3: seq=615 ttl=254 time=1.457 ms
64 bytes from 192.168.11.3: seq=616 ttl=254 time=1.586 ms
64 bytes from 192.168.11.3: seq=617 ttl=254 time=1.932 ms
64 bytes from 192.168.11.3: seq=618 ttl=254 time=1.777 ms
64 bytes from 192.168.11.3: seq=619 ttl=254 time=1.858 ms
64 bytes from 192.168.11.3: seq=620 ttl=254 time=1.610 ms
64 bytes from 192.168.11.3: seq=621 ttl=254 time=1.717 ms
64 bytes from 192.168.11.3: seq=622 ttl=254 time=449.031 ms
64 bytes from 192.168.11.3: seq=623 ttl=254 time=910.691 ms
64 bytes from 192.168.11.3: seq=624 ttl=254 time=1.726 ms
64 bytes from 192.168.11.3: seq=625 ttl=254 time=1.929 ms
64 bytes from 192.168.11.3: seq=626 ttl=254 time=1.793 ms
64 bytes from 192.168.11.3: seq=627 ttl=254 time=1.750 ms
64 bytes from 192.168.11.3: seq=628 ttl=254 time=1.683 ms
64 bytes from 192.168.11.3: seq=629 ttl=254 time=2.253 ms
64 bytes from 192.168.11.3: seq=630 ttl=254 time=1.685 ms
64 bytes from 192.168.11.3: seq=631 ttl=254 time=1.540 ms
64 bytes from 192.168.11.3: seq=632 ttl=254 time=1.714 ms
64 bytes from 192.168.11.3: seq=633 ttl=254 time=445.452 ms
64 bytes from 192.168.11.3: seq=634 ttl=254 time=908.223 ms
64 bytes from 192.168.11.3: seq=635 ttl=254 time=1.975 ms
64 bytes from 192.168.11.3: seq=636 ttl=254 time=1.483 ms
64 bytes from 192.168.11.3: seq=637 ttl=254 time=1.613 ms
64 bytes from 192.168.11.3: seq=638 ttl=254 time=1.988 ms
64 bytes from 192.168.11.3: seq=639 ttl=254 time=1.957 ms
64 bytes from 192.168.11.3: seq=640 ttl=254 time=2.069 ms
64 bytes from 192.168.11.3: seq=641 ttl=254 time=1.814 ms
64 bytes from 192.168.11.3: seq=642 ttl=254 time=1.858 ms
64 bytes from 192.168.11.3: seq=643 ttl=254 time=1.673 ms
64 bytes from 192.168.11.3: seq=644 ttl=254 time=423.194 ms
64 bytes from 192.168.11.3: seq=645 ttl=254 time=883.148 ms
64 bytes from 192.168.11.3: seq=646 ttl=254 time=1.597 ms
64 bytes from 192.168.11.3: seq=647 ttl=254 time=1.670 ms
64 bytes from 192.168.11.3: seq=648 ttl=254 time=1.567 ms
64 bytes from 192.168.11.3: seq=649 ttl=254 time=1.783 ms
64 bytes from 192.168.11.3: seq=650 ttl=254 time=1.775 ms
64 bytes from 192.168.11.3: seq=651 ttl=254 time=1.817 ms
64 bytes from 192.168.11.3: seq=652 ttl=254 time=1.729 ms
64 bytes from 192.168.11.3: seq=653 ttl=254 time=1.654 ms
64 bytes from 192.168.11.3: seq=654 ttl=254 time=1.924 ms
64 bytes from 192.168.11.3: seq=655 ttl=254 time=434.177 ms
64 bytes from 192.168.11.3: seq=656 ttl=254 time=892.426 ms
64 bytes from 192.168.11.3: seq=657 ttl=254 time=1.629 ms
64 bytes from 192.168.11.3: seq=658 ttl=254 time=1.902 ms

[OnFreund]

doesn't seem unique to pinging the Risco system

I thought we're talking about CoolMaster.

In any case, these are too frequent to be explained by the integration trying to connect. You probably have some add-on or custom integration that is hogging your network every X seconds, and every now and then, it coincides with CoolMaster fetching data. Even a retry won't necessarily help, because there are two consecutive slow pings.

I suggest you try disabling integrations and add-ons to see which one is causing this.

[ekutner]

I'm sorry, we are talking about CoolMaster. I was thinking I needed to find time to look at the tests you asked me to add for the Risco related PR I submitted a few months ago and probably wrote Risco instead of CoolMaster because of that. You might call it a Freundian slip :)

Back to the issue at hand. Since the integration doesn't log exactly what was the issue it encountered I tried running tcpdump to capture the network traffic to see what was going on. When I did that, the craziest thing happened. The extended ping responses disappeared and all responses were under 3ms and the CoolMaster, which usually repeats quite often didn't happen in nearly 24h of running the network capture. As soon as I stopped the capture the extended pings were back and the CoolMaster error occurred again within an hour. I have over 30 years networking experience and have never seen anything like this before, so I have no idea what's going on and I'm still trying to figure it out.
That said, it would be very helpful if the integration logged the exception that was received in the _async_update_data() function. It would help understand what was the actual problem it encountered. I'm also quite convinced that a retry (or two) would hide the issue well enough that it wouldn't matter what the real underlying root cause is. Since there is no downside I can think of, it would be a good enough solution that might help others as well.

[OnFreund]

You might call it a Freundian slip :)

:)

I have over 30 years networking experience and have never seen anything like this before, so I have no idea what's going on and I'm still trying to figure it out.

Very strange indeed. My guess (purely a guess) would be that tcpdump is changing timing on whatever is hogging the network.

That said, it would be very helpful if the integration logged the exception that was received in the _async_update_data() function.

I agree, but I think that in this case it's simply a timeout, especially if it always takes 1 second to fail (does it?)

I'm also quite convinced that a retry (or two) would hide the issue well enough that it wouldn't matter what the real underlying root cause is.

Potentially, but I would still encourage you to find the root cause, because it will eventually manifest in other ways.
In any case, feel free to create a PR with the logging enhancement and the retry mechanism.

[OnFreund]

Are you using the Tuya integration? This was the cause for a similar issue in another integrations: #146405

[ekutner]

I'm not using the Tuya integration.
I want to submit that PR with the extra logging and retries. Would you require tests for that? Because I don't see an existing test file for the coordinator so not sure how/if it should be tested.

[OnFreund]

The coordinator is tested using the the tests for the entity platforms, so you can add the relevant tests there.

[ekutner]

Just an FYI, I finally found out what was causing those extended reply times in ping. It's this arpscan-based device tracker component that I'm using: https://github.com/cyberjunky/home-assistant-arpscan_tracker. After disabling it the pings are very consistent at <5ms but the CoolMaster disconnects/reconnects are still happening as before.

[OnFreund]

Did you try it with the retry?