@bwente You gave me a great idea.
I decided o create a a tiny “launcher” page for switching between multiple displays on one kiosk device. A TV in my study.
I wanted the same Android TV to also show a security camera dashboard (Frigate NVR on my home network), not just MagicMirror. The kiosk browser only points at one URL at a time. Rather than build a full app switcher, I just added a tiny extra route to the small reverse-proxy Node server I already had running for the MM display one page, two big buttons:
!
The two buttons just link out to http://192.168.0.16:8088 (MM-Docker) and http://192.168.x.x:5000 (Frigate NVR)
Point the kiosk browser’s start URL at 192.168.x.x:8080/launcher(MM- with Physical Monitor) instead of either destination directly, no JavaScript needed for the actual navigation, and they’re natively D-pad-focusable on a TV, so the remote just moves focus between them and select jumps straight there (the green focus ring makes the current selection obvious from across the room).
One thing worth flagging for anyone doing the same on an Android TV specifically: not every “kiosk browser” app renders a page like this correctly. I initially used one built more for single-photo slideshow display, and it auto-detected and fullscreened the first video element it found instead of showing the actual page layout, fine for MagicMirror (mostly text/widgets) but broke a multi-camera grid dashboard that uses video tags for live streaming. Swapping to a proper general-purpose kiosk browser (Fully Kiosk Browser) fixed it, worth checking that whatever app you use actually renders full webpages as-is, not just “the most interesting-looking media on the page.”
Thank you @bwente for the idea.

Sharing a setup that’s been working well for me, in case it’s useful to anyone else juggling a physical MM display on aging/fragile hardware.
Background: I had MagicMirror running natively on a Raspberry Pi 3B with a monitor attached. I wanted to move to Docker, but didn’t want to run Docker on the same Pi that’s driving the display, that Pi is old, and I didn’t want display/GPU quirks tangled up with container management.

What I ended up with instead:

• MagicMirror runs as a single Docker container on a separate, more capable Pi on the same home network , completely headless, no monitor attached.
• The Pi with the physical monitor doesn’t run MagicMirror at all anymore. It just runs a browser in kiosk mode, pointed at a small local reverse-proxy process running on that same Pi, which in turn proxies through to the Docker container’s web UI.
  Why the proxy, instead of just pointing the browser straight at containerhost:8080?
  Two reasons:

1. MagicMirror sends X-Frame-Options: SAMEORIGIN, which matters if you want to wrap the feed in your own page (see #2).
2. I wanted a couple of small custom status overlays on the display itself — e.g. a banner if the Docker host becomes unreachable, or if internet connectivity drops but the local container is still fine. To overlay anything on top of MM’s own page you need it loaded same-origin, so a tiny local Node reverse-proxy on the display Pi re-serves the container’s content from localhost, strips that header, and the wrapper page around it handles the status banners.
   Why this arrangement, generally:

One MagicMirror instance/config to maintain, no matter how many physical screens you eventually want — each display Pi is just “a browser + a small proxy,” nothing module- or backend-specific.
Any hardware-specific pain (GPU driver quirks, monitor power management, etc.) on the display Pi stays isolated from the actual MagicMirror process, a crash or leak in a module’s backend logic can’t take the display down, since they’re not sharing a process tree anymore.

Honest caveat: this doesn’t make the display Pi itself lighter, it’s still a real browser doing real DOM/JS rendering and image decoding locally, so don’t expect a resource-usage miracle on the display side. What you get is architectural: single source of truth for MM itself, and a much smaller, simpler thing running on whatever hardware is stuck driving a screen
I’m pairing this with a Radar motion sensor for wake-on-motion, poll a GPIO pin and call dpms_control on on a HIGH reading, dpms_control off after N minutes of no motion. One thing worth knowing if you’re doing the same: Trixie’s kernel exposes the GPIO chip at a different base offset than older Raspberry Pi OS versions, so older libraries like onoff that write raw BCM pin numbers straight to sysfs (/sys/class/gpio/export) fail with EINVAL. Shelling out to gpioget/gpiomon from libgpiod-tools instead sidesteps that entirely:

I’ve just published MMM-SolarGenerationCalendar, a MagicMirror² module that displays a live solar generation dashboard by bridging directly with Home Assistant. No API keys or internet dependency required. Since I have a Soliscloud integration this module is tailored for that. However, you need to have integrated your Solar Plant with the relevant HA integration( Which requires, API Key & Secret). It features a live power gauge, six stat cards (Power, Today, Month, Peak, Year, Lifetime), a today’s generation curve, and a 30-day bar chart with a daily average line, all pulled from HA’s REST and WebSocket APIs. If you are using any other Solar Integration, you can still use this module. Check out the FAQ’s. for how to do that.
Checkout the Module at;
github.com/CyberRagz/MMM-SolarGenerationCalendar

Thanks to the observation from @KristjanESPERANTO, I have updated the code avoided Axios completely and used the native Fetch. And while I was at it I also added the HomeAssistant integration.
Checkout the latest update;
https://github.com/CyberRagz/magicmirror-mcp

@rkorell That is so encouraging.

@KristjanESPERANTO said:

Why are you using an very old version of axios instead of build-in fetch?

You have given me food for thought. There’s no good reason. Axios 1.6.0 is not ancient, but it’s still an unnecessary dependency for what this client does. Many TypeScript libraries were originally written for Node 14/16 environments, so Axios became the default. The repo requires node >= 18, and Node 18 ships with the native fetch API built in. Every single method in client.ts is a simple GET or POST with JSON , exactly what fetch handles natively without any extra package. The only real reason to reach for axios in a Node 18+ project today is if you need interceptors for complex auth flows, automatic retry logic, or upload progress events .
Axios was chosen for convenience and historical compatibility. However, for a modern Node.js TypeScript MCP server, native fetch is cleaner and preferable. For this project switching to native fetch seems logical. Axios adds more value in complex APIs, but here the benefit is minimal. So i guess, i need to strip it . Thanks, I will try and update ASAP.

A Model Context Protocol (MCP) server for controlling MagicMirror² via the MMM-Remote-Control API.
My first milestone in automating MagicMirror using the AI assistants. (With Help from AI Programming Tools.)
This lets AI assistants like Claude interact with your smart mirror showing/hiding modules, sending alerts, toggling the display, restarting the mirror, and more. The possibilities are endless, just requires ingenuity.
Check it Out Here :
https://github.com/Ragziesoft/magicmirror-mcp

MMM-HollywoodMovies
A simple but beautiful MagicMirror² module that displays upcoming Hollywood movie releases — complete with poster thumbnails, release dates, and lead cast — powered by the free TMDB API. Fully configurable.

Features

🎬 Displays up to 5 upcoming Hollywood movies releasing in the next 6 months
🖼️ Movie poster thumbnails via TMDB image CDN
📅 Formatted release dates
🎭 Top 3 lead actors per film
🔄 Auto-refreshes every 6 hours
⚡ Retry logic with timeout handling for reliable operation on Raspberry Pi
Check it out here;
https://github.com/Ragziesoft/MMM-HollywoodMovie

@sdetweil I agree. Just to make a point I used AI to rewrite .css code for some of the modules to enhance the UI display on the screen. I achieved the Glass Morphism display characteristics, which is the latest in IOS

@sdetweil Amazing. My current setup has MagicMirror and Homeassistant running on the home network. The integrations between the two is like a Portal has opened up between the future and the past. It is almost like the AI (Alien) visits the past and resolves issues, I guess it is time for the community to harness the power of AI (Cautiously of course) and make MagicMirror a truly user friendly project which can benefit the people who have no tech/ coding background , and would need something that repairs itself when broke.

AI Coding Tools Infuse a New Life in MagicMirror

But before that; a word of caution, PLEASE, Please know what you are doing, take backups.

Over the past few months, I decided to revisit my MagicMirror setup, and the transformation has been substantial. What was once a stable but slowly evolving dashboard has now become a far more dynamic, optimized, and feature-rich system, largely due to the practical use of modern AI coding tools. Previously, extending or modifying MagicMirror modules required significant time for debugging, documentation review, and iterative testing. While that process was valuable, it often slowed experimentation. With AI-assisted development, I was able to accelerate module customization, refactor legacy configurations, improve styling consistency, and resolve dependency conflicts far more efficiently. Some of the key improvements included:

• Refactoring older custom modules for cleaner, maintainable code
• Optimizing API integrations for faster data refresh cycles
• Improving CSS layout responsiveness and visual structure
• Enhancing module intercommunication logic
• Automating repetitive configuration adjustments
• Generating code for new Modules, customised to my requirements and setup
• Tight integration with Homeassistant
  AI tools proved especially effective when troubleshooting obscure npm issues, adjusting Node.js compatibility problems, and restructuring asynchronous logic. Instead of spending hours isolating minor errors, I could focus on architectural improvements and feature expansion.
  The result is a significantly more responsive, visually refined, and modular MagicMirror installation—essentially a complete recharge of the system without starting from scratch.
  AI coding tools are not a replacement for understanding the underlying architecture, but they are undeniably powerful accelerators. For anyone maintaining or expanding a MagicMirror instance, integrating AI into the workflow can dramatically reduce friction and unlock creative possibilities.
  It has effectively given my MagicMirror a second life. I am currently using, Claude Desktop with Sonnet 4.6, Openclaw, AgentZero . All these provide direct integration with MagicMirror and modify code and configurations directly.
  FInally remember PLEASE be careful and know what you are doing.

@sdetweil Thank you for the info. However, I finally successfully migrated to Trixie with desired Monitor Resolution and Rotation. And i am using Raspberry Pi 3B+ with an Acer 27 Inch monitor.
With Trixie being launched only three weeks back, there is almost no solutions avaiable. I will shortly share my process of how it was achieved.
Thanks

I took the plunge. My five year old MagicMirror ground to a halt as far as Display resolution, Rotation and DIsplay control are concerned. Everything was working great on my Raspberry Pi 3B+. An unfortunate rpi-update broke everything. I struggled to restore Bullseye, and it was a shock to realise it is not easy to find the right official image.
I then tried Bookworm, the three issues continued to remain unsolved.
I then decided to install Trixie. Most of the transition of MM was smooth, ofcourse with a few hicks, but getting the display resolution and rotation was the most frustrating part.
I got it working finally. I have restored the Display resolution and the rotation succesfully.
I will shortly upload the entire process which was not only exhausting but of great learning value.
I need to recover the GPIO Notification Module which isnt working and resulting Motion control of monitor using RCWL0516.

@schlomm Thnaks, but i wanted the Bulleseye, OS 32 Bit (for Pi 3B+) full desktop version.

To resolve major issues with Display and rotation and also screen On Off control I am forced to flash the older Bullseye version. I searched high and low, but the " Official Bullseye OS 32 Bit for Raspberry Pi 3B" is almost impossible to find. It has been removed from the Raspberry Pi website, even the archives do not seem to have the correct file. Some shady mirror site do list it but i am aprehensive. I dont know what i am missing. Any help in locating the verified OS from a reliable source.
Thanks

@schlomm ## I just thoght of uploading the Summary of Attempts - All Failed. It is really getting frustrating. My Monitor was working perfectly well the desired rotation and resolution 1080x1960, and now is stuck at 1024x768.

1. config.txt modifications:**

• Custom hdmi_timings for 1920x1080
• Various hdmi_mode settings (82, 87)
• hdmi_ignore_edid=0xa5000080
• Different boost levels and drive settings
• Result: Monitor only shows up to 1024x768 max

2. cmdline.txt kernel parameters:**

• video=HDMI-A-1:1920x1080@60D
• Various video= parameter combinations
• Result: No effect on available resolutions

3. Custom EDID firmware:**

• Created multiple EDID files (256 bytes, 268 bytes, 285 bytes)
• Placed in /lib/firmware/edid/ and /boot/firmware/edid/
• Used drm.edid_firmware=HDMI-A-1:edid/1920x1080.bin
• Rebuilt initramfs to include EDID early
• Result: Kernel loads file but rejects it as “Invalid firmware EDID”

4. Wayland/X11 rotation scripts:**

• wlr-randr (Wayland) - can’t set non-existent 1920x1080 mode
• xrandr (X11) - output name issues
• Result: Can only work with available modes (max 1024x768)

Core Problem:

• Acer HA270 monitor provides NO EDID data** to the Pi
• Bookworm OS + Labwc Wayland compositor won’t accept forced resolutions
• Same monitor worked with Pi 3B + Bullseye (older firmware stack)
• Raspberry Pi detects only: 1024x768, 800x600, 848x480, 640x480

Current Status:

Stuck at 1024x768 rotated = 768x1024 instead of desired 1080x1920. Wonder if we the Rpi OS team is aware f this issue.

@sdetweil Thanks for tryin for a solution. The mirror was oriented in portrait mode, and now the display is landscape and that too low resolution. All my modules displays are messed up and it is a very sorry sight. I had to switch off the mirror… In the last 5 years this is the first time i have had to go through such a major issue.
Is there a way to set the resolution in the config.js ? But i guess the OS and hardware will prevent any software configuration settings.
Can you suggest any other resolution?
Thanks

@rkorell I have tried all changes and variations with config.txt and cmdline.txt, none are working. I am now stuck at a lower resolution screen and no rotation. Any solutions?

@sdetweil So is there a solution for this issue? Request advice. Thanks

@sdetweil Sorry missed your msg.
Issue is: I am unable to set the resolution of 1080x1920 (Portrait orientation) for my MagicMirror. None of the configurations settings in config.txt relating to dtoverlay have resolved the issue. In fact it is causing my monitor to go blank with no picture. Only mode works is ; 1024x768
and Landscape.
I even reflashed OS to Bookworm , i had Bullseye earlier. The monitor on/off control is breaking because probably the HDMi output is not being detected.
OS & HARDWARE INFO ;
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm
Linux magicmirror 6.12.47+rpt-rpi-v7 #1 SMP Raspbian 1:6.12.47-1+rpt1~bookworm (2025-09-16) armv7l GNU/Linux
NODE / NPM / PM2 / MAGICMIRROR INFO ;
v20.19.1
10.8.2
6.0.13

Installed MagicMirror npm packages:
magicmirror@2.24.0 /home/pi/MagicMirror
├── @electron/rebuild@3.7.2
├── colors@1.4.0
├── console-stamp@3.1.2
├── digest-fetch@2.0.3
├── electron@25.9.8
├── envsub@4.1.0
├── epoll@4.0.2
├── eslint-config-prettier@8.10.2
├── eslint-plugin-import@2.32.0
├── eslint-plugin-jest@27.9.0
├── eslint-plugin-jsdoc@46.10.1
├── eslint-plugin-prettier@4.2.5
├── eslint@8.57.1
├── express-basic-auth@1.2.1
├── express-ipfilter@1.3.2
├── express@4.21.2
├── feedme@2.0.2
├── helmet@7.2.0
├── husky@8.0.3
├── iconv-lite@0.6.3