Big update: I let Home Assistant take over the mirror completely
It has been a while. This is the largest change I have made to the mirror since I moved off the Raspberry Pi, and since a lot of you here run Home Assistant too, I thought the whole story was worth writing down — including the part where I found out my mirror had been quietly burning a CPU core for years.
It started with a fan
The NUC was loud. Not “something is broken” loud, just always-working loud. I finally sat down to find out why, and the renderer process was sitting at 88% of a core, all day, every day.
The cause turned out to be wonderful:
Three MMM-Snow instances were running. In July. Invisible.
They are scheduled to appear on three days a year. The rest of the time they are hidden — and hidden in MagicMirror does not mean stopped. hide() sets opacity: 0, not display: none. Their 90 snowflakes kept animating, 180 infinite CSS animations, holding the page at a steady 60fps around the clock.
On its own that is cheap. The expensive part was that MMM-ImmichSlideShow had a fullscreen photo on screen, and that photo had to be re-rastered on every one of those 60 frames per second.
Two A/B tests confirmed it — hide the photo and CPU went 88% → 12%; pause the snow and it went 88% → 9%. Neither half was the problem. The combination was.
The bigger problem underneath
With the snow disabled, CPU dropped to ~41%. Better. But then I counted what was actually on screen:
16 modules visible at once. The complete wather profile, plus the Immich slideshow on top of it.
That is when I understood that four independent things were writing to the same visibility state, none of them aware of the others, none using MagicMirror’s locking:
| Controls | Triggered by | |
|---|---|---|
MMM-ModuleScheduler |
class groups | cron |
MMM-ProfileSwitcher |
the profile (exclusive) | CURRENT_PROFILE |
| Node-RED / HA | individual modules | presence, sensors |
MMM-Modulebar |
individual modules | touch |
Only ProfileSwitcher is exclusive — set_profile() walks every module and either shows or hides it. The other three only touch what they point at and leave the rest alone.
So my presence sensor showed the photo slideshow when nobody was there, but nothing ever told the other fifteen modules to go away. The globe kept spinning WebGL, the news feed kept scrolling, weather and electricity prices kept updating — all behind a picture nobody could see past.
The intent was right. The transport was wrong.
The fix: one owner
The rule I settled on is simple:
MMM-ProfileSwitcheris the only thing that sets visibility. Node-RED changes the profile instead of changing modules.
That means:
MMM-ModuleScheduleris removed — itsglobal_schedule,notification_scheduleandmodule_scheduleall moved into Node-REDdefaultClass: "Photos", so the resting state is the slideshowincludeEveryoneToDefaultstays off, so resting state is the photo alone — walk up, presence fires, the profile comes up and brings the button bars with it- ProfileSwitcher’s
timersremoved, so there is only one thing deciding when to go back
Now everything that is not part of the profile gets hide()d, and therefore suspend()ed.
The one CSS line everyone here should copy
This is the part I would have wanted to know years ago:
/* css/custom.css */
.module.hidden { content-visibility: hidden; }
Module.suspend() in the base class is an empty hook. If a module does not implement it — and most do not — it keeps running when hidden. content-visibility: hidden skips style, layout, paint and animation for the entire subtree, so a hidden module genuinely costs nothing.
The price is that a module disappears instantly instead of fading out. Worth it.
The missing piece: the profile as a real HA entity
Here is the thing that made it all click, and the reason this is worth a post rather than a footnote.
I use MMM-HomeAssistant (my fork of ambarusa’s), which publishes every module as an MQTT switch entity. Great — but there was no way for Home Assistant to see or set the profile.
So I added one. profileControl: true now publishes a select entity:
{
module: "MMM-HomeAssistant",
config: {
moduleControl: true,
profileControl: true,
profiles: ["Photos", "Night", "Work", "Weather", "Media", ...],
}
}
select.magic_mirror_hallway_profile
Selecting an option sends CURRENT_PROFILE — the same notification the on-screen buttons send. And the state is read back from ProfileSwitcher’s CHANGED_PROFILE notification, which it emits on every change including the one it makes at startup.
That last detail is what makes it genuinely useful: the entity always shows what the mirror is really displaying, even when someone pressed a button on the mirror itself. So Node-RED can tell its own command apart from a human, and hold a manual choice for 20 minutes before handing back to the schedule.
Without that feedback, an automation can only fire and hope — and it will happily fight the person standing in front of the mirror.
The profile names have to be listed in the config because Home Assistant validates against them, and there is no way to discover them: a profile is only ever a class name on some module.
What Node-RED looks like now
All of it lives on one tab. Two decisions, both edge-triggered — nothing is sent unless it differs from what the mirror reports:
1. Which profile? One function node, with the whole schedule as a table at the top. No cron strings, no month indices to get wrong:
const SCHEDULE = [
{ profile: "NewYear", date: "12-31", always: true, from: "23:45", to: "23:59" },
{ profile: "Halloween", date: "10-31", from: "05:55", to: "23:00" },
{ profile: "Work", days: [1,2,3,4,5], from: "08:00", to: "16:00" },
{ profile: "Weather", days: [1,2,3,4,5], from: "16:01", to: "20:29" },
{ profile: "Media", days: [0,1,2,3,4,5,6], from: "20:30", to: "23:00" },
];
Precedence: dark screen → night → always rows → a choice made at the mirror → nobody there → the table.
2. The overlays. MagicMirror profiles are single-axis; my mirror is not. Printer cameras, the Bird Buddy panels, the Halloween video and a birthday background all come and go on events, not on the profile.
Since set_profile() is exclusive it wipes them on every profile change. The solution needs no code: give them a class no profile uses, so they are always hidden by default, and have Node-RED re-assert them right after each profile change. Between changes it stays quiet — which is exactly what leaves MMM-Modulebar free to toggle things by hand.
“Always hidden by default” is the right way to be wrong: at worst something is missing for a second, instead of unwanted content flashing up.
Birthdays became a nice example. Instead of a whole Birthday profile that replaces whatever is up, it is now one overlay rule: swap the background picture, keep the profile.
Results
| Before | After | |
|---|---|---|
| Modules visible when idle | 16 | 1 |
| Renderer CPU | 41.3% | 12.4% |
| Xorg CPU | 18.6% | 0.1% |
| Things writing visibility | 4, unlocked | 1 |
| Profile visible in HA | no | a real entity, both directions |
(Those are after the snow was already dealt with. Counting that, the renderer went from 88% to 12%.)
The Xorg number is the one that tells the real story — 18.6% to 0.1% means the repainting actually stopped, rather than merely becoming invisible.
The mirror is also just nicer now. Empty hallway: one photo, nothing else. Walk up: the right profile appears with the buttons. Walk away: back to the photo. Screen off at night puts it on an empty profile so nothing renders at all until morning.
Things that bit me along the way
MMM-Remote-Control’s fuzzy module matching. If the exact identifier does not exist it falls back to matching module names, and runs the action on every hit. A wrong module number in my flow meant every Bird Buddy visit lit up all ten of myMMM-homeassistant-sensorsinstances — silently, for years. I testedmodule_05_MMM-Profilepictureagainst my mirror recently: 10 hits. If you address modules by number, check them.- Module indices include disabled modules. Setting
disabled: truedoes not renumber anything. Handy, but not obvious. - The
cronpackage changed month indexing from 0-11 to 1-12. My Halloween, New Year and birthday schedules had silently never fired — two of them threw “no execution date within 8 years” and were simply ignored. - Xorg’s
-dpmsflag is notxset -dpms. On the X server command line it removes the extension. My screen had not actually been turning off at all since the reinstall. - A profile can never be truly empty.
everyonemodules show in every profile except the default one. I use that on purpose now — the night profile keeps the two button bars, which cost nothing.
Would I recommend it?
If you run MagicMirror with Home Assistant and more than a handful of modules: yes, and the CSS line above regardless.
The mental shift is small but it changes everything — stop telling the mirror which modules to show, and start telling it which mode it is in. Everything else follows, and you stop being able to get into contradictory states at all.
Happy to share the Node-RED flow or the module config if anyone wants a starting point. Just ask. 🙂
