It looks like just another weather report, but this one is a bit different.
There is a raspberry pi running under the TV. It gets weather data from various APIs, including the local sensors inside and outside the house. Then it calibrates the weather forecast using a neural network model trained on historical data. It creates the weather report image every hour and makes it available via a Rest API.
The Inky Frame wakes up every hour, retrieves new images from the API on the RPI, and displays.
Next steps : program the buttons to show a snow report, or a dashboard of info taken from heating system or other devices in the house.
Code is on Github but not public.
Haven’t figured out how to hide the secrets.py on gh, as well as various credentials to access APIs. I suppose I just delete it and keep it separately.
you should create a file called .gitignore in the root of your project and add all filenames there, that contain secrets or things not to publish. Git will then prevent the upload of these files.
I typically use something like this:
*.pyc
TODO
boot_out.txt*
lib
*secrets.py
__pycache__
settings.py
.venv*
If you already have it on github, you must be careful, because users can go back in history and find deleted files. So maybe it is better to save your work, delete the complete repo, and recreate it. Of course you also loose your complete history this way.
An alternative is to create a second, public version of the project. But that is hard to maintain in parallel.
Matplotlib is infinitely powerful, but quite frustrating. There is a lot of hacking going on here.
Just for fun, the rendering back-end can be different on each platform, so I had to re-do all the font sizes and alignments when I ported it from Mac OS to RPI.
The blocking change is strange, I would have expected that you’d want the graphics update to block so that the board doesn’t try to go into sleep before the update is done.
I bought the HAT version of Inky Impression, and I’m now mulling over the practicalities of making a Pico adapter for it. It would be a learning experience, but that can be fun in itself, and having the whole thing run on batteries might just be nicer.
Ah, brilliant! I’ve done a bit of PCB design before, but I don’t have much experience with the nitty-gritty of MOSFETs, so I was nosing at the schematic for the Inky Frame and trying to work it out from there, but yours looks more simple. 0.35 microamps is fantastic. What kind of batteries are you running it off?
I am using an 18650 LiPo cell. But it should work with any LiPo. The reason for the 18650 is historic: I had this running with a Pi-Zero-W (also with some power-management electronics). Compared to the Pico, the Pi needs a lot more current during an update-cycle so the beefy battery was necessary. Since swapping in the Pico I can’t remember when I had to recharge the battery. Self-discharge is probably higher than what I actually use.
Ah interesting, thanks! I’m now working through figuring out how to get something similar going. I’ve run some preliminary numbers and wow, yeah, theoretically you get a lot of refresh cycles if you control the power with an RTC/MOSFET pair!
Yes, I’m a bit surprised at how poor the Pico is in terms of low power, it obviously wasn’t much of a priority for them. In fairness, a dedicated PCB without the LEDs and regulators etc. might be better, but when the MOSFET works so well I’m not sure if the effort is really worth it.
I’d also just like to get used to using MOSFETs as I’ve other projects in mind which will have sensors and things which would benefit from being turned off totally when not needed. I know the RTC could just control the enable pin of a regulator, but I think it is worth knowing anyway.