Open tomjn opened 12 months ago
One other thing I wanted to try was storing a base image on each view, there's no need to re-render all the icons and backgrounds every single frame, better to render it once, then copy and draw text/charts over the top. I don't know how much this would actually save though
This is some great effort toward making this a better script, thank you and sorry it has gone largely ignored. Everything is on fire for me right now, but I'm working through it.
I've upgraded Grow to our latest Python packaging standards, and am now starting to migrate it from RPi.GPIO over to gpiod/gpiodevice. This is quite a significant upheavel and will conflict and make a merry mess of your well intentioned changes.
Would you like to:
Or:
Wrangle everything you need to and I'll revisit this, then I can do it in more atomic PRs instead of one great big one.
I actually have one or two bugbears I've been meaning to fix in this, not sure if they affect the main branch too or just my work:
I also determined most of the CPU usage after these changes is from image rendering, and there's newer versions/replacements of the library used.
Something I would suggest though:
bin
folder but instead just a wrapper is installed, that way updating the script is just a git pull
away rather than doing vim surgery in the user bin folder as rootThe monitor
script would also be relying on packages in a virtual environment in most cases, so I need to figure out how to run "services" like that in the context of the correct venv 😬
Work in progress for the migration is here - https://github.com/pimoroni/grow-python/pull/36
Huge roadblock for this is that gpiod
doesn't support soft PWM, nor will it ever. I've tried to implement PWM in pure Python and it works, but it's not stable or reliable. Might have to roll a new, do-one-thing-succinctly PWM library for this.
I haven't tackled edge counting with the sensors yet, either, but in theory gpiod
should handle that reasonably well.
The grow monitor service was using a lot of CPU on my Pi Zero 1 which ate up power, regularly in the 70-90% CPU utilisation.
At this point I thought, does it really have to update, render, and resave the config on every single loop?
So I split it out into 3 functions and use the
schedule
package, now it's much more likely to be in the 30-60% CPU range, and the main loop is much cleaner.