Environment
MagicMirror²: 2.37.0
Weather provider: Open-Meteo
Hardware: Raspberry Pi 4
OS: Debian 13
Architecture: ARM64
Electron: 42.5.2
Which start option are you using?
node --run start
Are you using PM2?
Yes
Module
weather
Have you tried disabling other modules?
Have you searched if someone else has already reported the issue on the forum or in the issues?
What did you do?
Configuration
{
module: "weather",
config: {
weatherProvider: "openmeteo",
type: "current",
initialLoadDelay: 0
}
},
{
module: "weather",
config: {
weatherProvider: "openmeteo",
type: "hourly",
initialLoadDelay: 15000
}
},
{
module: "weather",
config: {
weatherProvider: "openmeteo",
type: "forecast",
initialLoadDelay: 30000
}
}
<!-- Paste relevant code here -->
Steps to reproduce the issue:
I use three Open-Meteo weather instances: current, hourly, and forecast. They are configured with different delays so their first requests do not all occur simultaneously.
What did you expect to happen?
The first requests should begin at approximately:
- Current: immediately
- Hourly: after 15 seconds
- Forecast: after 30 seconds
Subsequent requests should continue according to each instance’s updateInterval.
What actually happened?
All three providers begin fetching at nearly the same time.
When Open-Meteo or the network is slow, the three instances also time out and retry together. On my Raspberry Pi, the log showed all three timeout messages at nearly identical timestamps.
Additional comments
The weather module includes initialLoadDelay in the configuration sent through INIT_WEATHER, but the server-side Open-Meteo provider starts HTTPFetcher immediately.
HTTPFetcher.startPeriodicFetch() immediately calls fetch(), so the configured delay is never applied.
Participation
Environment
MagicMirror²: 2.37.0
Weather provider: Open-Meteo
Hardware: Raspberry Pi 4
OS: Debian 13
Architecture: ARM64
Electron: 42.5.2
Which start option are you using?
node --run start
Are you using PM2?
Yes
Module
weather
Have you tried disabling other modules?
Have you searched if someone else has already reported the issue on the forum or in the issues?
What did you do?
Configuration
Steps to reproduce the issue:
I use three Open-Meteo weather instances: current, hourly, and forecast. They are configured with different delays so their first requests do not all occur simultaneously.
What did you expect to happen?
The first requests should begin at approximately:
Subsequent requests should continue according to each instance’s updateInterval.
What actually happened?
All three providers begin fetching at nearly the same time.
When Open-Meteo or the network is slow, the three instances also time out and retry together. On my Raspberry Pi, the log showed all three timeout messages at nearly identical timestamps.
Additional comments
The weather module includes initialLoadDelay in the configuration sent through INIT_WEATHER, but the server-side Open-Meteo provider starts HTTPFetcher immediately.
HTTPFetcher.startPeriodicFetch() immediately calls fetch(), so the configured delay is never applied.
Participation