Read the statement by Michael Teeuw here.
Request loop & "Loading..." in standard weather module (Open-Meteo) after update
-
Hi everyone,
I’m struggling with the default weather module since the latest update. I’ve already spent some time analyzing the logs and behavior with the help of an AI (Gemini) to pinpoint the cause. Here is what we found:
-
The Issue:
Most of the time, I just see “Loading…”. The logs show a massive request loop, firing hundreds of requests per minute.
Key Observation: The weather is often displayed correctly in the morning until early afternoon. After that, it breaks. This strongly suggests that the request loop exhausts the rate limit or triggers an IP ban from Open-Meteo every day. -
My Environment:
Provider: Open-Meteo (no API key).
Platform: Proxmox LXC Container (Fresh install via helper script).
Network: Pi-hole is running, but Open-Meteo is whitelisted. DNS resolution is fine.
- Troubleshooting steps taken:
Fresh Install: Completely recreated the LXC container – no change.
Config: Increased updateInterval significantly, but it’s ignored during the loop.
Alternatives: Investigated MMM-OneCallWeather and OWM, but the “Free Plan” doesn’t provide the forecast data I need without a credit card.
It looks like the http_fetcher or the weather node_helper is stuck in a logic loop and ignores the update intervals for Open-Meteo. Any advice on how to fix this?
-
-
@Phantomkommander can you show you config for the weather module
-
@sdetweil Hi Sam,
here is my current configuration for the weather modules. I am using the default weather module with Open-Meteo.
{ module: "weather", position: "top_right", config: { weatherProvider: "openmeteo", type: "current", tempUnits: "metric", lat: 50.4667, lon: 7.6333, useKmh: true, updateInterval: 20 * 60 * 1000, } }, { module: "weather", position: "top_right", header: "Wetter Vorhersage", config: { weatherProvider: "openmeteo", type: "forecast", lat: 50.4667, lon: 7.6333, useKmh: true, updateInterval: 20 * 60 * 1000, } },An interesting update: Right now, the weather data is actually being displayed correctly again. However, based on my observations over the last few days, it usually works in the morning and early afternoon, and then fails (stuck on ‘Loading’) for the rest of the day.
This supports the theory that the request loop I see in the logs (journalctl) eventually triggers a rate limit or a temporary IP ban from Open-Meteo. The config seems to work fundamentally, but the fetching behavior is out of control."


-
@Phantomkommander great! Can you post some of the log entries?
-
@sdetweil
"Hi Sam,for comparison, here are the current logs while the system is working correctly. As you can see, the weather provider initializes and then stays quiet for several minutes:
Apr 18 14:56:53 MagicMirror npm[230]: [2026-04-18 14:56:53.051] [LOG] [weather] Attempting to initialize provider openmeteo... Apr 18 14:56:53 MagicMirror npm[230]: [2026-04-18 14:56:53.317] [LOG] [weather] Weather provider openmeteo initialized... Apr 18 15:06:53 MagicMirror npm[230]: [2026-04-18 15:06:53.184] [LOG] [weather] Attempting to initialize provider openmeteo...And here again is the ‘Loop’ state from earlier today (for direct comparison):
[18.04.2026 10:15:22.453] [INFO] [http_fetcher] [weatherprovider.openmeteo] Fetching url: https://api.open-meteo.com/v1/forecast?latitude=50.4667&longitude=7.6333... [18.04.2026 10:15:22.510] [INFO] [http_fetcher] [weatherprovider.openmeteo] Fetching url: https://api.open-meteo.com/v1/forecast?latitude=50.4667&longitude=7.6333... [18.04.2026 10:15:22.622] [INFO] [http_fetcher] [weatherprovider.openmeteo] Fetching url: https://api.open-meteo.com/v1/forecast?latitude=50.4667&longitude=7.6333...The difference is clear: When it fails, it ignores the timing logic entirely. It seems that once a specific error occurs (maybe a temporary timeout from Open-Meteo), the http_fetcher enters a state where it retries instantly without any back-off delay."
-
@Phantomkommander thanks. I think this is a defect in the new weather data collector
I opened an issue in the MagicMirror GitHub repo so we can make sure it’s tracked and fixed
See https://github.com/MagicMirrorOrg/MagicMirror/issues/4109
-
@sdetweil “Thank you, Sam! I’m glad the logs were helpful in identifying the defect. I’ll keep an eye on the GitHub issue and wait for the official fix. Thanks for your great support!”
-
Actually, there might have already been a fix in the develop branch…
so you could try that first…
see this topic on how to get the develop branch
https://forum.magicmirror.builders/topic/14327/testing-new-fixes-or-solving-current-problems-with-next-release-code
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login