@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

@pat59 You may should remove your credentials from the urls ….

Regards,
Ralf

@sdetweil
OK; thanks for this hint.
May npm install has avoided the resulting error which I had to solve…

Anyway: Thanks a LOT!
Regards,
Ralf

@sdetweil
Yes :-)

In fact I’ve used

npm ci --omit=dev

this does the deletion of the node_modules folder inherently AFAIK …

Thanks again, dear Sam!

Ralf

@sdetweil
For some really strange reasons, neither

pi@MagicMirrorPi5:~/MagicMirror/modules/MMM-Remote-Control $ git fetch --all --tags
pi@MagicMirrorPi5:~/MagicMirror/modules/MMM-Remote-Control $ git fetch --tags

currently give any feedback…

So I’ve worked with the found git-hash:

git checkout 1f451ce

This at least worked and rolled back to V. 3.3.2.

Unfortunately some dependencies (package-lock.json ???) are not strict enough, so the rollback produces an error message:

[ERROR] Error when loading MMM-Remote-Control: require() of ES Module /home/pi/MagicMirror/modules/MMM-Remote-Control/node_modules/uuid/dist-node/index.js from /home/pi/MagicMirror/modules/MMM-Remote-Control/API/api.js not supported.

So I downgraded UUID:

cd ~/MagicMirror/modules/MMM-Remote-Control
npm install uuid@9.0.1
npm ci --omit=dev

With this module is running again.

From now on I’m in a in ‘detached HEAD’ state - but this seems OK.
Thanks for your time, effort and always great help!

Ralf

@sdetweil I’ve found V3.3.2 and just try "git checkout 1f451ce "

@sdetweil
BTW: Do you know if it is possible to restore the “old” version from remote-control?
May THIS is the better option for me?

@sdetweil
just ran a testrun of your upgrade script:

pi@MagicMirrorPi5:~/MagicMirror $ bash -c  "$(curl -sL https://raw.githubusercontent.com/sdetweil/MagicMirror_scripts/master/upgrade-script.sh)"
update log will be in /home/pi/MagicMirror/installers/upgrade.log

doing test run = true, NO updates will be applied!

Check current Node installation ...
Node currently installed. Checking version number.
Minimum Node version: v22.18.0
Installed Node version: v20.18.1
Node should be upgraded.
Node.js upgrade defered, doing test run
Check current NPM installation ...
NPM currently installed. Checking version number.
Minimum npm version: V10.9.2
Installed npm version: V10.8.2
npm should be upgraded.
npm upgrade defered, doing test run  ...

saving custom.css
reverting to master branch from _fix_clipping, saving changed files
would restore file modules/default/weather/current.njk before switch back to master branch
would restore file package-lock.json before switch back to master branch
would restore file package.json before switch back to master branch
error: Your local changes to the following files would be overwritten by checkout:
        package-lock.json
        package.json
Please commit your changes or stash them before you switch branches.
Aborting
unable to change back to master branch, stopping execution

What does the last message mean?
“unable to change back to master branch, stopping execution”
What have I to do?

@sdetweil
Good point!
Unfortunately I’ve already DONE the upgrade of remote-control - and now it doesn’t work anymore :-)

@sdetweil
Dear Sam,
thanks for this.

Until now I had avoided to upgrade with the thought “never touch a running system” …
Now it seems to be time for an upgrade - because I like MMM-Remote-Control.
@kristjanesperanto said: " at least node 22. I recommend version 24" - would one of these versions be installed by your current upgrade-script?

Than I would feel much better using your script than doing it manually …

As far as I remember i had some local (code) modifications in standard-weather module - this would prevent your upgrade-script from upgrading, as far as I remember.
Is this still true? And if yes: There was a “force” ooption in the script?

Thanks a lot for your work!

Warmest regards,
Ralf

@KristjanESPERANTO

OK…

New version now shows the same error…
Actually my mirror works pretty fine…
So I hesitate to update node …
What are the risks - and if: How do I do update node?

• Will my mirror run afterwards or do I have to upgrade the mirror as well?

Thanks for any advise!

Warmest regards,
Ralf

I’m not able to attach the logfile…
[2025-12-20T10_58_15_392Z-debug-0.log](Invalid file type. Allowed types are: .jpg, .jpeg, .png, .gif, .png, .jpg, .jpeg, .gif)

@KristjanESPERANTO Good Evening!
Nice work!
I like it but with this update it doesn’t work anymore (for me, at least).
I get an error message: “Cannot GET /remote.html”.

I first tried to update with

git pull
npm ci --omit=dev

This runs smooth, but results in the mentioned error message (mirror restarted :-) :

pi@MagicMirrorPi5:~/MagicMirror/modules/MMM-Remote-Control $ npm ci --omit=dev

> mmm-remote-control@4.0.1 postinstall
> node scripts/postinstall.js

modules.json already exists, skipping copy.

> mmm-remote-control@4.0.1 prepare
> simple-git-hooks || echo 'No problem. Skipping git hooks installation.'

sh: 1: simple-git-hooks: not found
No problem. Skipping git hooks installation.

added 38 packages, and audited 39 packages in 9s

4 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities

After this I’ve tried to do the manual installation via:

pi@MagicMirrorPi5:~/MagicMirror/modules/MMM-Remote-Control $ ~/MagicMirror/modules/MMM-Remote-Control/installer.sh

this at least showed an error:

Installation for the MagicMirror² Remote-Control module started!

Notice: This script and the installed software is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.

>>> Continue? [y/N]? y

Directory /home/pi/MagicMirror/modules/MMM-Remote-Control already exists.

You are currently on the master branch.

>>> Do you want to switch to the develop branch? [y/N]? N

>>> Do you want to update your branch? [Y/n]? Y

Pulling changes...
Already up to date.

Checking for new dependencies to install...


> mmm-remote-control@4.0.1 postinstall
> node scripts/postinstall.js

modules.json already exists, skipping copy.

> mmm-remote-control@4.0.1 prepare
> simple-git-hooks || echo 'No problem. Skipping git hooks installation.'

sh: 1: simple-git-hooks: not found
No problem. Skipping git hooks installation.

added 38 packages, and audited 39 packages in 3s

4 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
Done.

Update finished!
node:internal/modules/cjs/loader:1544
      throw err;
      ^

**Error [ERR_REQUIRE_ESM**]: require() of ES Module /home/pi/MagicMirror/modules/MMM-Remote-Control/node_modules/uuid/dist-node/index.js from /home/pi/MagicMirror/modules/MMM-Remote-Control/[eval] not supported.
Instead change the require of index.js in /home/pi/MagicMirror/modules/MMM-Remote-Control/[eval] to a dynamic import() which is available in all CommonJS modules.
    at [eval]:1:13
    at [eval]-wrapper:6:24 {
  code: 'ERR_REQUIRE_ESM'
}

Node.js v20.18.1

>>> Do you want to view instructions on how to configure the module? [Y/n]? n

You should also set an API key in your config section!
  It's dangerous to go alone! Take this.
  apiKey: ''
  I made it just for you.

Have fun with the module, if you have any problems, please search for help on github or in the forum:

   Github : https://github.com/Jopyth/MMM-Remote-Control
   Forum  : https://forum.magicmirror.builders

Do not forget to restart your MagicMirror² to activate the module! Installation finished.

So my third and last try was a complete fresh installation - but again with no luck - and the same error message, which I’m not able to handle:

pi@MagicMirrorPi5:~/MagicMirror/modules $ bash -c "$(curl -s https://raw.githubusercontent.com/Jopyth/MMM-Remote-Control/master/installer.sh)"

Installation for the MagicMirror² Remote-Control module started!

Notice: This script and the installed software is provided “as is”, without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the software or the use or other dealings in the software.

>>> Continue? [y/N]? y

MagicMirror² detected in: /home/pi/MagicMirror

>>> Is this correct and do you want to start installation? [y/N]? y

You can use either the master or the develop branch.
The develop branch contains more features, but is also more likely to cause errors or crashes.
This can be changed later by executing this script again, or using the git branch command.

By default the master branch will be installed.

>>> Do you want to install the develop branch instead? [y/N]? n

Cloning the repository on master branch...

Cloning into 'MMM-Remote-Control'...
remote: Enumerating objects: 2748, done.
remote: Counting objects: 100% (1098/1098), done.
remote: Compressing objects: 100% (317/317), done.
remote: Total 2748 (delta 866), reused 932 (delta 780), pack-reused 1650 (from 3)
Receiving objects: 100% (2748/2748), 2.50 MiB | 1.13 MiB/s, done.
Resolving deltas: 100% (1913/1913), done.

Installing dependencies...


> mmm-remote-control@4.0.1 postinstall
> node scripts/postinstall.js

Successfully created modules.json from template.

> mmm-remote-control@4.0.1 prepare
> simple-git-hooks || echo 'No problem. Skipping git hooks installation.'

sh: 1: simple-git-hooks: not found
No problem. Skipping git hooks installation.

added 38 packages, and audited 39 packages in 3s

4 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities
Done.

Installation finished.
node:internal/modules/cjs/loader:1544
      throw err;
      ^

**Error [ERR_REQUIRE_ESM]**: require() of ES Module /home/pi/MagicMirror/modules/MMM-Remote-Control/node_modules/uuid/dist-node/index.js from /home/pi/MagicMirror/modules/MMM-Remote-Control/[eval] not supported.
Instead change the require of index.js in /home/pi/MagicMirror/modules/MMM-Remote-Control/[eval] to a dynamic import() which is available in all CommonJS modules.
    at [eval]:1:13
    at [eval]-wrapper:6:24 {
  code: 'ERR_REQUIRE_ESM'
}

Node.js v20.18.1

>>> Do you want to view instructions on how to configure the module? [Y/n]? n

You should also set an API key in your config section!
  It's dangerous to go alone! Take this.
  apiKey: ''
  I made it just for you.

Have fun with the module, if you have any problems, please search for help on github or in the forum:

   Github : https://github.com/Jopyth/MMM-Remote-Control
   Forum  : https://forum.magicmirror.builders

Do not forget to restart your MagicMirror² to activate the module! Installation finished.

Do you please have a hint for me how to solve this?

MM is running on a Pi5 / NVME.

Thanks for any advice!

Warmest regards,
Ralf