@htilburgs sure. you’re right. Sorry.
I’ve removed package-lock.json from git-tracking and corrected the README.md installation instruction according your advise.
Instructions in postings above corrected as well.

Regards,
Ralf

MMM-PresenceScreenControl: gpiomon replaces native dependencies (PR #2)

I’m happy to share that @KristjanESPERANTO contributed a significant improvement to
MMM-PresenceScreenControl via https://github.com/rkorell/MMM-PresenceScreenControl/pull/2:

What changed:
The PIR sensor handling has been completely reworked. Instead of relying on node-libgpiod (a
native C addon requiring @electron/rebuild) with a Python/gpiozero fallback, the module now uses
gpiomon — a standard CLI tool that comes pre-installed with libgpiod on every Raspberry Pi.

What this means for you:

• No more native compilation during npm install
• No more @electron/rebuild or Python dependencies for PIR
• Works on both Bookworm and Trixie out of the box
• Automatic detection of libgpiod version (1.x / 2.x) and GPIO chip (Pi 4: gpiochip0, Pi 5:
  gpiochip4)

Additional fixes in the same update:

• Log spam eliminated: runtime log messages now respect the debug setting (“off” / “simple” /
  “complex”). With debug: “off” (default), pm2 logs stay clean. Thanks to @htilburgs for spotting
  this!
• Confusing [MMM-Pir] log prefix renamed to [PresenceScreenControl]

To update:

cd ~/MagicMirror/modules/MMM-PresenceScreenControl
rm -rf node_modules package-lock.json
git pull
npm install

BIG ! thanks to @KristjanESPERANTO for the clean refactoring and pointing out the log issues!

Warm regards,
Ralf

Dear @htilburgs,

Thanks for the detailed logs and config — very helpful!

Issue 1 — resolved as you found: wlr-randr instead of xrandr on Wayland. ✓

Issue 3 (confusing [MMM-Pir] prefix) — fixed in the latest commit. Log messages now show
[PresenceScreenControl] [PIR]. A git pull will get you this fix.

Issue 2 (screen stays on at startup): The counter showing 00:00 when nobody is in front of the
sensor is actually correct — no presence means the counter is expired.
The real question is: does your screen actually turn off? Your log shows the off-command executing successfully:
[updateScreen] SUCCESS: executed “DISPLAY=:0 wlr-randr --output HDMI-A-1 --off”
If the screen turns off but comes back on after ~10 seconds (as you describe in your second post),
that’s not our module turning it back on — the debug log shows no PIR_DETECTED event at that
moment. Please check if your Wayland compositor (Wayfire?) has its own idle/screen management:
look for an [idle] section in ~/.config/wayfire.ini. A dpms_timeout or similar setting would
re-enable the screen and override our wlr-randr --off.

Warmest regards,
Ralf

@sdetweil I’ve identified some of current modules (not MY modules) to use moment.js heavily.
Does it make sense to contact their developers proactively or even open an “issue” ?
From my mirror-build the impacted modules are: MMM-Strava, MMM-MyGarbage and MMM-NowPlayingOnSpotify …

With regards to planned weather module changes MMM-CalendarExt3Agenda relies on some weather information but this is handled by notification so it should work…

Warm regards,
Ralf

Dear Sam, @sdetweil

yes — my MMM-PresenceScreenControl module is one of those. It uses node-libgpiod (native C addon for GPIO/PIR sensor
access), which requires @electron/rebuild to match Electron’s Node ABI.

That said, the module has had an automatic fallback since v1.1.0: if node-libgpiod fails to compile or rebuild, it
transparently falls back to Python/gpiozero for PIR sensor access. So it will work without a successful
electron-rebuild — just via a different code path.

The dependency setup (as of v1.3.1):

• node-libgpiod is an optionalDependency (npm continues if it fails)
• @electron/rebuild is not listed as a dependency — it’s installed on-demand by the postinstall script only when
  node-libgpiod is actually present
• If either fails, the module falls back to Python gracefully

So for your testing: this module would be a good candidate to verify if electron-rebuild still works, but it won’t
break if it doesn’t.

My other modules (MMM-Globe, MMM-Best-Weather, MMM-My-Actual-Weather, etc.) are pure JavaScript — no native addons, no
electron-rebuild needed.

Hope this helps.
Warmest regards,
Ralf

Dear @htilburgs Thank you so much for flagging this — I genuinely appreciate it! I have to admit: on my own system, I
probably just watched the npm install output fly by and thought “yeah, whatever, it works” 😄

But you’re absolutely right that a clean install experience matters, so I looked into it properly.

The good news: v1.3.1 is now released and fixes everything. To update:

cd ~/MagicMirror/modules/MMM-PresenceScreenControl
git pull
rm -rf node_modules package-lock.json
npm install

You should now see 0 vulnerabilities and 0 deprecation warnings. The package count also dropped from 181 to 47 — quite
a diet! Details are in the updated
https://github.com/rkorell/MMM-PresenceScreenControl/blob/main/README.md#changelog.

What I changed:

• Removed @electron/rebuild from the pre-installed optional dependencies. It was dragging in a massive tree of build
  tools (tar, glob, rimraf, node-gyp…) that are never actually used at runtime. On Trixie, they weren’t even used at
  install time since node-libgpiod can’t compile there. The postinstall script already had on-demand logic for the rare
  case it’s needed — so listing it as a dependency was just unnecessary baggage.
• Upgraded mqtt from v4 to v5 (fully backwards-compatible, no config changes needed).

A word about those “vulnerabilities”: npm audit tends to be… let’s say enthusiastic about scaring people. Every
single one of those 8 vulnerabilities was either a build-time-only dependency (tar path traversal — relevant only when
extracting npm packages during install) or a theoretical ReDoS in minimatch (exploitable only if someone feeds
malicious glob patterns into a help-text lookup function). None of them could ever be triggered at runtime on a
MagicMirror sitting in your living room.

That said — seeing 8 vulnerabilities (6 high) in bright red after installing a module is not exactly
confidence-inspiring, even if the actual risk is zero. So I’m glad you pointed it out, and now the install is squeaky
clean.

Let me know if v1.3.1 works for you!

Thanks again and warm regards,
Ralf

@sdetweil YES, you are SO right!
Sorry!
so

{
			module: 'MMM-BackgroundSlideshow',
			position: 'fullscreen_below',
                        header: "", 	//<- this should work 
			config: {
  				imagePaths: ['/mnt/nas/'],
			recursiveSubDirectories: true,
			transitionImages: false,
  				randomizeImageOrder: true,
			showImageInfo:	true,				
			imageInfoLocation: "bottomRight",
			imageInfo: "date",
			showProgressBar: false,
			imageInfoNoFileExt: true,
			showAllImagesBeforeRestart: true,
			slideshowSpeed: 600000
				}
	},

should work…
Ralf

@mrchips83 said:

MMM-BackgroundSlideshow

Dear @mrchips83 ,
as far as I can see “PICTURE INFO” including the underline seems to be the standard module header.
You simply can get rid of it if you put a
header: “”,

in your modules config section.
so

{
			module: 'MMM-BackgroundSlideshow',
			position: 'fullscreen_below',
			config: {
  				imagePaths: ['/mnt/nas/'],
			recursiveSubDirectories: true,
			transitionImages: false,
  				randomizeImageOrder: true,
			showImageInfo:	true,				
			imageInfoLocation: "bottomRight",
			header: "", 	//<- this should work 
			imageInfo: "date",
			showProgressBar: false,
			imageInfoNoFileExt: true,
			showAllImagesBeforeRestart: true,
			slideshowSpeed: 600000
				}
	},

should do the trick.
I cannot contribute to eliminating the timstamp, sorry.

Warm regards, and good. luck,
Ralf

@plainbroke said:

Will that work in the USA ? I like the prettier styling…

Dear @plainbroke ,
well, I owe you an apology — and a thank you!

When you asked, I answered “wrong satellite” and moved on. Technically correct, but I completely missed the obvious next question: “So… can we get the
RIGHT satellite?”

Turns out, we can. The CIRA SLIDER service that provides the beautiful Meteosat GeoColor imagery (with the night city lights) serves four geostationary
satellites — and one of them is GOES-19, parked right over the Americas at 75.2°W. Same API, same image quality, same stunning day/night visualization.
I just never looked.

Your question made me look. So as of v3.1.0, MMM-Globe now supports:

┌─────────────────┬────────────────────┬───────────────────────────┐
│      Style      │     Satellite      │           View            │
├─────────────────┼────────────────────┼───────────────────────────┤
│ geoColorEurope  │ Meteosat (0°)      │ Europe / Africa           │
├─────────────────┼────────────────────┼───────────────────────────┤
│ geoColorUSA     │ GOES-19 (75.2°W)   │ Americas ← this is yours! │
├─────────────────┼────────────────────┼───────────────────────────┤
│ geoColorPacific │ GOES-18 (137.0°W)  │ Pacific                   │
├─────────────────┼────────────────────┼───────────────────────────┤
│ geoColorAsia    │ Himawari (140.7°E) │ Asia / Australia          │
└─────────────────┴────────────────────┴───────────────────────────┘

Just set style: “geoColorUSA” and you’re good to go. Same auto-polling every 60 seconds, same beautiful globe, just the right half of the planet this
time. 😊

So thank you for what I should have recognized as a feature request instead of a geography lesson. Sometimes the best contributions come disguised as
simple questions.

Warmest regards,
Ralf

Today added a minor fix: Globe disappeared when browser-refresh is performed…

Good afternoon!

today’s check of MMM-PresenceScreenControl shows me an issue posted by @icemanmw , which wasn’t on my radar but is an easy and useful addition.
Thanks for this idea.
I’ve added two additional parameters mqttUser and mqttPassword for those of you requiring additional authentification.

In Addition to this external trigger I had have some issues resolved :

While migrating my MagicMirror setup from Bookworm to Debian 13 (Trixie), I ran into a few things that required
changes to MMM-PresenceScreenControl. Since others might face the same issues, here’s a summary.

v1.1.0: GPIO fallback for Trixie + touch simplification

Trixie ships with libgpiod 2.x, which is a breaking API change from 1.x. The node-libgpiod npm package doesn’t work
with it (and also has issues with newer Electron versions). Rather than waiting for upstream fixes, the module now
auto-detects the situation and falls back to Python/gpiozero, which works perfectly on Trixie out of the box. No
configuration change needed — if you’re on Bookworm, nothing changes; if you’re on Trixie, it just works.

I also simplified the touch handling: the old touchMode parameter (0-3) is gone. Touch/click is now always active —
tap anywhere to wake up the display and reset the timer. Less config, same result.

v1.2.0: Removed VNC disconnect workaround

On older setups (X11), I had a double-click feature that would shut off the screen AND disconnect the VNC session to
avoid a “mini window” problem. Turns out this is no longer needed: wayvnc (0.9.1+) on Wayland/labwc natively manages
screen power through the wlr-output-power-management protocol. When you connect via VNC, the screen turns on. When you
disconnect, it goes back to whatever state it was in. Clean and simple — so I removed the workaround entirely.

Both updates are fully backwards-compatible. If you’re upgrading from v1.0.x, just pull the latest version. The only
thing to clean up in your config is removing touchMode and vncDisconnectCommand if you had them — but even if you
don’t, they’re simply ignored.

Have fun and a nice rest of the day.

Warmes regards,
Ralf

@plainbroke :-) It will work in US but you will see the wrong half of the globe …

To be serious: No, you requirement is for sure to see USA side of the globe - so it will not work for you - wrong satellite.

Warmest regards,
Ralf

Dear community,

just a heads-up for those of you using MMM-Globe with the europeDiscNat or europeDiscSnow
style — you’ve probably noticed that the satellite image has been stuck since around
February 22. Turns out EUMETSAT has pulled the plug on their old static image server at
eumetview.eumetsat.int. They moved to a shiny new platform at view.eumetsat.int, but
unfortunately it’s a JavaScript app now — no more simple image URLs we can point a module
at.

I’ve also opened an issue on the original repo for reference:
https://github.com/LukeSkywalker92/MMM-Globe/issues/22

I realize this probably flew under the radar for most of you — if your globe is pointed at
the Americas or Asia, everything’s fine. But for the small but proud club of European globe
watchers, it’s been a rough week staring at the same cloud pattern wondering if the weather
had simply stopped.

Since the original MMM-Globe hasn’t seen any updates in a while, I went ahead and created a
fork that adds a new “meteosat” style. It pulls Meteosat full-disk imagery from the CIRA
SLIDER service (run by NOAA/RAMMB at Colorado State University). The GeoColor product looks
really nice on the mirror — natural color during the day, and city lights on a Blue Marble
background at night. I think you’ll like it!

Big thanks to Luke Scheffler (@lukecodewalker) for creating MMM-Globe in
the first place — his idea of turning satellite images into a globe with a simple CSS circle
clip is just brilliant. This fork builds on his work.

If you want to give it a try:
cd ~/MagicMirror/modules
rm -rf MMM-Globe
git clone https://github.com/rkorell/MMM-Globe.git

Then change your config to:
{
module: “MMM-Globe”,
position: “lower_third”,
config: {
style: “meteosat”,
imageSize: 600,
updateInterval: 15 * 60 * 1000
}
},

The fork also fixes an annoying startup issue where the globe would stay blank after a
reboot if the network wasn’t ready yet — something that probably bugged a few of us running
this on a Raspberry Pi.

All the details, available styles and config options are in the README:
https://github.com/rkorell/MMM-Globe

Happy mirroring! 🪞

@KristjanESPERANTO Dear Kristijan,
just tested v4.2.4 — works perfectly! Restart via the Remote-Control UI now completes cleanly
under pm2, no orphaned Electron process, no port conflict. Exactly the behavior you’d expect.

I also noticed you added a dedicated handleRestart.test.js with 210 lines of unit tests covering
both the pm2 and standalone code paths — that’s really impressive and goes well beyond just a
quick fix. Having proper test coverage for this kind of dual-mode behavior is exactly the right
thing to do. Much appreciated!

Thanks for the incredibly fast turnaround and the quality of the fix. Consider this confirmed
working on:

• MagicMirror 2.34.0
• MMM-Remote-Control 4.2.4
• Node.js v22, Electron 39.5.2
• Raspberry Pi 5, Debian 13 (Trixie)
• pm2 with file-watch

Warmest regards,
Ralf

@KristjanESPERANTO Dear Kristijan,

after a long time I finally managed to see your “new” modul.
First of all: Thanks a lot for your effort, again - nice piece!

In the past few days I’ve completely rebuilt my mirror and migrated it to trixie as well as to the actual mirror and node versions.

I ran into a reproducible issue with the restart functionality when MagicMirror is managed by pm2 (which is the recommended setup per the official MagicMirror documentation).

The Problem

When triggering a restart via the Remote-Control UI (or the /api/restart endpoint), MagicMirror enters an endless crash-loop with EADDRINUSE: address already in use :::8080.

Root Cause
The handleRestart function in node_helper.js (lines 717-741) uses the Electron-native restart mechanism:

const {app} = require("electron");
app.relaunch();
app.quit();

This works fine in standalone mode, but creates a race condition with pm2:

1. app.relaunch() spawns a new Electron instance (child of the current process)
2. app.quit() terminates the current Electron instance
3. pm2 detects the termination as a crash and spawns another Electron instance
4. Now two Electron instances compete for port 8080 → EADDRINUSE → both crash → pm2 keeps restarting → infinite loop

The only way to recover is to manually identify and kill the orphaned Electron process, then trigger a clean restart via touch config.js (which pm2’s file-watch picks up).

Interestingly, the catch-block fallback for server mode (lines 726-739) already does it correctly — it calls process.exit(0) and lets the process manager handle the restart. The Electron code path just doesn’t account for the pm2 scenario.

Possible Fix

When running under pm2, the Electron-native app.relaunch() should be skipped entirely.

pm2 can be detected via environment variables like PM2_HOME, pm_id, or PM2_USAGE:

handleRestart (query, res) {
  try {
    const {app} = require("electron");
    if (!app) { throw "Could not get Electron app instance."; }

    // When running under pm2, don't use app.relaunch() — pm2 handles restart
    if (process.env.PM2_HOME || process.env.pm_id !== undefined) {
      Log.log("Running under pm2, exiting cleanly for process manager restart...");
      this.sendResponse(res, undefined, {action: "RESTART", info: "Exiting for pm2 restart..."});
      setTimeout(() => app.quit(), 1000);
      return;
    }

    this.sendResponse(res, undefined, {action: "RESTART", info: "Restarting Electron..."});
    app.relaunch();
    app.quit();
  } catch (error) {
    // ... existing server mode fallback ...
  }
}

Environment

• MagicMirror 2.34.0
• MMM-Remote-Control 4.2.2 (commit b854832)
• Node.js v22, Electron 39.5.2
• Raspberry Pi 5, Debian 13 (Trixie)
• Process manager: pm2 with file-watch on config.js

Workaround

For now, I’ve documented this for my setup: never use the restart button in Remote-Control. Monitor ON/OFF works fine, only the restart is
affected.

Thanks for considering this — happy to test any fix if needed!

Warmest regards,
Ralf

@sdetweil resolved in less than 24 hours :-) This is “responsive” !
Thanks again!
Ralf

@sdetweil OK; cool! Thanks again for all your effort!

Warmest regards,
Ralf

Dear Sam, @sdetweil ,

sorry for the late reply — time zones 😊 (it was night here in Germany when you posted).

To answer your question: the right branch is main.
That’s where mm_backup.sh pushes to
(git push -f origin main) , and that’s where backups should live.

The problem is that mm_restore.sh creates and checks out a “restore”-branch but never switches back (to main) or deletes “restore” afterwards. So after a restore, the local repo stays on restore-branch.

When mm_backup.sh runs next, it does git add and git commit — which goes to the currently checked-out branch (restore-branch), but then pushes main. So the new backup commit is “lost” on the wrong branch.

I think the simplest fix would be to add a git checkout main at the beginning of mm_backup.sh,
before any git operations. That way it always commits to the right branch regardless of what
happened before.

Alternatively, mm_restore.sh could clean up after itself by switching back to main and deleting
restore-branch when it’s done.

Thanks for looking into it!

Warmest regards,
Ralf

Dear Sam ( @sdetweil) ,

Hope you’re doing well! I’ve been using your MagicMirror backup-restore scripts for quite a while
now and they’ve been super helpful - thank you so much for maintaining them!

I just ran into a small issue that I wanted to share. At some point in the past, I had used
mm_restore.sh, which left my local backup repo on a branch called restore-branch. When I ran
mm_backup.sh today (after a loooong time) , it committed the backup to restore-branch (since that was
the checked-out branch), but the push command on line 511 explicitly pushes main:

git push -u origin main refs/tags/$next_tagnumber

So the tag got pushed correctly, but the actual backup commit never made it to main on GitHub -
because the commit was on restore-branch while the push targeted main (which still pointed to the
old commit).

Easy fix on my end - I just merged restore-branch into main and pushed. But you might want to add
a git checkout main (or git switch main) somewhere before the commit step in mm_backup.sh, so the
script always commits to the right branch regardless of which branch happens to be checked out.

Thanks again for all your work on this - and for all the help you are performing here for us!

Ralf

@wuermchen which fork are you using?
There was a newer implementation, I guess last year.
This version resolved the sticky caller-window (at least for me).

Good luck,
Regards,
Ralf