@rkorell That should already be fixed in the develop branch by https://github.com/MagicMirrorOrg/MagicMirror/pull/4161 and will be in the next release. It would be great if you could switch to the develop branch and test it before the release :) Good analysis, by the way!

@wimthoelke
Please update to the new version (v4.4.3). Your stationID works for me.
If this doesn’t work: use the profile dbweb.
If this doesn’t work, checkout this module: MMM-PublicTransportHub

@Volkae said:
everything worked fine, but since two days it does not work anymore. It only signs “Abfahrtsschnittstelle nicht erreichbar”.

There have been some recent issues with certain APIs (we use different ones depending on the profile). Tell me which profile you’re using and which station and I’ll check. If you don’t want to share the station here, you can also send it to me via private message.

@sdetweil said:

this used to be default behavior

Are you sure? Do you remember in which version it worked that way? I’m not aware of it ever being the default, but I could be wrong :)

@sdetweil CX3 should use each event’s source-calendar color even when multiple calendars are shown together in the same month view. Does it work with multiple calendars?

@kkmirr04 Does it work when you add this to your custom.css?

.CX3 .event.singleday .headline .title,
.CX3 .event.singleday .headline .time {
  color: var(--calendarColor);
}

@Richard238 I haven’t had any problems with this new version.

@angeliKITTYx This shouldn’t happen with the just released new version v2.36.0. I recommend to update :)

@sdetweil said:

@kristjanesperanto what do you think of this?

Hmm… I didn’t expect something like that in the current release. But I won’t be able to take a closer look at it right away. It would be interesting to see if this also happens in the develop branch.

@Phantomkommander said:

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.

Good suggestion. I’ve opened a PR (https://github.com/MagicMirrorOrg/MagicMirror/pull/4121) to implement that :)

@iamktothek You don’t need node-fetch. The fetch API is built-in meanwhile :-)

@Dentrass-0 Cool 👍 You could now remove the npm install command from the README.

@Dentrass-0 You could ask ChatGPT how to replace axios with fetch in your module.
That would even have the advantage of simplifying the installation and update process, since npm install would no longer be necessary.

@Dentrass-0 Nice! 👏

But why are you using axios? And why an super outdated version from 2023?
axios should be easily replaceable with the built-in fetch API.

@SdR I tested this config on my side and it works. I only had to add one missing closing bracket in your snippet.

Do you see any errors in the terminal?

Also, after pulling the new version, did you run: node --run install-mm?

If openmeteo is also empty, this looks like a general config/runtime issue, not only an OpenWeather API issue.

Please show us the systeminformation from the terminal. Looks like this:

[2026-04-07 21:13:27.184] [INFO]  [systeminformation] 
####  System Information  ####
- SYSTEM:   manufacturer: Micro-Star International Co., Ltd.; model: MS-7D75; virtual: false; MM: v2.36.0-develop
- OS:       platform: linux; distro: Debian GNU/Linux; release: forky/sid; arch: x64; kernel: 6.19.10+deb14-amd64
- VERSIONS: electron: 41.1.1; used node: 25.9.0; installed node: 25.9.0; npm: 11.12.1; pm2: 6.0.14
- ENV:      XDG_SESSION_TYPE: wayland; MM_CONFIG_FILE: undefined
            WAYLAND_DISPLAY:  wayland-0; DISPLAY: :0; ELECTRON_ENABLE_GPU: undefined
- RAM:      total: 61881.24 MB; free: 42885.43 MB; used: 18995.81 MB
- OTHERS:   uptime: 45 minutes; timeZone: Europe/Berlin

@BKeyport Okay, no rush 🙂

Sam is right, that was caused by the big rewrite (which resolved other issues, particularly a fundamental architectural one).

A fix is already in the develop branch: https://github.com/MagicMirrorOrg/MagicMirror/pull/4092

Are you familiar enough with Git to test the develop branch?

So that you can start receiving weather data again right away and don’t have to wait until we’ve figured the issue out, I’d suggest you try a different provider.

https://docs.magicmirror.builders/modules/weather.html

@SdR, did apiVersion: "2.5" really still work before the MM update? That version was deprecated a long time ago (June 2024). See https://forum.magicmirror.builders/topic/18662/modules-using-openweather-api-need-review.

@oskisch Are you still on the develop branch? Are there still errors in the console?