You don’t need to do that, but if you wanted to, my Github handle is Extra-Fox.
I really don’t do all that much with Github, but I found Github desktop to be useful enough to create an account.
I ran into a weird issue last week with the panel going offline. It just started happening out of nowhere and I wasn’t sure what was going on, but looking into the boot logs showed issues with SPI availability. I have only the most tenuous grasp over what this is about, but I muddled through the issue and ultimately added a new line to my service that runs the program automatically.
Issues with access to SPI had been a problem previously for me and my initial service file reflects that. This was derived by using the LLMs to troubleshoot and suggest changes.
I’ve now added the ”ExecStartPre=/bin/sleep 5" line under the service heading. This was again a suggestion from the LLM and it seems to have worked. I’ve not had the problem return in over a week since implementing the change.
My Service File
[Unit]
Description=Tempest E-Paper Weather Display
After=multi-user.target dev-spidev0.0.device
Requires=dev-spidev0.0.device
[Service]
ExecStartPre=/bin/sleep 5
ExecStart=python3 /home/<usr>/Tempest-7.5-E-Paper-Display/weather.py
WorkingDirectory=/home/<usr>/Tempest-7.5-E-Paper-Display
User=<usr>
Group=spi
Restart=on-failure
[Install]
WantedBy=multi-user.target
I had weird issues with mine originally, I run the service off of a shell script:
[Unit]
Description=WeatherPlus Python Service
After=multi-user.target
Conflicts=getty@tty1.service
[Service]
Type=simple
ExecStart=/home/pi/startup.sh
StandardInput=tty-force
Restart=on-failure
[Install]
WantedBy=multi-user.target
Which then looks like this:
#!/bin/bash
/sbin/iwconfig wlan0 power off
cd /home/pi/weatherpi
python -u weatherpi.py >> python.log
The line here: /sbin/iwconfig wlan0 power off ensures there is no power saving junk applied to the WLAN, then this also allows me to redirect the screen output to the logfile that I do use quite frequently especially with dev work. Is this the right way to do it? Probably not. I’m sure there is commentary on my tomfoolery. But it works. These are not exposed to the internet in any way that I would feel like they are a risk.
You might send error output to a file too, and add a logrotate script.
I have an ancient fork of this nice display that grabs a JSON file from my weewx system and displays it very much like the original e-ink setup. No WF code nor access required.
In doing so, I ran into some issues with unexpected input generally around how the display figures out which icon to display for the forecast, so my fork was a bit unstable until I worked it out.
I tried looping in the script ala display - sleep - clear - display - sleep (etc.) but ran into occasional issues where the bus got locked between refreshes, seemingly because the previous run was crashed/hung.
What I did was punt on a service and drop back to running it out of cron rather than trying to run it as a service or as a modified python script that runs/sleeps/runs/sleeps/etc.
# crontab file entry
2-57/5 * * * * cd /home/pi/Tempest-7.5-E-Paper-Display && timeout 60 python3 weather-cron.py >/tmp/program.out 2>&1
The timeout 60 really helped, as did logging + error-logging to a file so I could figure out what was going on if something went amok. My logging just goes to stdout so it was nice and simple. I’m sure I could have used python logging for more slickness but it was good enough for me.
I run on a pi3+ if that matters. Before needing to reboot the box to relocate it, I had uptime well over 170 days so it’s very stable given good power.
I started noticing that the display would occasionally go blank, or show the network connection error. This started happening more frequently along with emails from Astro.API telling me I was approaching my daily quota.
I checked out the logs for the service and sure enough, Astro.API refuses to serve up information after you hit the quota (code 429). This in turn seemed to be causing a fatal error in the script.
So, I took a chance and had Claude look at it. I told it what I thought was going on, gave it the original script, and the errors from the service. After a few rounds Claude added some new error catching approaches that seems to have cleared up the issue.
Of the things Claude noted was that the original error catching loop doesn’t actually allow it to fall back to the USNO.API service. It also noted that when it had issues connecting with the Astro.API it would go into a really tight loop making a lot of requests that was likely driving the frequent hits to the rate limiter. Take all that with a grain of salt of course.
In the end, I’ve got it back up and running again and I guess in a few days I should know whether the fixes were truly effective.
@Anorine I’m attaching the modified script for you to inspect and decide if you want to use any of it. Or see something Claude missed.
weather.py.txt (35.3 KB)
Hey! Awesome timing as usual. I have a fix for that that is not published. Sob story time, I’ve been so busy with work all of the coding has been so far out of the kitchen a back burner isn’t in the cards.
Yes, yes, very sad. Anyway, I have been running the fix for some time, tonight I changed error screens for more cohesion and timeouts for missing JSON keys. There’s a new alert icon for Extreme Heat Warnings where rather than the warning triangle, it’s two little fires.
I also need to put in your template files. I’ll get to them as soon as I can. For now, I’ll pull the files and get the repository updated.
Death. That’s pretty much how I feel about any weather warmer than about 82F so I’m totally down with that. 
I just uploaded the files. Give her a spin and hopefully that helps. In the event you hit a non-200 status from one of the APIs, it will sleep for 30 minutes. This help alleviate the pounding on the API that only serves to prolong the issue.
Stay cool out there brother!