A New Chapter for MagicMirror: The Community Takes the Lead
Read the statement by Michael Teeuw here.

Categories

  • Announcements regarding the MagicMirror software and forum.

    67 Topics
    428 Posts
    rejasR
    Release Notes Thanks to: @angeldeejay, @egeekial, @khassel, @KristjanESPERANTO, @MikeBishop, @rejas ⚠️ This release needs nodejs version >=22.22.2 <23 || >=24 (no change to previous release) (update July 6) Compare to previous Release v2.36.0 [core] Prepare Release 2.37.0 (#4193) fix(electron): map IPv6 :: wildcard to localhost (#4188) refactor(main): modernize DOM update flow with async/await (#4186) refactor(main): simplify _updateDom with async/await (#4185) fix(security): prevent unauthorized secret expansion in socket payloads (#4184) refactor(main): simplify updateDomWithContent async flow (#4182) fix: modules losing data after HTTP 304 responses (#4180) chore: add missing core defaults (#4181) fix(server): enforce ipWhitelist for Socket.IO too (#4169) feat(systeminfo): include Git hash and branch in system information log (#4167) feat(electron): support object-based electronSwitches (#4161) systeminformation thread not ending: move error handling from utils to app (#4160) fix systeminformation thread not ending (#4155) refactor: use ES module imports in browser core (#4158) refactor(core): remove old Object.assign polyfill (#4157) refactor: rewrite Module as an ES6 class (#4151) refactor: rewrite NodeHelper as an ES6 class (#4147) update eletron to v42 (#4144) refactor(utils): drop ajv dependency (#4142) fix(systeminformation): output right ‘used node’ version (from parent process) (#4141) fix: skip postinstall git clean when not in a git repository (#4139) Remove unnecessary conditionals and fix falsy property check in imperial conversion (#4135) update version in package.json [dependencies] update dependencies (#4191) Bump actions/checkout from 6 to 7 (#4190) chore: update dependencies and adjust import path for SunCalc (#4189) update dependencies incl. electron and revert yauzl-electron-install-fix (#4183) update dependencies, add electron fix in package.json (#4175) chore: update dependencies (#4162) Bump actions/dependency-review-action from 4 to 5 (#4152) Unify linting: replace Stylelint and markdownlint with ESLint (#4148) update dependencies and workflows to node v26 (#4140) [modules/alert] CodeQL cleanup for alerts #18, #19, #20 (#4153) fix: resolve CodeQL alerts #24 and #26 (#4145) fix(electron): resolve CodeQL alerts #22 and #25 in electron.js (#4136) [modules/calendar] perf(calendar): pre-filter ICS data before parsing (#4168) perf(calendar): use async ICS parsing to avoid blocking event loop (#4143) [modules/newsfeed] [newsfeed] add allowBasicHtmlTags option for basic emphasis (#4176) [modules/updatenotification] fix(updatenotification): don’t spawn a child process when running under PM2 (#4166) fix(updatenotification): use process.argv[0] as restart binary (#4163) fix(updatenotification): preserve start mode on restart (#4156) fix(updatenotification): fix ref diff parsing for fetch --dry-run (#4138) refactor(updatenotification): replace pm2 usage with node logic (#4134) [modules/weather] feat(weather): add Buienradar provider (#4164) [testing] remove warning in unit tests (for nodejs >= v25) (#4149) polish HTTP 304 docs/test/handling (#4129)
  • Discuss the MagicMirror² core framework.

    495 Topics
    4k Posts
    B
    MMM Config already seems to cover most of the proposed workflow without forcing every module author to adopt a new schema. The automatic discovery plus optional custom form definitions sounds like a practical balance between compatibility and structured configuration.
  • Anything harware related can be found here.

    799 Topics
    7k Posts
    F
    I just found brigla-shop.de, they aren’t that expensive, I guess I will try them.
  • Add exciting new features to your mirror.

    6k Topics
    59k Posts
    J
    super basic question, both modules are from the same developer, but both are missing the most basic info of how to install. in instances like this how do I find the first bit of info to put in terminal to start pulling down the info needed for a module? Cheers.
  • Make your mirror your own but modifying its appearance.

    434 Topics
    3k Posts
    S
    @Jk1 said: I needed this to set the header color yes, I thought you were talking about text color, not background…
  • Share your project story with pictures.

    578 Topics
    5k Posts
    SnilleS
    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. 🙂
  • You have a problem with your mirror? Ask for help.

    5k Topics
    36k Posts
    KristjanESPERANTOK
    Thanks for sharing your experience! As Node.js and Electron evolve, their hardware requirements increase over time, and older or less powerful devices may eventually struggle. Staying on older versions is unfortunately not a sustainable solution because of missing security fixes, bug fixes and new features.
  • A place to talk about whatever you want.

    1k Topics
    10k Posts
    S
    @Tigershroffr interesting but you missed one critical point. The vast majority of ‘developers’ did this for themselves as their first and only module. With no intention of keeping it up. They shared it to be nice to others And have now moved on to other projects @kristjanesperanto has worked w many module owners to become a maintainer.