PIR / MQTT - Presence sensor(s) revived

rkorell

Dear MagicMirror-ians

As may already known I was a real fan of MMM-Pir.
For also good known reasons this nice module is not longer maintained.

I have a local clone which runs OK but in the meantime I had switched to MMM-MQTTScreenOnOff wich attaches a “better” (radar-) sensor to my mirror. But I’ve missed the progress bar, the dimming and cron-like functionality. In addition the radar sensor is much slower than PIR- caused by a 5 second update intervall as minimum.

After plenty of tinkering and testing, and above all torturing AI heavily I’m excited to announce: MMM-PresenceScreenControl is finally out! 🎉

This module brings together the best of both worlds:
• The beloved timer bar and auto-dimming from MMM-Pir,
• The reliability, MQTT support, and simplicity of MMM-MQTTScreenOnOff,
• All cleaned up, without unnecessary complexity, cryptic cron strings, or weird build tricks.

A few highlights:
• Presence detection with PIR, MQTT, or both (whichever triggers first wins)
• A visual timer bar so you always know how long the screen will stay on
• Straightforward “ignore” and newly introduced “always-on” time windows using plain times and days—no cryptic cron needed
• Customizable screen on/off commands—works on Pi, PC, X11, Wayland, CEC, and more
• Touch mode for remote or manual override (yes, you can poke your mirror awake remotely!)

If you’re after spinning circles or relay magic, this isn’t your thing (yet 😉). 
But if you want a solid, readable, and maintainable presence module that just works—even (hopefully) after updates—this is for you.

Give it a try, share your feedback, open pull requests, or ask questions right here or on GitHub:

Happy mirroring!

Ralf

Peter

@rkorell sadly it does not work: Pi 2b, bookworm, Pir only.
It says: Presence: no
It has worked for years with MMM-Pir on Bullseye.
Can you help please?
Peter

rkorell

Dear @Peter,

I can imagine that this is a restriction of your hardware.
I’m not THAT system specialist but as far as I remember there are some limitations regarding environment and software versions on Pi2b …
Because the “actuality” of used libgpiod this may doesn’t work on this specific hardware.

I can imagine Sam (@sdetweil ) can deliver a more precise statement on this.

On pi4/5 with “current” MM versions this works - and yesterday I got feedback regarding a successful installation.

Is there any log-entry which can be useful here?
Is the right GPIO configured for PIR?
Is the PIR sensor functional / calibrated?
Is power/ground connected to PIR?
Is power supply sufficient and working?

Regards,
Ralf

Peter

@rkorell
The Pir worked fine with MMM-Pir and Bullseye on the Pi 2b.
Fresh install with Bookworm: everything worked fine except the Pir.
That is why I tried your module.
Peter

advpolish

I’m not THAT system specialist but as far as I remember there are some limitations regarding environment and software versions on Pi2b -

rkorell

Dear @Peter,
Yes fully understood…
Without context - and may an answer regarding my questions - It‘s really hard to help.

Warmest regards,
Ralf

rkorell

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

htilburgs

@rkorell
When I install this module (currently using MMM-Pir) I got a lot of messages of deprecated modules. It also gives me 8 vulnerabilities (2 low, 6 high).

npm warn skipping integrity check for git dependency ssh://git@github.com/electron/node-gyp.git
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
npm warn deprecated @npmcli/move-file@2.0.1: This functionality has been moved to @npmcli/fs
npm warn deprecated rimraf@3.0.2: Rimraf versions prior to v4 are no longer supported
npm warn deprecated glob@8.1.0: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
npm warn deprecated glob@8.1.0: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
npm warn deprecated tar@6.2.1: Old versions of tar are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me

> MMM-PresenceScreenControl@1.3.0 postinstall
> ./postinstall

node-libgpiod not installed (optional), skipping electron-rebuild.
PIR sensor will use Python/gpiozero fallback.

added 181 packages, and audited 182 packages in 34s

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

8 vulnerabilities (2 low, 6 high)

To address issues that do not require attention, run:
  npm audit fix

To address all issues (including breaking changes), run:
  npm audit fix --force

Run `npm audit` for details.
pi@MagicMirror:~/MagicMirror/modules/MMM-PresenceScreenControl $

I’m running on a Pi 4b with Trixie.

rkorell

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

htilburgs

@rkorell said:

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

Better:

rm -f node_modelues package-lock.json
git pull
npm install

Otherwise the git pull wil not work.

Issue 1:
When time is up, the screen doesn’t go off. Dim works, but then when the screen should go off, it is not dimmed anymore and on. Debug says:

[2026-03-06 18:16:29.150] [LOG]   [MMM-PresenceScreenControl] [updatePresence] pirPresence=false, touchPresence=false, presence=true, newPresence=false 
[2026-03-06 18:17:30.311] [LOG]   [MMM-PresenceScreenControl] [startCounter] Counter expired: presence=false, pirPresence=false, calling updateScreen(false) 
[2026-03-06 18:17:30.323] [LOG]   [MMM-PresenceScreenControl] [updateScreen] on=false, cmd="DISPLAY=:0 xrandr --output HDMI-1 --off" 
[2026-03-06 18:17:30.467] [LOG]   [MMM-PresenceScreenControl] [updateScreen] SUCCESS: executed "DISPLAY=:0 xrandr --output HDMI-1 --off"

Issue 2:
When module is started, and there is no movement, the mirror stays on and counter says 00:00.
Until it see movement, than counter start and after the counter is should go out (not, see issue 1). Debug after just started:

[2026-03-06 18:20:32.007] [LOG]   [MMM-PresenceScreenControl] [startCounter] Counter expired: presence=false, pirPresence=false, calling updateScreen(false) 
[2026-03-06 18:20:32.012] [LOG]   [MMM-PresenceScreenControl] [updateScreen] on=false, cmd="DISPLAY=:0 xrandr --output HDMI-1 --off" 
[2026-03-06 18:20:32.132] [LOG]   [MMM-PresenceScreenControl] [updateScreen] SUCCESS: executed "DISPLAY=:0 xrandr --output HDMI-1 --off"

Current config (for testing):

{
                        module: "MMM-PresenceScreenControl",
                        position: "bottom_right",
                        disabled: false,
                        config: {
                                mode: "PIR",
                                pirGPIO: 17,
                                onCommand: "DISPLAY=:0 xrandr --output HDMI-1 --mode 1920x1200 --rotate left",
                                offCommand: "DISPLAY=:0 xrandr --output HDMI-1 --off",
                                counterTimeout: 30,
                                autoDimmer: false,
                                autoDimmerTimeout: 60,
                                style: 2,
                                colorFrom: "red",
                                colorTo: "lime",
                                colorCronActivation: "cornflowerblue",
                                showPresenceStatus: false,
                                debug: "on",
                                resetCountdownWidth: false
                        }
                },

Pi OS version:

PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
DEBIAN_VERSION_FULL=13.3

Mirror information:

- SYSTEM:   manufacturer: Raspberry Pi Foundation; model: Raspberry Pi 4 Model B Rev 1.4; virtual: false; MM: 2.34.0
- OS:       platform: linux; distro: Debian GNU/Linux; release: 13; arch: arm64; kernel: 6.12.62+rpt-rpi-v8
- VERSIONS: electron: 39.7.0; used node: 22.22.0; installed node: 22.21.1; npm: 10.9.4; pm2: 6.0.14
- ENV:      XDG_SESSION_TYPE: tty; MM_CONFIG_FILE: undefined
            WAYLAND_DISPLAY:  undefined; DISPLAY: :0; ELECTRON_ENABLE_GPU: undefined
- RAM:      total: 1845.58 MB; free: 972.54 MB; used: 873.04 MB
- OTHERS:   uptime: 5652 minutes; timeZone: Europe/Amsterdam

Node version:

v22.21.1

Currently I’m using MMM-Pir from Coernel82/MMM-Pir and this works fine. But because he doensn’t maintain this module, I thougt to go over.

I use these settings in this module:

mode: 3 - use wlr-randr (For raspbian 12 with wayfire compositor)
wrandrForceRotation: "270",
wrandrForceMode: null,
waylandDisplayName: "wayland-0",
Pir mode: 1,
gpio: 17,
triggerMode : "LH" - motion signal is triggered when sensor goes from LOW (0, no-motion) to HIGH (1, motion)

htilburgs

Ok, I made an error because of issue 1.
I used the xrandr instead of the wrandr command for Wayland.

Now Im using:

onCommand: "DISPLAY=:0 wlr-randr --output HDMI-A-1 --on --mode 1920x1080 --transform 270",
offCommand: "DISPLAY=:0 wlr-randr --output HDMI-A-1 --off",

The screen goes off after 30 sec (current counterTimeout), but after 10 seconds the screen goes on again, counter says 00:00 without that there was any movement. Also the debug doesn’t say noting. Until I create movement, than the counter starts at 00:30 and the screen goes off and after 10 sec. on. It looks like something triggers the software, to think there is movement.

Issue 2 still exists (it only applies when Mirror is first started).
After that it detects movement and it works fine.

Issue 3
When debug is on and MMM-PresenceScreenControl is started, I see a message from [MMM-Pir][LIB][PIR]. Very confusing because I first thougt I had my other module still running.

[2026-03-06 19:36:00.975] [LOG]   [MMM-PresenceScreenControl] [MMM-Pir] [LIB] [PIR] Mode 0 Selected (gpiod library) 
[2026-03-06 19:36:00.977] [LOG]   [MMM-PresenceScreenControl] [MMM-Pir] [LIB] [PIR] [GPIOD] node-libgpiod not available, falling back to Python/gpiozero (mode 1)

rkorell

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

rkorell

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

htilburgs

@rkorell
Hi Ralf, I don’t agree with your argument about Issue 2.
When my MagicMirror starts and it does not detect any movement, the screen will stay on and on until movement is detected. Let’s say I’m not around for 2 hours, the screen is on for 2 hours.

My other PIR modules I tested, do this as aspected (both MMM-Pir and MMM-Universal-Pir). So maybe you can consider to change this.

The other issue still exists after the update.
I don’t have a wayfire.ini file in my ~/.config.
My previous module MMM-Pir puts the screen off and at movement on. It stays off after it goes off.
With MMM-PresenceScreenControl my screen turns off and than after about 6-7 seconds, the screen comes back on again. I don’t make conclusions, but I think it has nothing to do with my system of Wayland settings. Something is triggering that the screen goes on again.

htilburgs

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

The better way is first rm -rf node_modules package-lock.json, otherwise git pull gives an error that it cannot update because of package-lock.json

error: Your local changes to the following files would be overwritten by merge: package-lock.json
Please commit your changes or stash them before you merge.

rkorell

@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

rkorell

Dear @htilburgs

You were right about the startup behavior — I’ve fixed it. The screen now turns off after ~1
second if no presence is detected at startup. No more waiting for the first sensor event.

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

Regarding the remaining issue (screen comes back on after 6-7 seconds): The debug log you shared
earlier shows the off command executing successfully, with no PIR event triggering the screen back
on. The module isn’t causing it — but I need to understand what is. Could you please set debug:
“complex” and share the complete log output from the moment the screen turns off until it comes
back on? That will show every internal state change.

Thanks for your testing and feedback — it’s making the module better for everyone.

Warm regards,
Ralf

htilburgs

@rkorell
First of all, thank you for your time!

You were right about the startup behavior — I’ve fixed it. The screen now turns off after ~1
second if no presence is detected at startup. No more waiting for the first sensor event.

Ok, nice. But why ~1 second?
Why not the time from counterTimeout?
Just my thoughts ;-)

Could you please set debug:
“complex” and share the complete log output from the moment the screen turns off until it comes
back on?

I will do this, but it will be tommorow.
I have to get up early and it’s already late.

sdetweil

@rkorell you could set a preinstall script in
package.json to erase the lock file

htilburgs

@rkorell
I did a git pull so I’m sure I’ve the latest version:

Screen stays on until I trigger the sensor, so that is not changed.
Screen goes off after 30 sec (my setting for testing) and after 6 seconds it comes on again, saying 00:00

I had set debug:“complex” and this is what it gave

[2026-03-09 06:53:11.320] [LOG]   [MMM-PresenceScreenControl] [PresenceScreenControl] [PIR] gpiomon output: 30488.576057914     rising  gpiochip0 17 "GPIO17" 
[2026-03-09 06:53:12.466] [LOG]   [MMM-PresenceScreenControl] [PresenceScreenControl] [PIR] gpiomon output: 30489.724051868     falling gpiochip0 17 "GPIO17" 
[2026-03-09 06:53:14.974] [LOG]   [MMM-PresenceScreenControl] [PresenceScreenControl] [PIR] gpiomon output: 30492.232041526     rising  gpiochip0 17 "GPIO17" 
[2026-03-09 06:53:16.122] [LOG]   [MMM-PresenceScreenControl] [PresenceScreenControl] [PIR] gpiomon output: 30493.380045941     falling gpiochip0 17 "GPIO17" 
[2026-03-09 06:55:15.350] [LOG]   [MMM-PresenceScreenControl] [PresenceScreenControl] [PIR] gpiomon output: 30612.608045172     rising  gpiochip0 17 "GPIO17" 
[2026-03-09 06:55:16.498] [LOG]   [MMM-PresenceScreenControl] [PresenceScreenControl] [PIR] gpiomon output: 30613.756051231     falling gpiochip0 17 "GPIO17"

I only have a message when I trigger the PIR, but further no messages. For being complete, my config:

{
                        module: "MMM-PresenceScreenControl",
                        position: "bottom_right",
                        disabled: false,
                        config: {
                                mode: "PIR",
                                pirGPIO: 17,
                                onCommand: "DISPLAY=:0 wlr-randr --output HDMI-A-1 --on --mode 1920x1080 --transform 270",
                                offCommand: "DISPLAY=:0 wlr-randr --output HDMI-A-1 --off",
                                counterTimeout: 30,
                                autoDimmer: false,
                                autoDimmerTimeout: 60,
                                style: 2,
                                colorFrom: "red",
                                colorTo: "lime",
                                colorCronActivation: "cornflowerblue",
                                showPresenceStatus: false,
                                debug: "complex",
                                resetCountdownWidth: false
                        }
                },