PIR / MQTT - Presence sensor(s) revived

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
                        }
                },

rkorell

@sdetweil Thanks.
I’ve excluded this file from git tracking so the pull should work.
Warm regards,
Ralf

rkorell

Dear @htilburgs,
it seems, we are in the same time-zone :-) wouldn’t be surpised even same mother-tongue …

Nevertheless, thank you for your patience and the detailed logs — they were extremely helpful in tracking this down.

What we found

The module works perfectly on my system (Pi 5, Debian Trixie, Wayland/labwc, MagicMirror 2.34.0), so we did an intensive
deep-dive comparing your setup, your MMM-Pir configuration, and your MMM-PresenceScreenControl configuration to understand why
the screen comes back after ~6 seconds on your system.

The key clue came from your own working MMM-Pir config:

mode: 3
waylandDisplayName: "wayland-0"

MMM-Pir mode 3 uses wlr-randr — the same tool you configured for MMM-PresenceScreenControl. But there’s a critical difference:
MMM-Pir internally sets WAYLAND_DISPLAY=wayland-0 (from your waylandDisplayName parameter) before calling wlr-randr.

Your MMM-PresenceScreenControl config, on the other hand, uses:

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

wlr-randr is a Wayland tool — it communicates with the Wayland compositor via the WAYLAND_DISPLAY environment variable.
DISPLAY=:0 is an X11 variable and is meaningless to wlr-randr. Without the correct WAYLAND_DISPLAY, wlr-randr falls back to
guessing the socket, which results in the unstable behavior you’re seeing: the screen turns off but comes back after ~6
seconds.

This also explains why your system info shows WAYLAND_DISPLAY: undefined — MagicMirror/Electron doesn’t have it set, so any
screen command executed from the module needs to provide it explicitly.

The fix

Replace DISPLAY=:0 with WAYLAND_DISPLAY=wayland-0 in your config. You have two options:

Option A: wlr-randr (matching your working MMM-Pir setup)

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

This is the minimal change — same tool, same parameters, just the correct environment variable.

Option B: wlopm (recommended, more robust)

wlopm is purpose-built for display power management on Wayland. Unlike wlr-randr --off (which removes the output from the
compositor layout), wlopm --off uses the Wayland power management protocol (DPMS-level) — it turns the display hardware off
without affecting window layout. This is what I use on my system.

First install it (it’s in the Trixie repos):

sudo apt install wlopm

Then configure:

onCommand: "wlopm --on HDMI-A-1",
offCommand: "wlopm --off HDMI-A-1",

Note: wlopm doesn’t need WAYLAND_DISPLAY explicitly — the default fallback to wayland-0 works reliably on Trixie. And since
wlopm controls hardware power state, it doesn’t need --mode or --transform on the on command — the display simply wakes up with
its previous settings intact.

For reference, the https://github.com/Jopyth/MMM-Remote-Control/blob/master/docs/guide/monitor-control.md documents wlr-randr
as the recommended Wayland screen control option, including the hint to set WAYLAND_DISPLAY if needed.

About the startup behavior (screen stays on)

You mentioned the screen stays on after MagicMirror starts until you trigger the PIR. The startup fix from commit 39d28d6 does
work — it turns the screen off ~1 second after startup. But since your offCommand wasn’t working correctly (the DISPLAY=:0
issue), the screen appeared to “stay on.” Once you fix the command, the screen should turn off shortly after startup if nobody
is in front of the PIR.

You also asked: “Why not the time from counterTimeout?” — That’s a fair point. On my system, counterTimeout is 600 (10
minutes), so turning off after 1 second is the desired behavior — I want to see that the restart worked, but not wait 10
minutes. For your setup with counterTimeout: 30, having 30 seconds of screen-on after startup would make more sense.

I’m planning a new config parameter startupGracePeriod that lets you define how long the screen stays on after module start
before the presence logic kicks in. This way each user can choose independently of their counterTimeout. I’ll include this in a
future release.

Upcoming improvement: cronMonitor efficiency

While investigating your issue, I discovered that the internal cron monitor (which checks for always-on/ignore time windows)
sends updates to the frontend every second, even when nothing has changed and the screen is off. This causes unnecessary DOM
rebuilds and is inefficient, though it’s not the cause of your screen-comes-back problem. I’ll fix this in the next release to
make the module quieter after screen-off.

About the debug logging

Now that we’ve identified the root cause, you can set debug: “off” in your config again. The debug output you saw (gpiomon
lines in pm2 logs) comes from the PIR library and goes to the console. The module’s own debug logging (updatePresence,
startCounter, updateScreen, etc.) intentionally writes to a separate log file (MMM-PresenceScreenControl_local.log in the
module directory) rather than to pm2 logs. This keeps the debug output focused and separated from the noise of all other
modules — much easier to analyze when troubleshooting a specific issue. If you ever need to debug the module again, check that
file instead of pm2 logs.

Summary

Screen comes back after 6 seconds: Replace DISPLAY=:0 with WAYLAND_DISPLAY=wayland-0 (Option A), or switch to wlopm (Option
B)
Screen stays on after startup: Should be fixed once Option A or B is applied. A startupGracePeriod parameter is planned for
a future release.
Log prefix [MMM-Pir]: Already fixed in your version ✓

Please let me know if Option A or B resolves the screen-comes-back issue!

Warm regards,
Ralf

htilburgs

@rkorell
I live in the Netherlands.

I’m Currently at the office, but I Will test it this evening and give you the results.

rkorell

@htilburgs :-) OK, nearby - Germany …
Thanks for testing/feedback!

Ralf

htilburgs

@rkorell
Oke, done some testing:
With the ‘new’ strings, I get:

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

[ERROR] [MMM-PresenceScreenControl] [updateScreen] ERROR: Error: Command failed: WAYLAND_DISPLAY=wayland-0 wlr-randr --output HDMI-A-1 --on --mode 1920x1080 --transform 270
unknown output HDMI-A-1

Why this message, I don’t know.
After a reboot this message didn’t show again.

Then I stopped MagicMirror and did the same command from the commandline WAYLAND_DISPLAY=wayland-0 wlr-randr --output HDMI-A-1 --off

After 6 seconds my display comes on again.
So it isn’t coming from MagicMirror, but from my system.
I created a simple Python3 script to turn off and on my monitor. Same problem.

Next step:
I took a new SD Card and installed a fresh copy of Trixie.
Didn’t do anything else, no updates or something else and tried again with WAYLAND_DISPLAY=wayland-0 wlr-randr --output HDMI-A-1 --off from the command prompt.
Display goes off and after 6 seconds back on again.
So I excluded MagicMirror. What else can it be?

Next step:
I took an other RPI4b with the new SD Card from previous step. Repeated the test, but still same result. Monitor goes on after 6 seconds. So it is not MagicMirror, not the RPI. But why it works with MMM-PIR and not with MMM-PresenceScreenControl. It is still a riddle for me.

Next step:
Original RPI with original SD Card and installed MMM-Universal-Pir. Same result, after 6 seconds screen on.
So I excluded MagicMirror, SD Card, Trixie installation and RPI. It must have something to do with my monitor?!?
Did something happen? Not that I know.

After doing a search on the big WWW, I found an interesting article that described exact the same issue I was having.
https://forums.raspberrypi.com/viewtopic.php?t=363966

So I searched for my RemoteControl and search for a setting
that automatically scan its input sources (not easy if your MagicMirror screen is rotated 270° ;-)
And I found this setting and indeed it was standing on auto scan. I put it on HDMI as only source and tried it again:

YES, IT IS WORKING!!!

And even better than before, now my monitor turns completly off after 15 min. of no signal. So instead of using 75W when on, 26W in standby, it now uses 0W after 15 minutes (it’s a setting on the monitor).
Activating the PIR, it turns back on!

So with this I hope that if somebody else has this problem, they can solve it to.

Ralf, thanks for all the help and trying to solve it with me.
I’m looking forward for the startupGracePeriod parameter and think this is going to make the module fully as I like it.
Thank you for your great work with this module and a grownup replacement for MMM-Pir!!!

rkorell

@htilburgs

YES, IT IS WORKING!!!

I’m SO happy.
Great news - congratulations…
So at least your stubborn issue leds to several code enhancements - during my investigation regarding your symptoms I had the chance to identify some optimization potential, so code is much cleaner now.
Thanks for this gentle “push”.

Warmest regards,
Ralf