Conversation
…ssary blank image conversion
|
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:
|
|
The Work in progress for the migration is here - #36 Huge roadblock for this is that I haven't tackled edge counting with the sensors yet, either, but in theory |
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
schedulepackage, now it's much more likely to be in the 30-60% CPU range, and the main loop is much cleaner.