Meanwhile you can add

  maxFlights: 0, // restrict number of shown flights (0 means show all)

to the config.

@philpburns72 said:

if there is a way to limit the number of results this returns?

This feature doesn’t exist at the moment. However, I’ve noticed myself that during peak times, the list can get so long that it scrolls off the bottom of the screen.

The question is how to implement such a filter. One idea would be a maxPlanes property that displays only the n aircraft closest to your own position (both on the map and in the list). But perhaps you have a better suggestion?

@JMac

Regarding Strava: They’ve tightened their API terms of use; in practice, this means that only paying users can access the API. So, if you aren’t a paying Strava user, you can save yourself the trouble of installing any Strava modules…

@sdetweil I did it on github, will write a test for this so that we see it prior to release

@sdetweil

so a normal install without devDependencies should not trigger this error

I wrote “should”, didn’t test it and this was my expectation to node behavior …

As node seems to check all dependencies, we need >= 22.22.2, we can edit release notes and forum post if needed …

the eslint-plugin-package-json dependency has this requirement but this is only a devDependency so a normal install without devDependencies should not trigger this error.

		"node_modules/eslint-plugin-package-json": {
			"version": "1.5.0",
			"resolved": "https://registry.npmjs.org/eslint-plugin-package-json/-/eslint-plugin-package-json-1.5.0.tgz",
			"integrity": "sha512-KQkAdn+7I4vn1W4Va+V8M94RhcgZBvgrxMglDqgEhJgQDRUJ9RdtrEiHoe/84oVTIlp0jiPttLYwkExdvHYhZQ==",
			"dev": true,
			"license": "MIT",
			"dependencies": {
				"@altano/repository-tools": "^2.0.1",
				"change-case": "^5.4.4",
				"detect-indent": "^7.0.2",
				"detect-newline": "^4.0.1",
				"eslint-fix-utils": "~0.4.1",
				"eslint-json-compat-utils": "^0.2.3",
				"jsonc-eslint-parser": "^3.1.0",
				"package-json-validator": "^1.5.0",
				"semver": "^7.7.3",
				"sort-object-keys": "^2.0.0",
				"sort-package-json": "^4.0.0"
			},
			"engines": {
				"node": "^22.22.2 || >=24.15.0"
			},
			"peerDependencies": {
				"@eslint/json": ">=1.0.0",
				"eslint": ">=9.0.0"
			},
			"peerDependenciesMeta": {
				"@eslint/json": {
					"optional": true
				}
			}
		},

I’ve now implemented additional tests, so such errors should be spotted much earlier in the develop branch…

@scottwalsh

thank you for bringing this up. And yes, the debian arm images had the amd64 electron version installed …

I fixed this meanwhile.

If you are happy with the wolfi image you can stay on this tag or use the wolfi-electron tag.

You can set the image in the .env file too (without override).

@fillilutten

I agree with Sam.
That looks like a weather warning to me. They are quite rare, and the scenario might never have occurred during the module’s development…

@noeknl said:

is it possible to locate the list of flights on the right of the map, so I can utilize landscape mode better?

pushed a new version which supports now 4 map positions top, bottom, left, right

@noeknl

works with both providers if you switch the content of your laMin/laMax values …

after some more research I think we are blocked by digitalocean: “SMTP ports 25, 465, and 587 are blocked on Droplets to prevent spam and other abuses on our platform.”

I found another working port so the mail issue should be solved now (until blocked again on the new port …). I was able to send a test mail after the change which failed before.

@htilburgs

the forum is running since 10 days and I think I got the mail last weekend, so nothing changed.

But I found errors in the logs [emailer.send] Error: Connection timeout

@RonR

Thanks for the positive feedback. I found it amusing that you thanked Sam first, since he provides most of the support here — something for which, honestly, I often lack the time and patience…

The problem itself seemed familiar to me; I just had to track down the corresponding issue.

@RonR

see https://gitlab.com/khassel/magicmirror/-/work_items/103

@smegbadger said:

Before I could send this another day passed and now they are correct! Docker is still on UTC but the Clock and Agenda are correctly showing times on BST!

Thanks for the feedback. This is expected behavior. If you really need the timezone for other stuff in the container you can set it by adding this in the compose.yaml:

    environment:
      - TZ=Europe/Berlin

@smegbadger

The external url for getting the TZ doesn’t work anymore, I had to switch to another one. Meanwhile this did not work but I pushed new images some minutes ago which should fix this. So please pull the new image and let me know if it works.

Release Notes

Thanks to: @cgillinger, @khassel, @KristjanESPERANTO, @sonnyb9

⚠️ This release needs nodejs version >=22.21.1 <23 || >=24 (no change to previous release)

Compare to previous Release v2.35.0

This release falls outside the quarterly schedule. We opted for an early release due to:

• Security fix for the internal cors proxy
• API change of the weather provider smi
• Several bug fixes

Breaking Changes

The cors proxy is now disabled by default. If required, it must be explicitly enabled in the config.js file. See the documentation.

⚠️ Security

You can find several publicly accessible MagicMirror² instances.

This should never be done. Doing so makes your entire configuration, including secrets and API keys, publicly visible. Furthermore, it allows attackers to target the host; this is only prevented beginning with this release.

Public MagicMirror² instances should always run behind a reverse proxy with authentication.

[core]

• Prepare Release 2.36.0 (#4126)
• Allow HTTPFetcher to pass through 304 responses (#4120)
• fix(http-fetcher): fall back to reloadInterval after retries exhausted (#4113)
• config endpoint must handle functions in module configs (#4106)
• fix replaceSecretPlaceholder (#4104)
• restrict replaceSecretPlaceholder to cors with allowWhitelist (#4102)
• fix: prevent crash when config is undefined in socket handler (#4096)
• fix cors function for alpine linux (#4091)
• fix(cors): prevent SSRF via DNS rebinding (#4090)
• add option to disable or restrict cors endpoint (#4087)
• fix: prevent SSRF via /cors endpoint by blocking private/reserved IPs (#4084)
• chore: add permissions section to enforce pull-request rules workflow (#4079)
• update version for develop

[dependencies]

• update dependencies (#4124)
• chore: update dependencies (#4088)
• refactor: enable ESLint rule “no-unused-vars” and handle related issues (#4080)

[modules/newsfeed]

• fix(newsfeed): prevent duplicate parse error callback when using pipeline (#4083)

[modules/updatenotification]

• fix(updatenotification): harden git command execution + simplify checkUpdates (#4115)
• fix(tests): correct import path for git_helper module in updatenotification tests (#4078)

[modules/weather]

• fix(weather): use nearest openmeteo hourly data (#4123)
• fix(weather): avoid loading state after reconnect (#4121)
• weather: fix UV index display and add WeatherFlow precipitation (#4108)
• fix(weather): restore OpenWeatherMap v2.5 support (#4101)
• fix(weather): use stable instanceId to prevent duplicate fetchers (#4092)
• SMHI: migrate to SNOW1gv1 API (replace deprecated PMP3gv2) (#4082)

[testing]

• ci(actions): set explicit token permissions (#4114)
• fix(http_fetcher): use undici.fetch when dispatcher is present (#4097)
• ci(codeql): also scan develop branch on push and PR (#4086)
• refactor: replace implicit global config with explicit global.config (#4085)

@OliWer said:

Is this something that could be build into the default module?

we introduced Themes for this use case with the lastest mm release

@parnic

bullseye support ends in 5 month. But I don’t think we will remove the x11 start option because there are many other os which have no wayland support.

This is an electron option, wayland needs an extra param -ozone-platform=wayland. This is all defined in the package.json.

So as long as electron supports x11 I see no reason to remove the x11 option from mm.

With the new release we only switched to wayland as default option (when you use node --run start) because we think the majority is meanwhile using wayland.