Snilles Magic Mirror Project

[bolinoid]

Brilliant!

[nowayto]

@Snille I’ve logged in just to say… you are incredible!
That’s a very very great example of what a MM can do.
It’s just up to our minds!
Incredible, really.
I’m really interested about the IR touch system, I think I’m not enough professional to set it up but it’ really interesting.
I hope to have enough time in the future to learn/make one of this.
Thank you so much to have explain your project so well at the community

[Snille]

@nowayto Thank you! I’m glad to inspire!
If you have any questions, just write. :)

The mirror has It’s been in use in our family now for many years. Over time it’s been more and more integrated with my Home Assistant setup as well. It’s used for daily information such as news and weather. And of course, it’s been a big part of my daughters “Birthday Treasure Hunts” (check out last years hunt here). :)

I highly recommend to build one… It’s not until you built it you understand how much you need it. :)

[a7c12a5]

Hi @Snille just found Magic Mirror project online and I’m about to get started to build a family dashboard similar to https://forum.magicmirror.builders/topic/18011/touchscreen-family-dashboard but interested in your design of having profiles for the members of the family so I can change what is shown on the display.

I’m just getting started today to start the development. I’ll probably reach out with some questions.

If you have any suggestions on how I should do the initial setup and start my build let me know.

I’m probably going to use a monitor similar to the one from the link of the family dashboard ASUS 24" 1080P Multi-Touch Monitor (BE24ECSBT).

[Snille]

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-ProfileSwitcher is the only thing that sets visibility. Node-RED changes the profile instead of changing modules.

That means:

• MMM-ModuleScheduler is removed — its global_schedule, notification_schedule and module_schedule all moved into Node-RED
• defaultClass: "Photos", so the resting state is the slideshow
• includeEveryoneToDefault stays 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 timers removed, 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 my MMM-homeassistant-sensors instances — silently, for years. I tested module_05_MMM-Profilepicture against my mirror recently: 10 hits. If you address modules by number, check them.
• Module indices include disabled modules. Setting disabled: true does not renumber anything. Handy, but not obvious.
• The cron package 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 -dpms flag is not xset -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. everyone modules 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. 🙂