Closed T0ytoy closed 10 months ago
@T0ytoy thanks for the report.. well technically should be possible to run on another thread, but I had some difficulty to implement it. I will try to optionally set a limit for the CPU (this is almost implemented), let's say if we go over 50% then it will automatically suspend the rendering, if the option is active. I assume also that on your case there are other components running on the background and would be really useful to know what is the CPU usage when the camera is in idle (simply seting the camera off from the service) and wait for a couple of seconds.. Would please provide me this value? Honestly the PI4 used in the test actually runs just some additional add on.. the problem is that with openCV this issue would not exist but the HAOS isn't supporting it. Alternatively you might try the ValetudoPNG, that probably is much more light than this camera.
Here is a graph of my rpi cpu usage yesterday :
From 19:00 -> 23:00 usage is about 7-8% (as per usal), then from 23:00 -> 1h30 vacuum was running, cpu load is about 30% (100% on 1 core).
I juste tested disabling the camera through the service, and setting the vacuum to go to a point far away: no performance issue at all. After I re-enabled the camera and made the vacuum go back to base, CPU was often close to 90-100% on 1 core. There is only Home Assistant, mosquitto and Z2M running on that pi, I have a lot of custom integrations activated though.
You mention ValetudoPNG, does it generate automatic calibration values for the xiaomi vacuum card? Nice thing about it is that it can be executed on another computer, and I have a mini-pc that could run it. Best thing would probably be to migrate my home assistant to that pc, but I like the idea of having a separate host for smart-home related stuff!
Anyway thank you very much, please ask if I can do anything!
I think (from wha I understood) ValetudoPNG is actually supporting the calibration of the card as well. This is why I thought that as alternative to this could help in this case. So.. in summary.. I will restart to think out a solution to run on a separate thread and probably this will help. In general the camera should draw just the robot and eventually the complete image when there is a difference on the walls detected. From the camera logs is possible to see the number of frames and the frequency of the total refresh is marked as frame 0. that normally is the highest consuming part... mmmm okay.. can't promises that this will be fix soon but.. will work on it, although, ValetudoPNG actually can really run from another computer (so far I know it is contained)? if so probably I can simply do the same and let docker think about the CPU ;)
p.s. this is actually a great inspiration idea, thank a lot for it..
Thank you, I will try ValetudoPNG in the meantime. And yes, having the image generation on a separeted container (as an option) would be a great feature!
Great job on this project though, I hope it will get better and better!
Feedback for you if you're interested: ValetudoPNG works good on another computer on it's own container. Performances are good and it works for me. However valetudo vacuum camera is way easier to set up, good job :)
Let me know if you want me to test something on my rpi 3B+ ;)
Feedback for you if you're interested: ValetudoPNG works good on another computer on it's own container. Performances are good and it works for me. However valetudo vacuum camera is way easier to set up, good job :)
Let me know if you want me to test something on my rpi 3B+ ;)
Of course I'm interested, thanks for letting me know. In other to keep this camera easy to setup and use I'm working on a solution to run the image creation and rendering smooth.
As you know unfortunately there is a huge limit as per we can't use OpenCV on the HAOS. In any cases as this will take time, I'm glad to read that you successfully installed ValetudoPNG, and I will keep open this item, providing some updates from time to time, so that you can eventually confirm if it will work also on the 3B+ (I thought to buy one of these too to make some test on it as well).
If you star the project I guess this will help us to keep in touch 😉
@T0ytoy I'm working right now on the implementation of multiprocessing = new thread for the camera.. if it will work will go ahead to release a beta version of it.. it is a little complicated to explain and also to implement anyhow, thanks a lot man, this improvement will help for sure also to improve the performance of the rendering, if it works ;)
Checklist
The problem
When the vacuum is running, even if not displaying the xiaomii-vacuum-card, my Hass instance almost completely hangs: navigating the app is slow, even switch on / off a light with a smart button IRL can take > 20 seconds. If watching the vacuum card, the vacuum position updates but pretty slowly (a few times each minute).
CPU usage is ~30% (one core seem to be maxed out, the 3 others are doing nothing), top indicates that 'python3' process is using 100% CPU.
As soon as the vacuum stops its cycle, everything go back to normal. I am aware that the Rpi 3B+ is slower than the Rpi4 you are using to test releases, so maybe it is just not enough powerful. That being said it is still weird it maxes out one core and leave nothing to Home Assistant process.
Would it be possible to execute valetudo vacuum camera computations on another thread?
I am available to help test things out as much as needed, thank you very much for your hard work!
What version of an integration has described problem?
v1.5.5
What was the last working version of an integration?
No response
What vacuum model do you have problems with?
Dreame L10s Ultra
Please firmware installed on your Vacuum.
3018 with Valetudo 2023.12.0
What version of Home Assistant do you use?
2024.1.0
What type of installation are you running?
Home Assistant Container
Camera's settings.
Logs or Errors shown in the HA snapshots (please enable the Debug Mode)
No response
Additional information
No response