Closed iSteve-O closed 1 month ago
The integration polls for data from the mesh and then calculates a few things based on that. So, a mesh with a large number of devices could use more resources than a smaller one.
What do you have the timings set to? Do you have any device trackers enabled?
The integration polls for data from the mesh and then calculates a few things based on that. So, a mesh with a large number of devices could use more resources than a smaller one.
What do you have the timings set to? Do you have any device trackers enabled?
I have around 50 devices connected to my 3-node mesh, but I am not using any for trackers or UI devices. In fact, the only part of the integration I am actively using is the reboot mesh feature, but I do see how the rest could be really useful.
Currently I have the main scan interval set to the default 60 seconds, which seems to be the culprit, so I suppose I can raise that to significantly decrease the frequency of spikes. The scan interval for device trackers is set to 10 but since I don't have any trackers defined this probably isn't affecting anything and the spikes are around 60 apart.
I do appreciate your response. I guess what you are saying is it just needs that much CPU to parse all of that data. I thought maybe something was amiss. If this is the case the issue can probably be closed.
My set up sounds similar to yours in terms of size (I have a 4th node for an area that would typically be a dead spot).
I have it running on an RPi 4 and don't notice anything amiss, but I'm not actively watching resources either.
There is some processing that I can refactor to make "opt-out". That processing relates to firing events for new nodes and devices. It would have to be opt-out otherwise it would be a breaking change for some I guess.
I'll see what I can do and we can revisit this to see if that helps.
Not sure if this is still an annoyance for you. However, I have done a rewrite of pretty much everything to do with polling and entity building/updates.
It's currently in the dev branch and I'm running on a test device here against my home network. The test rig is Home Assistant in a docker container running on an RPi4.
I'll try and look at CPU stats at some point as well, but it's probably quite dirty as it's also running other containers as well.
I'll close this for now. I've just realised a beta of the reworked integration so we can see if that behaves any better.
I don't know if this is a real issue per se but I wanted to raise it anyway. My pi typically runs around 1-3% CPU usage most of the time, but when this integration is enabled there are frequent spikes in usage about once a minute to at least 5-7% but as much as 15% CPU usage. I just would not expect this integrations to use this much CPU at these intervals.
Without Integration
With Integration
I apologize if I shouldn't be raising this. I really appreciate this integration for the ability to reboot the mesh!