Best posts made by rkorell

rkorell

trixie: gpiomon -e rising -c 0 23

You could try Karsten‘s suggestion…
Replace your configs gpioCommand with the suggested one and check what happens…
As I had assumed in my earlier post it‘s may related more to gpio than to HDMI …

Regards,
Ralf

rkorell

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

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

rkorell

Dear all,

I have been chasing a runaway Electron disk cache on my Mirror (Pi 5, MM 2.34.0) and added what I thought was the obvious fix to my config.js:

electronSwitches: ["disk-cache-size", "104857600"],   // 100 MB

Some months later the cache had grown to 2 GB (260,000+ files in ~/.config/Electron/Cache/Cache_Data/).
My limit appeared to be ignored entirely.

When I looked at js/electron.js line 47 I think I see why, but I want to sanity-check this with the community — maybe I am simply misreading the code.

The line is:

app.commandLine.appendSwitch(...new Set(electronSwitchesDefaults, config.electronSwitches));

As far as I understand it, two things are happening here:

new Set(a, b) silently drops the second argument.

The Set constructor signature is new Set([iterable]) — it accepts exactly one iterable. Any further arguments are ignored. So I believe this is equivalent to:

new Set(electronSwitchesDefaults)

and config.electronSwitches never makes it in.
Is that right?
Or am I missing some clever JavaScript I have not seen before?

appendSwitch only takes one switch per call.

The Electron docs state the signature is appendSwitch(switch, value?). Spreading a flat array of multiple switches into a single call should — if I understand correctly — only honour the first switch/value pair and silently discard the rest.

The defaults array ([“autoplay-policy”, “no-user-gesture-required”]) happens to be exactly one switch with one value, so that one works. But anything a user adds via config.electronSwitches would never take effect, even if point 1 were fixed.

If both readings are correct, the natural fix would be a loop, something like:

const switches = [["autoplay-policy", "no-user-gesture-required"], ...(config.electronSwitches || [])];
switches.forEach(([s, v]) => app.commandLine.appendSwitch(s, v));

or, if electronSwitches is documented as a flat array, the user-facing schema would need to be specified more clearly first.

My questions to the forum:

Is my reading of new Set(a, b) correct here?
Has anyone successfully used electronSwitches to actually change Electron behaviour, and if so, with what syntax?
Is this maybe legacy code that the community has worked around in other ways I am not aware of?

Thanks,
Ralf

rkorell

@costascontis , If I got you right, this seems to be a web page. So i can imagine, this could be a candidate for MMM-SmartWebDisplay.

Check it out.
Good luck!
Ralf

rkorell

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

Ralf

rkorell

@sdetweil , @kristjanesperanto ,
I’ve decided to resolve it by myself - with Sam’s hint/advice/helper-file.
It seems to work - will double check my cache size in a few days.

Thanks again for your great support.
Migration is a bigger task and wihout any need currently too much - even cache-growth wouldn’t change this.

never touch a running system :-)

Warm regards,
Ralf

rkorell

Good evening to all.
Today was an interesting day - caused by an issue posted by Stefano ( papinist )

He opened issue # 10 . with a friendly, well-argued suggestion: expose the mirror screen to Home Assistant as a proper switch — something you can both see (is the screen on?) and control (turn it on/off) as a native HA entity.

The nice realisation while designing it was that this needs almost nothing new. PSC already speaks MQTT — it already subscribes to a presence topic so that MQTT occupancy sensors can drive the screen. So Home Assistant is simply another presence source, exactly like a radar or mmWave sensor publishing occupancy. The only piece genuinely missing was the reverse direction: a topic the mirror writes, carrying its own screen state. No extra module, no shell scripts, no IPC — just publish one more thing and let HA subscribe to it.

The design

The result is an optional homeAssistant config block. Enable it and PSC opens a dedicated MQTT connection (independent of mode, so it works even in pure PIR setups), reusing the broker and credentials you already configured:

homeAssistant: {
  enabled: false,                  // opt-in, default off → no surprise
  discovery: true,                 // publish the HA auto-discovery config
  discoveryPrefix: "homeassistant",// must match your HA MQTT discovery prefix
  objectId: "magicmirror_screen",  // technical id → topic paths + HA unique_id
  name: "MagicMirror Screen"       // friendly name shown in HA
}

A few decisions worth flagging, because each is a small opinion:

It’s a switch, not a button — so ON latches. ON sets a held presence signal: the screen stays on for as long as the switch is on. OFF releases it, and the mirror returns to standby through your normal counterTimeout — the same graceful countdown a PIR walk-away uses. There’s deliberately no separate “instant off”; if you want a snappy off, lower counterTimeout.

It never reaches into the module’s own logic. The integration adds exactly one OR-term to the presence evaluation — haPresence alongside the existing PIR / MQTT / touch sources — and it sits below the cron windows in precedence. The scheduler still wins: an ON during a cronIgnoreWindows is swallowed, an OFF during a cronAlwaysOnWindows is overridden. Timer, dimming and window logic are untouched.

The switch is a strict mirror of the real screen. The state topic always publishes the actual screen state, whatever caused the change — PIR, schedule, touch or HA — and it re-publishes after every command. So when the schedule rejects or overrides a command, the switch snaps back to reality rather than lying: HA can never show “on” while the screen is off, or vice versa. A command is a request; the fact is whatever the mirror actually does.

Auto-discovery + availability, so setup is effortless. On connect PSC publishes a retained Home Assistant MQTT-Discovery config and an availability topic backed by a Last-Will. HA creates the entity automatically and marks it unavailable if the mirror drops off the broker.

The topics, all derived from objectId:

homeassistant/switch/magicmirror_screen/config   (retained)  → discovery
magicmirror/magicmirror_screen/set                           → command  (HA → mirror: ON/OFF)
magicmirror/magicmirror_screen/state             (retained)  → state     (mirror → HA: ON/OFF)
magicmirror/magicmirror_screen/availability      (retained)  → online/offline (LWT)

How the auto-creation works

The mirror and Home Assistant never talk to each other directly — the broker is the only meeting point, and the discoveryPrefix (homeassistant) is the agreed channel. HA’s MQTT integration subscribes to homeassistant/# and listens for anyone announcing themselves there. Because our config is published retained, the broker hands it to HA the instant HA connects — even if HA boots hours later. HA reads the topic path plus the JSON body and builds switch.magicmirror_screen, wired to the command/state/availability topics. It’s the same mechanism Tasmota, Zigbee2MQTT and ESPHome use — the mirror just follows the convention, so it’s picked up like any other device.

An example automation (doorbell → wake → graceful standby)

automation:
  - alias: "Doorbell wakes the MagicMirror"
    trigger:
      - platform: state
        entity_id: binary_sensor.video_doorbell
        to: "on"
    action:
      - service: switch.turn_on
        target: { entity_id: switch.magicmirror_screen }
      - delay: "00:00:30"        # keep the camera visible while you look
      - service: switch.turn_off
        target: { entity_id: switch.magicmirror_screen }

Turn it on when the doorbell rings, keep it visible for half a minute, then hand back to PSC’s timer for the standby — or drop the delay/off and turn it off from another trigger, whatever fits your flow.

A note on testing

I don’t run Home Assistant here, so I verified the whole MQTT surface with MQTT Explorer playing HA’s role — publishing ON/OFF to the command topic and watching the discovery, state and availability topics. The entire round-trip is observable that way: ON holds, OFF starts the countdown, the state tracks the real screen (including snapping back when the schedule overrides a command), the discovery config is well-formed, availability goes online on start. The one thing that needs a real instance — does HA actually auto-create the entity from that config — is being confirmed by papinist, who has the setup for it.

Update / install

If you’re already on the module:

cd ~/MagicMirror/modules/MMM-PresenceScreenControl
git pull

No dependency changes this time, so no npm install is needed — just restart MagicMirror. Everything is backwards-compatible and opt-in: homeAssistant.enabled defaults to false, and the rest is additive, so an update touches nothing in your existing setup until you switch it on.

A genuine thank-you to papinist for the friendly, well-reasoned suggestion and the pleasantconversation that shaped it. Exactly the kind of exchange that makes maintaining a module worthwhile.

Hope you find it useful.

Warmest regards,
Ralf

rkorell

@thartley
The text size of the newsfeed description is controlled via the global CSS class .small which the template assigns to the element.
Defined in ~/MagicMirror/css/main.css:

.small { font-size: var(--font-size-small); }

If I see it right::

default/newsfeed/newsfeed.css does not contain a font-size for the description — only list and layout rules.
The description-specific class .newsfeed-desc does exist, but it does not set a font size.

If you want to change the description size independently of other .small elements , the cleanest approach would be an override in css/custom.css:

.newsfeed  .newsfeed-desc { font-size: your_desired_font_size_as_number)

(do not alter the global .small).

HTH.
Warm regards,
Ralf

rkorell

@papinist Thanks, dear Stefano for your confirmation!

in addition Stefano introduced another idea which pumps addional value to the module.
Following Stefano’s idea the module now announces the raw PIR-Motion data as well as the presence-information to MQTT Broker - so HA is able to trigger additinal actions (e.g. switching a light on) .

Happy mirroring!