@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.

Release Notes

Thanks to: @angeldeejay, @in-voker, @JHWelch, @khassel, @KristjanESPERANTO, @rejas, @sdetweil

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

Compare to previous Release v2.34.0

⚠️ We introduced some internal changes with this release, please read this forum post before upgrading!

[core]

• Prepare Release 2.35.0 (#4071)
• docs: add security policy and vulnerability reporting guidelines (#4069)
• refactor: simplify internal require() calls (#4056)
• allow environment variables in cors urls (#4033)
• fix cors proxy getting binary data (e.g. png, webp) (#4030)
• fix: correct secret redaction and optimize loadConfig (#4031)
• change loading config.js, allow variables in config.js and try to protect sensitive data (#4029)
• remove kioskmode (#4027)
• Add dark theme logo (#4026)
• move custom.css from css to config (#4020)
• move default modules from /modules/default to /defaultmodules (#4019)
• update node versions in workflows (#4018)
• [core] refactor: extract and centralize HTTP fetcher (#4016)
• fix systeminformation not displaying electron version (#4012)
• Update node-ical and support it’s rrule-temporal changes (#4010)
• Change default start scripts from X11 to Wayland (#4011)
• refactor: unify favicon for index.html and Electron (#4006)
• [core] run systeminformation in subprocess so the info is always displayed (#4002)
• set next release dev number (#4000)

[dependencies]

• update dependencies (#4068)
• update dependencies incl. electron to v41 (#4058)
• chore: upgrade ESLint to v10 and fix newly surfaced issues (#4057)
• chore: update ESLint and plugins, simplify config, apply new rules (#4052)
• chore: update dependencies + add exports, files, and sideEffects fields to package.json (#4040)
• [core] refactor: enable ESLint rule require-await and handle detected issues (#4038)
• Update node-ical and other deps (#4025)
• chore: update dependencies (#4021)
• chore(eslint): migrate from eslint-plugin-vitest to @vitest/eslint-plugin and run rules only on test files (#4014)
• Update deps as requested by dependabot (#4008)
• update Collaboration.md and dependencies (#4001)

[logging]

• refactor: further logger clean-up (#4050)
• Fix Node.js v25 logging prefix and modernize logger (#4049)

[modules/calendar]

• fix(calendar): make showEnd behavior more consistent across time formats (#4059)
• test(calendar): fix hardcoded date in event shape test (#4055)
• [calendar] refactor: delegate event expansion to node-ical’s expandRecurringEvent (#4047)
• calendar.js: remove useless hasCalendarURL function (#4028)
• fix(calendar): update to node-ical 0.23.1 and fix full-day recurrence lookup (#4013)
• fix(calendar): correct day-of-week for full-day recurring events across all timezones (#4004)

[modules/newsfeed]

• fix(newsfeed): fix full article view and add framing check (#4039)
• [newsfeed] refactor: migrate to centralized HTTPFetcher (#4023)

[modules/weather]

• fix(weather): fix openmeteo forecast stuck in the past (#4064)
• fix(weather): fix weathergov forecast day labels off by one (#4065)
• weather: fixes for templates (#4054)
• weather: add possibility to override njk’s and css (#4051)
• Use getDateString in openmeteo (#4046)
• [weather] refactor: migrate to server-side providers with centralized HTTPFetcher (#4032)
• [weather] feat: add Weather API Provider (#4036)

[testing]

• chore: remove obsolete Jest config and unit test global setup (#4044)
• replace template_spec test with config_variables test (#4034)
• refactor(clientonly): modernize code structure and add comprehensive tests (#4022)
• Switch to undici Agent for HTTPS requests (#4015)
• chore: migrate CI workflows to ubuntu-slim for faster startup times (#4007)

see https://github.com/MagicMirrorOrg/MagicMirror/releases/tag/v2.35.0

@sdetweil said:

the custom*.css files get moved

no, only css/custom.css and only if the target specified in config.customCss doesn’t exist.

This is the normal setup used by ~95% of the users, we cannot handle every edge case so these users must change it manually.

@BKeyport said:

I’m currently setting the CSS file with customCss: “css/custom3.css”, in the config,

I’ll change that to customCss: “config/custom3.css”, ?

in your setup no file is moved automatically. As you are already using the config.customCss feature you can do the changes before next release by

• move all the custom*.css file from css to config
• change config.customCss: "config/custom3.css"

@KristjanESPERANTO

I’m using https://globe.airplanes.live/ and they have a RainViewer Layer which still works when zooming in - maybe they use a license key …

Another approach I played with is using german dwd data (problem: germany only), tested this in my MMM-Flights module:

@smegbadger said in MMM-Universal-PIR - ‘GPIOcommand exited with error!':

It never occurred to me the container would update things unannounced!

the container does not update things on your host, but the container itself is running debian and (if you are using karsten13/magicmirror:latest) the debian version of the container image switched from bookworm to trixie …

see https://github.com/rainviewer/rainviewer-api-example?tab=readme-ov-file#personal-use-api-limitations

@KristjanESPERANTO

colorScheme seems to be useless too, the docs only mention 2 which is the default in the module, if I try other values there is no difference.

said in MMM-RAIN-MAP:

but since today, the two lowest of my four zoom levels seem to have stopped working

they are definitely gone …

I used for several years

        mapPositions: [
          { lat: ${LAT}, lng: ${LON}, zoom: 9, loops: 1 },
          { lat: ${LAT}, lng: ${LON}, zoom: 8, loops: 1 },
          { lat: ${LAT}, lng: ${LON}, zoom: 7, loops: 1 },
          { lat: ${LAT}, lng: ${LON}, zoom: 6, loops: 1 },
        ],

and now found in their docs Maximum zoom level is 7.

Another restriction is that there is no forecast anymore (as already stated in the module readme).

That’s a shame, it unfortunately devalues ​​the module.

@smegbadger

I had no idea about that, but now that you’re using Docker:

The gpiomon command is called inside the container (doesn’t work) and you call it for testing on the host (does work).

So I assume you have the newer version of gpiomon running in the container. So update the command in config.js to the new syntax described in the module README and try again (the new command will fail on the host but should work from inside the container).

@Stulli

you can set the mapUrl in the config:

var config = {
  modules: [
    {
      module: "MMM-Flights",
      position: "top_left",
      config: {
        laMin: 50.0,
        laMax: 50.21,
        loMin: 8.4,
        loMax: 8.8,
        mapUrl: "https://{a-d}.basemaps.cartocdn.com/light_all/{z}/{x}/{y}.png",
      },
    },
  ],
};

@Stulli

from the README:

As default map openstreetmap is used, other maps are possible, you find a list here.

You also can use maps from mapbox and create own maps with mapbox studio.

With mapbox you have to provide

• <username> (e.g. karsten13)
• <mapid> (e.g. cjp8vd7p807su2rqp8hc4dzoq)
• <accesstoken>

and set the mapUrl in config.js to https://api.mapbox.com/styles/v1/<username>/<mapid>/tiles/{z}/{x}/{y}?access_token=<accesstoken>.

@KristjanESPERANTO

The module is working for me, but since today, the two lowest of my four zoom levels seem to have stopped working (no change after updating).

I don’t see any 429 errors in the logs.

But let’s just wait and see; it might work again tomorrow…

@Klinge

from the module README.md:

Please test the used commands first outside of MagicMirror². If they not work from a terminal it makes no sense to use them inside this module.

So what is the output if you run gpiomon -r -b gpiochip0 17 on your machine?

And provide the version with gpiomon -v

@Mathes75

one thing (if not already done) would be a reboot and then again the prune command.

Otherwise start from scratch …

@Mathes75

really strange, the 1b1... is still there …

try docker system prune -f and check after this again docker ps -a

@Mathes75

show docker ps -a.

From the logs it looks like the strange container was deleted but I see no labwc container.

@Mathes75

looks like there is an old container but no idea why docker is unable to remove it.

You can try

cd /opt/mm/run
docker compose down
docker rm -f $(docker ps -aq)
docker compose up -d

@Mathes75

which script?

show content of “the script” and output of docker compose config

@sdetweil said in Having difficulty starting my mirror. I really need some help:

But it’s provided and is a ‘quick’ ‘win’ to get base up and running.

I’ve had another setup running for a while now, which solves some of the problems but of course also has its drawbacks.

It runs on Fedora with PM2. Why Fedora? Because I use bootc and therefore get automatic operating system updates. The downside is, of course, modules related to the Pi’s hardware, but the PIR sensor works.