@andrenajolly - most interesting is: what length is “full length” ?
From this it depends for sure how to build the frame and how to choose right glass (kind of glass, thickness) …

Kind regards,
Ralf

@plainbroke you’re really welcome.
Thanks for your patience :-)

Ralf

@sdetweil Take your time!
Family is most important.
This issue is REALLY not important, neither urgent.
I do not need this module right now - was just for testing, if I can help @Cr4z33 further with some examples to copy - as asked.

So don’t hurry.

Ralf

@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

@schlomm Yes I had samples from them.

In the end I‘ve decided to use the monitor in a nice ancient picture frame without any glass.
So the „mirror“ effect is missing but this fits my usecase better.
The frame is mounted in our living room and I can see all of the information from every place in the room…

Warmest regards,
Ralf

@olex.s @sdetweil , dear all,

As you know for sure I‘m really a fan of MMM-Pir - for (my) good reasons.
For a friend of mine I‘ve build a second mirror and because he is heavily engaged in smarten his home :-) I‘ve considered to use alternatives to a PIR sensor - because they are definitely unsmart…
With this I‘ve seeked for an integration for his homee solution which is not really capable for MQTT and randomly found a really cool device which I would like to share with you, guys!
This is not a „motion“ sensor but a real „presence“ sensor (radar based, not infrared) which even is able to identify a silently sitting person!
In addition this genius thingy talks MQTT, delivers the „presence“ status in a JSON object and so it is absolutely easy to use it with magic mirror and the herein presented module MQTTScreenOnOff.

This sensor is pretty expensive and invented and build by a small startup here in Germany 🇩🇪 .
You can find this sensor here.
The webpage is in German but for some reason the default UI is in English :-)
From my perspective this is defnitely worth the money (this is the fourth radar sensor I‘ve bought but the first one which is in the near of „working“)

The mqttTopic transmitted is: „tele/senvolon/STATE“ and the mqttPayloadOccupancyField is „presence“.
(The middle part is configurable in the sensor‘s UI, I‘ve decided to use vendor‘s name).

I REALLY miss the nice animation and the dimming of MMM-Pir but I‘m definitely thinking about to use this sensor as well.
(Which would be a major effort because my Mirror has an exact slot for the PIR sensor which is round and this sensor is squared so I will have to do some rough wood-work. On the other hand I MAY place the sensor away from the mirror on the opposite wall or in an other place and hide the hole from PIR sensor ….)

Nice MQTT module - thanks for this idea!

Warmest regards,
Ralf

@cricket said in MMM-Moon module - how to resize?:

It appears there is no size option in the module itself. I

I’ve had the same issue not with size but with alignment and had resolved this within the middle-center region and have used:

.region.middle.center {
  width: 45%;
 
}

in custom.css.

This works for me to position the moon nicely above earth in my implementation.

Regards,
Ralf

@mediahypno
I guess to get both - easyness and cheapness is not possible…

As far as I have seen pictures around and read several comments here in this forum I got the impression that best result will be with glass - this is kind of expensive.

The cheaper version with Acrylic is not that “brilliant” and there are may some restrictions in the viewing angle.

The least expensive so cheapest version is the foil - this is the far most complicated one because you have to apply the foil on some kind of Acrylic or glass which often fails due to bubbles, scratches, dust or whatever.

I definitely wanted to go for glass.

In the meantime I have decided to build up a “Magic Signage” not a mirror.
This is caused by the fact that the already build up prototype is present since several weeks in our living room and we visit this beauty several times a day.
So the final version will stay nearby - at least in the living room and a mirror at this place doesn’t make any sense to us.
(initially planned was to replace the mirror in the hallway but this becomes obsolete for the above reasons)

HTH,
Regards,
Ralf

@OliWer

Absolutely fine for me. Just a hint - as improvement path for further upcoming modules from your side :-)

Warm regards,
Ralf

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

@sdetweil said in Fontawsome symbol usage for calendar help requested.:

https://docs.magicmirror.builders/modules/calendar.html#configuration-options

Thanks!
Warm regards,
Ralf

@sdetweil , @BKeyport :
In the meantime a GeeekPi Ultra Thin ICE Tower Cooler is arrived and just installed.
Fan is bigger than Pi - looks weird.

After 20 minutes temperature is at 52°C nothing to hear.
Keep you posted…

Thanks for your feedback so far!

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

Don‘t forget to go to the target module directory before installing!

cd MMM-Tronity

Ralf

@BKeyport OK, thanks for your viewpoint!
Than I‘m on the right way - still works today :-)
Temperature was 45°C today in the morning - was at 56° everytime before …
So even passive cooling seems to be much better.

Nice rest of weekeend to all of you.
Ralf

I’ve just seen that you had invented a solution for your problem - MMM-HideModulesOnSpotify :-)
Cool!

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

Dear @schlomm ,
I initially had no clue at all regarding root cause :-)
And the finding “undervoltage” was never expected but came out off my logfiles.

After a LOT of tinkering and playing with syptomatic “solutions” system kept to be unstable so I decided to dig in and do some logging to identify root cause.

For this I wrote a shellscript and installed a system service which collects this data every five minutes.

shellscript:

sudo nano /usr/local/bin/wlan-diagnose.sh

content:

#!/bin/bash
LOGFILE="/var/log/wlan-diagnose.log"
DATE=$(date '+%a %d %b %H:%M:%S %Z %Y')
WLAN_IF="wlan0"

echo "===== $DATE =====" >> $LOGFILE

# IP-Adresse
echo "--- IP-Adresse ---" >> $LOGFILE
ip addr show $WLAN_IF >> $LOGFILE 2>&1

# Link-Status
echo "--- Link Status ---" >> $LOGFILE
iw dev $WLAN_IF link >> $LOGFILE 2>&1

# Default Route
echo "--- Routing ---" >> $LOGFILE
ip route >> $LOGFILE 2>&1

# Wpa_supplicant Status
echo "--- wpa_supplicant ---" >> $LOGFILE
systemctl status wpa_supplicant --no-pager >> $LOGFILE 2>&1

# Letzte wpa_supplicant Logs
echo "--- wpa_supplicant journal (letzte 20 Zeilen) ---" >> $LOGFILE
journalctl -u wpa_supplicant -n 20 --no-pager >> $LOGFILE 2>&1

# Kernel/Treiber Logs
echo "--- dmesg wlan0 ---" >> $LOGFILE
dmesg | tail -n 20 >> $LOGFILE 2>&1

# Ping-Test
PING_TARGET="8.8.8.8"
ping -I $WLAN_IF -c3 -W3 $PING_TARGET >> $LOGFILE 2>&1

echo "" >> $LOGFILE

set as executable:

sudo chmod +x /usr/local/bin/wlan-diagnose.sh

systemd-timer for this diagnosis script:

sudo nano /etc/systemd/system/wlan-diagnose.timer

content:

[Unit]
Description=WLAN Diagnose alle 5 Minuten

[Timer]
OnBootSec=1min
OnUnitActiveSec=5min
Persistent=true

[Install]
WantedBy=timers.target

service file:

sudo nano /etc/systemd/system/wlan-diagnose.service

content:

[Unit]
Description=WLAN Diagnose Service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/wlan-diagnose.sh

activate the service:

sudo systemctl daemon-reload
sudo systemctl enable --now wlan-diagnose.timer

Created logfile: /var/log/wlan-diagnose.log

possible command for filtering for errors:

grep -i "fail\|error\|disconnect" /var/log/wlan-diagnose.log

in my personal case directly after starting the service the undervoltage warnings appeared in the logfile:

Sep 24 19:23:02 MagicMirrorPi5 wpa_supplicant[702]: wlan0: CTRL-EVENT-CONNECTED - Connection to f8:bc:0e:51:50:48 completed [id=0 id_str=] Sep 24 19:23:02 MagicMirrorPi5 wpa_supplicant[702]: bgscan simple: Failed to enable signal strength monitoring --- dmesg wlan0 --- [ 385.672898] hwmon hwmon4: Voltage normalised [ 399.780700] hwmon hwmon4: Undervoltage detected! [ 401.796721] hwmon hwmon4: Voltage normalised [ 403.812728] hwmon hwmon4: Undervoltage detected! [ 405.831888] hwmon hwmon4: Voltage normalised [ 425.988994] hwmon hwmon4: Undervoltage detected! [ 428.008109] hwmon hwmon4: Voltage normalised [ 434.052979] hwmon hwmon4: Undervoltage detected! [ 438.087587] hwmon hwmon4: Voltage normalised [ 442.117090] hwmon hwmon4: Undervoltage detected! [ 444.133104] hwmon hwmon4: Voltage normalised [ 452.198182] hwmon hwmon4: Undervoltage detected! [ 454.213171] hwmon hwmon4: Voltage normalised [ 470.341318] hwmon hwmon4: Undervoltage detected! [ 478.405369] hwmon hwmon4: Voltage normalised [ 488.485467] hwmon hwmon4: Undervoltage detected! [ 490.505469] hwmon hwmon4: Voltage normalised [ 514.693689] hwmon hwmon4: Undervoltage detected! [ 516.709733] hwmon hwmon4: Voltage normalised [ 520.744884] hwmon hwmon4: Undervoltage detected! PING 8.8.8.8 (8.8.8.8) from 172.23.56.157 wlan0: 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=13.2 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=33.6 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=116 time=27.5 ms --- 8.8.8.8 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 13.220/24.756/33.576/8.529 ms

So I had identified my root cause with first strike.

In the meantime (today) I had severe additional problems (also “identified” by this mentioned log) - but this was a kernel/device driver problem which I cannot solve today.
But this leads to a modified recovery script because the version from yesterday only tried to restart the WPA_Supplicant which was not sufficient for my problem today.

[EDIT - Sep, 8th, 2025: deleted old recovery script because usage of ping without qualified path produced an error by the script itself. For this reason the script is not as useful as I thought. Sorry for confusion! ]

Hope this helps you.
Do not hesitate to ask for further information …

Warmest regards,
Ralf

@sdetweil OK, have pulled update and disabled debug options again.
Keep you posted.
THANKS for your effort!

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