MMM-Remote-Control

BKeyport

what’s with the microupdates? I’ve updated three times today. 🤣

S374n

4 updates today… :/ Kind of annoying to see the mirror changes the view with this notification.
anyway:

GUI looks better. Thanks!
First update changes my main.css - took me a while to figure it out and redo all my customizations.
Restart - doesn’t work. Shutdown i didn’t even try.
Restart Magicmirror2 - doesn’t work, says mm2 is not running.
Turn monitor on/off doesn’t work.
Minimize browser does it but then no way to revert. So point less, now need to reboot.

Any way to make it SSH from the phone? :)

rkorell

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

sdetweil

@rkorell to upgrade node use one of the tools

nvm or n

I prefer n
stop MagicMirror if running

sudo npm install n -g
sudo n 22.18
hash -r
node -v

Should confirm node is upgraded

Now we need to fix the MagicMirror dependencies

cd ~/MagicMirror 
rm -rf node_modules
npm install

Then start MagicMirror

In the future, if you want to upgrade MagicMirror, use my upgrade script and it will also upgrade node if necessary

sdetweil

@rkorell you can only upload pics here, you can paste some of the log into a message ( use the code block )

rkorell

@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

sdetweil

@rkorell force was if you already had started installing MM and had the latest code… NOT if you have code changes

the upgrade will report if files are changed and allow you to save them in git. but generally its intended to remind you where you made changes and do something about it…

the node upgrade should not impact the running MM… (I say that with ’ quote marks, cause I am not sure…)

WHY do you NEED the RemoteControl update?? if you don’t NEED it, then don’t take it…

sdetweil

@rkorell said in MMM-Remote-Control:

would one of these versions be installed by your current upgrade-scrip

today it will install node 22.18.0
after Jan 1 (2 weeks away) it will install 22.21.1 (for the next release)

rkorell

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

rkorell

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

rkorell

@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

@rkorell can you tell me when old was? luckily this module uses tags for releases, so you could restore to one of the previous releases…

in the module folder do

git fetch --all --tags

then when we figure out which release to try, we can

git checkout <tag_name>

Release 3.2.1 was about 5 months ago.

rkorell

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

sdetweil

@rkorell if you pull the tags, you can use the tag name

git checkout v3.3.2

rkorell

@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

@rkorell I was just about to add that you needed to redo the npm install for the module after deleting the node_modules folder
else you were trying to run the new dependencies with the old code

but you fixed it…

rkorell

@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

@rkorell said in MMM-Remote-Control:

npm ci

be careful… the package.json was built and tested on a cloud based virtual machine.
pi and other hardware types MAY need a different version of a dependency, i’ve only seen it myself twice in 6 years, but

npm ci uses the exact package.json
npm install will get the appropriate for this platform, even if the version changes.

anyhow… I use npm install --omit=dev when I do the installs script or MMM-Config

rkorell

@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

KristjanESPERANTO

Thanks for the feedback!

Since Sam has already addressed some of the issues, I won’t go into them again.

A few problems were mentioned, some of which I have just addressed with v4.1.0. E.g.:

Restart/Shutdown: Should now also work on systems without PM2.
Minimize: Now says “restart to restore” so you know how to undo it.

About the monitor control issue:

This would be tricky to get running by default everywhere because every system uses different commands (X11/Wayland/etc). You have to check the Monitor Control docs and configure the right commands for your specific setup - the defaults won’t work everywhere.

About the “npm install/npm ci” topic:

Yes, npm ci can be problematic for modules with native dependencies that need platform-specific builds. However, MMM-Remote-Control only uses pure JavaScript dependencies (marked, qrcode, simple-git, swagger-ui-dist, uuid) - no native modules that require compilation.

For this module, npm ci is actually the better choice because:

Guarantees exact tested versions which the developers released
Faster installation (no dependency resolution)
Same behavior in CI and production
No change on the package-lock.json

So the warning about npm ci is valid in general, but doesn’t apply here.

About the microupdates. Since the test suite does not a lot parts yet, some details simply go unnoticed after major changes. If you are not experiencing any problems with the module, you do not need to install every update.

About node update: I recommend using nvm for node updates. This is also what is offered as default for Linux on the official download page. This makes many things easier - like if something does not work after an update, you can easily switch back to the previous node version. So you don’t need to be so afraid of updates.