Weather display project

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.

3 Likes

Very nice, thanks for sharing!

That’s some lovely weather data! Are you planning at any point to switch it to battery power?

Do you have the Code up on Github or somewhere else?

I had a problem with screen refresh on battery. After reading the forums, I modified the code like this:

graphics.set_blocking(False)
graphics.update()
while graphics.is_busy():
print(“Waiting for graphics to update”)
time.sleep(2)

not sure if the set_blocking() makes a difference. It started working after I inserted the while loop to wait for it to finish.

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.

Done, it’s here

Not really industrial strength code, but whatever.

Thanks! Does not have to be industrial strength unless you expose the service to the internet.

The matplotlib-stuff is nice. I have tried various similar things directly on the InkyFrame, but the Pico fails due to memory.

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.

I am running the Impression with my own Pico adapters. See GitHub - bablokb/pcb-pico-pi-base: An Interface PCB to use Pi-Hats with a Pi-Pico(w) and also GitHub - bablokb/pcb-pico-power-switch: Suport PCB to switch battery power - designed for a Raspberry Pi Pico

Works great. And I can also use e.g. the Waveshare ESP32-S3-Pico, which is pin-compatible and has plenty of RAM.

1 Like

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?

Those look nice. Much tidier than using a HAT connector with lots of wires.

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!

BTW: in the image you can see a predecessor: GitHub - bablokb/pcb-pico-en-control: Suport PCB to control the enable pin of a Raspberry Pi Pico. This doesn’t even need a mosfet, since it directly controls the enable pin of the Pico. But the mosfet-solution which directly controls power is much better, because even with the enable-pin hard-wired to ground the Pico still draws 75µA.

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.