@sdetweil

Hi Sam,

I wanted to give you a quick update and, most importantly, say a huge thank you for your incredibly fast and professional help! It’s amazing to see how quickly you identified the defect and even opened an official issue on GitHub.

I’ve been monitoring the develop branch, and the fix is definitely working. The “rapid-fire” request loop is gone. Even with my temporary IP block, the logs show that the system is now handling the situation gracefully without spamming the API anymore:

Apr 21 07:45:29 MagicMirror npm[495]: [2026-04-21 07:45:29.616] [WARN]  [http_fetcher] [weatherprovider.openmeteo] ...
Apr 21 07:45:40 MagicMirror npm[495]: [2026-04-21 07:45:40.581] [LOG]   [weather] Received INIT_WEATHER for instance module_5_weather

The system is stable now, and I’m just waiting for Open-Meteo to lift the rate limit. I’ll provide another final update in a few days to confirm everything is still running smoothly, but for now: Thanks again, Sam! I really appreciate the support you give to this community.

@sdetweil
Hi Sam,

I’ve been testing the new develop branch of the weather module over the last few days, and I wanted to give you some positive feedback.

My tablet recently developed a life of its own (eigenartiges Eigenleben), causing unpredictable connection drops and browser reloads. This would have normally triggered the 24-hour API limit for OpenMeteo, but your new protection logic completely saved my setup! It’s great to see that the module now prevents “rogue” clients from getting the whole IP banned.

While testing, I had one idea for an improvement:
Currently, if a client reconnects during the backend’s “protection phase,” it stays on “Loading…” until the next scheduled fetch. It would be the icing on the cake if the module could immediately push the cached data to a newly connected client, instead of making it wait for the next real API call.

Anyway, thanks for the amazing work. Everything is running smoothly now!

Best regards,

Florian