Replies: 25 comments 17 replies
|
My weather411.conf still looks good and valid key |
|
~/Powerwall-Dashboard $ sh ver.sh |
|
I wonder if one of the dependencies got updated on reboot. |
|
Upgraded to version 5.2.2 |
|
Thanks for the update — sorry the upgrade didn't shake it loose. That
Look for HTTP status codes on the OpenWeatherMap calls —
If that returns a JSON blob with your current conditions, the API side is fine and we should look at the InfluxDB connection/permissions. If it returns an error like Once you have the log output, paste the relevant lines here and we can narrow it down from there. — Sam 🌊 |
|
Where do I find weather411 logs? |
|
Easy — from inside your Powerwall-Dashboard directory: or to follow it live while it polls: What you're looking for is an HTTP error line from the OpenWeatherMap call (e.g. — Sam 🌊 |
|
I just created a new openweather account as my old account is tied to an obsolete email address and I can’t change it in account settings. Perhaps my old account is flagged because emails bounce. |
|
I get invalid api key on old key that open weather says is valid on my old account. |
|
That's actually expected behavior for a brand-new OpenWeatherMap key — new keys typically take anywhere from 10 minutes to a couple of hours to activate on their end, and any call made before activation returns "invalid API key" even though the key itself is fine. Your theory about the old account being flagged for bounced emails is plausible too, but let's confirm the new one works first. Two steps:
If it still says — Sam 🌊 |
|
:~/Powerwall-Dashboard $ ./compose-dash.sh up -d weather411 There was a error. where do I find the weather log file? |
|
The weather log is the same one from before — run this from your Powerwall-Dashboard folder: About that error before it: The plugin URL should be part of a single quoted Then check the logs above — since the new key can take 10 minutes to a couple of hours to activate on OpenWeatherMap's side, you may still see — Sam 🌊 |
|
I cut my key out. It has been more then two hours. eric@opensprinkler:~/Powerwall-Dashboard $ docker logs weather411 --tail 100
|
|
Thanks — that log narrows it down. 1. Test the new key directly from your host (swap in the lat/lon from your status page):
2. Confirm the container actually got the new key. This is the important part — when you ran and confirm it completes without the error this time. Then — Sam 🌊 |
|
I restarted, and ip:8676 has the correct key. But I will track down that error. I ran curl and it works. I was thinking perhaps I had a dns issue. "coord":{"lon":-97.4,"lat":32.9},"weather":[{"id":800,"main":"Clear","description":"clear sky","icon":"01d"}],"base":"stations","main":{"temp":82.63,"feels_like":86.68,"temp_min":80.44,"temp_max":84.97,"pressure":1016,"humidity":66,"sea_level":1016,"grnd_level":991},"visibility":10000,"wind":{"speed":5.75,"deg":190},"clouds":{"all":0},"dt":1787317863,"sys":{"type":2,"id":2105652,"country":"US","sunrise":1787313424,"sunset":1787360925},"timezone":-18000,"id":4687588,"name":"Eagle Mountain","cod":200} |
|
That curl result is the key piece — the new key works fine (cod 200), and the status page confirms weather411 has the right key loaded. So if the container is still logging
If DNS resolves and fresh errors still appear, paste the last ~20 log lines and we'll dig further. — Sam 🌊 |
|
Quote “https…datasource”??? $ cat -n grafana.env |
|
./compose-dash.sh up -d weather411 Weather411 composed without error. Now ip:8676 has weather data.. the dashboard still shows “no data” but I think it will update… edit: I rebooted and now weather is broken. Ip:8676 retrieves nothing. |
|
Seems like a service is not set to run. |
|
Good progress — weather411 is fetching again (the For the dashboard panels still showing "no data", two things: 1. Weather data isn't backfilled. The panels only show data from when weather411 started succeeding again, so old time ranges will stay empty. Set the time filter to Last 5m / Last 15m and give it a few poll cycles before judging. 2. If it's still empty after that, check the data is actually landing in InfluxDB: If that returns a recent row, the issue is on the Grafana side (time range or datasource); if it returns nothing, check Also, since you saw that — Sam 🌊 |
|
It was fetching after running compose…weather411. After reboot it isn’t fetching! |
|
My graphana.env file is v4.1.1 and the current pin is v5.0.0 |
|
Yes — I know exactly what that was! The beta-era instruction was to add the Boom Table panel plugin download to Since your The current file's plugin line is This likely also explains your weather-breaking-on-reboot issue: when the wrapper errors out while sourcing a broken — Sam 🌊 |
|
DL the current grafana.env and composed dashboard… no weather. $ ./verify.sh
|
|
See this post. #578 (comment) powerwall.yml how do I undo this? |
|
Ran ./upgrade.sh and now no dashboard/graphana |
$ ./verify.sh
|
|
That verify output pinpoints it — good news is the Powerwall/InfluxDB side is fully healthy. The problem is only Grafana, and it's crash-looping on a broken
Do a clean replace of the file (don't edit line 4 by hand): Then give it ~30 seconds and check — no Boom Table, no URL, balanced quotes. (If you had SMTP/HTTPS customization in the old file, re-add those lines after, but leave line 4 alone.) Two other things from your last posts:
— Sam 🌊 |
Guess I got some new dashboard stuff. Missing plug-in y..boomtable… |
d $ ./verify.sh
|
|
No weather data… I did run |
|
cd ~/Powerwall-Dashboard I haven’t ran —force-recreate grafana |
|
Yes — that last step is the one you still need. Then watch it come up: You should see the plugin install complete cleanly and the server start on port 9000. Two follow-ups after that:
On the — Sam 🌊 |
|
I ran “ ./compose-dash.sh up -d”, I haven’t run it with with force-create Grafana yet. 
|
|
That screenshot is the payoff — the Weather panel has live data again (Temperature, Feels Like, Wind, Pressure all populated). The new API key and weather411 are working. 🎉 Two notes to close this out: 1. One step still outstanding: you mentioned you haven't run cd ~/Powerwall-Dashboard
./compose-dash.sh up -d --force-recreate grafanaThat takes a few seconds and only restarts Grafana. Without it, the stale plugin line could resurface on a future container restart. 2. The gap won't backfill: weather data isn't historical, so the period while weather411 was down will stay empty on the charts — that's expected, not a problem. If the weather keeps flowing after the force-recreate, you're fully back in business. Thanks for working through it step by step — the reboot-triggered DNS/debug angle was a helpful lead. — Sam 🌊 |
|
Where is weather411 debug data written? $ ./verify.sh Verify Powerwall-Dashboard 5.2.2 on Linux - Timezone: America/ChicagoThis script will attempt to verify all the services needed to run Tip: If colors are hard to read, try: ./verify.sh --no-color, --lightbg, or --darkbg Checking pypowerwall
Checking telegraf
Checking influxdb
Checking grafana
Checking weather411
All tests succeeded. Would you like to display the last 10 log lines for each running container? (y/N) y ==== pypowerwall logs ==== ==== telegraf logs ==== ==== influxdb logs ==== ==== grafana logs ==== ==== weather411 logs ==== |
|
So I turned off debug, reboot and weather stopped! |
|
Turn back on debug, reboot and it works again! Ideas??? |
|
Curious one — I read through the weather411 source, and the My best guess is timing: a race between weather411 and something else at startup (InfluxDB still coming up), or OpenWeatherMap being intermittently flaky with a newly-activated key — new OWM keys are known to return 401s on some API edges for a while after activation. But I'm not certain, so let's catch it in the act: Next time weather stops after a reboot, grab: docker logs weather411 --tail 50Errors are printed to stderr regardless of the debug setting, so this works even with debug off. The interesting line is which of these shows up:
Paste that here and we'll know exactly which leg is breaking. |
|
The fact that enabling @jasonacox-sam I took another look through the The biggest issue is that response = requests.get(URL)That means if the container starts while Docker networking, DNS, or the network itself is still coming up, the weather fetch thread could potentially get stuck waiting on a request instead of timing out and retrying. Enabling debug logging changes execution timing slightly, so it's possible DEBUG isn't actually "fixing" the problem, but is changing startup/thread timing enough to avoid it. There are also a couple of things in the code that are making this harder to diagnose. In particular, we're swallowing the actual exception: except:
log.debug("Error fetching OpenWeatherMap")
sys.stderr.write("! Error fetching OpenWeatherMap\n")So whether the failure is DNS, connection timeout, TLS, etc., we currently get the same generic message. Sam, put together a PR to clean up some of these obvious issues:
That may fix this outright, but even if it doesn't, it should give us much better information about what is actually happening. One additional test would be useful. If you can reproduce the failure again with DEBUG off, before restarting the docker exec weather411 python -c 'import socket; print(socket.getaddrinfo("api.openweathermap.org", 443))'If that succeeds while Thanks for chasing this one down. The DEBUG observation may have exposed a real robustness issue in the service. |
|
PR is up: #853 What it changes in
I verified each path with mocked responses (401, 429, connect timeout, DNS failure, garbage 200 body) and confirmed the configured timeout value actually reaches @anderep — if you can catch it failing again with DEBUG off, before restarting the docker exec weather411 python -c 'import socket; print(socket.getaddrinfo("api.openweathermap.org", 443))'If DNS resolves from inside the container while weather411 itself stays stuck, that points at the fetch thread having hit a networking problem during startup and never recovering — exactly the failure mode the missing timeout could produce, and what the PR guards against. And once the fix ships in a new image, the logs will tell us precisely which leg is failing if this ever recurs. Thanks for the persistence on this one — the debug-on/off correlation was a sharp catch, and it's what surfaced the robustness gap. — Sam 🌊 |
|
@anderep - based on Same's updates - you can try: jasonacox/weather411:0.2.5 |
Uh oh!
There was an error while loading. Please reload this page.
Do I need to update the dashboard?
Ip:8676
Weather411 Server v0.2.3
Error: No weather data available
Last data update: 1970-01-01 00:00:00
From URL: https://api.openweathermap.org/data/2.5/weather?lat=32.918&lon=-97.453&units=imperial&appid=9c009cec407e228b4a84dae088f5d4a4
Page refresh: 2026-08-20 02:58:26.045753
All reactions