<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Recently Active Topics]]></title><description><![CDATA[A list of topics that have been active within the past 24 hours]]></description><link>https://forum.magicmirror.builders/recent</link><generator>RSS for Node</generator><lastBuildDate>Wed, 20 May 2026 01:17:30 GMT</lastBuildDate><atom:link href="https://forum.magicmirror.builders/recent.rss" rel="self" type="application/rss+xml"/><pubDate>Tue, 19 May 2026 20:00:51 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[MMM-Bambulink: MagicMirror Module for Bambu Lab Printers]]></title><description><![CDATA[@TAGinside edit the wiki on the MagicMirror GitHub page to add your module to the appropriate section and the next day it will appear in the searchable list here
https://modules.magicmirror.builders/
You could also describe it on the discord or reddit MagicMirror channels
]]></description><link>https://forum.magicmirror.builders/topic/20245/mmm-bambulink-magicmirror-module-for-bambu-lab-printers</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20245/mmm-bambulink-magicmirror-module-for-bambu-lab-printers</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Tue, 19 May 2026 20:00:51 GMT</pubDate></item><item><title><![CDATA[MMM-HomeAssistant]]></title><description><![CDATA[@onkelbobby generally you should post a message to the author in the module github issues section
]]></description><link>https://forum.magicmirror.builders/topic/19692/mmm-homeassistant</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/19692/mmm-homeassistant</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Mon, 18 May 2026 20:45:10 GMT</pubDate></item><item><title><![CDATA[MMM-RTSPStream no longer working]]></title><description><![CDATA[@dangerousden have you tried MMM-Mplayer?
https://github.com/evroom/MMM-MPlayer
]]></description><link>https://forum.magicmirror.builders/topic/20246/mmm-rtspstream-no-longer-working</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20246/mmm-rtspstream-no-longer-working</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Mon, 18 May 2026 18:59:46 GMT</pubDate></item><item><title><![CDATA[MMM-FRITZ-Box-Callmonitor-py3 + MMM-Callmonitor-Current-Call Window]]></title><description><![CDATA[Dear @wuermchen -  you’re welcome.
Great that you’ve identified some additional issues and now have a working solution!
Congratulations!
Warm regards,
Ralf
]]></description><link>https://forum.magicmirror.builders/topic/20076/mmm-fritz-box-callmonitor-py3-mmm-callmonitor-current-call-window</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20076/mmm-fritz-box-callmonitor-py3-mmm-callmonitor-current-call-window</guid><dc:creator><![CDATA[rkorell]]></dc:creator><pubDate>Mon, 18 May 2026 14:47:29 GMT</pubDate></item><item><title><![CDATA[MM clock reverted to UTC]]></title><description><![CDATA[@smegbadger you would have to load the develop branch of MagicMirror, as we don’t distribute less than the full package…
see this link
https://forum.magicmirror.builders/topic/14327/testing-new-fixes-or-solving-current-problems-with-next-release-code
]]></description><link>https://forum.magicmirror.builders/topic/20237/mm-clock-reverted-to-utc</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20237/mm-clock-reverted-to-utc</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Mon, 18 May 2026 13:34:58 GMT</pubDate></item><item><title><![CDATA[Upgrade docker from 2.33 to 2.36 failure]]></title><description><![CDATA[@RonR
Thanks for the positive feedback. I found it amusing that you thanked Sam first, since he provides most of the support here — something for which, honestly, I often lack the time and patience…
The problem itself seemed familiar to me; I just had to track down the corresponding issue.
]]></description><link>https://forum.magicmirror.builders/topic/20244/upgrade-docker-from-2.33-to-2.36-failure</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20244/upgrade-docker-from-2.33-to-2.36-failure</guid><dc:creator><![CDATA[karsten13]]></dc:creator><pubDate>Sun, 17 May 2026 23:09:12 GMT</pubDate></item><item><title><![CDATA[Does MM no longer work on Pi Zero2w?]]></title><description><![CDATA[@wyovino
I find a very easy setup to be a server on an RPi3 A+ and the client in kiosk mode on an RPi Zero 2W.  This also gives one the option of having multiple clients attached to one server.
I’m an (old) engineer and a minimalist so I chose DietPi for my OS. This results in very little lag while easily maintaining them via ssh.
Total power consumption at full load is 5.5W (3.2W + 2.3W) versus the 4.6W for the Model 3 B+, but incrementally you get power savings as you add more clients. Cost wise, this is also more effective if you have multiple clients.
On the server side, I created scripts to install MM and eliminated the need for pm2 in favor of using services, as this save significantly on memory usage (RPi3 A+ only has 512MB of RAM).  DietPi + bare services + dropbear + MM server take up only 194-206MB of RAM.  Swap varies from 0-30MB.
I do not have a lot of modules running.  The basic Calendar, Weather, MMM-RAIN-MAP plus a module I create for to capture and display Ring camera snapshots (currently called MMM-RingSnapshot).
On the client side, I created a script to perform the most basic installation which reduces all display resources to bare X and chromium.  Total is 240-248MB running DietPi + chromium in kiosk mode with no windows manager.  Swap varies from 0-120MB while running.
I was thinking of posting the scripts on GitHub, but I’m not certain there is appetite for something that is non-standard for MM.
YMMV
]]></description><link>https://forum.magicmirror.builders/topic/20243/does-mm-no-longer-work-on-pi-zero2w</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20243/does-mm-no-longer-work-on-pi-zero2w</guid><dc:creator><![CDATA[noholdsbard]]></dc:creator><pubDate>Fri, 15 May 2026 16:10:32 GMT</pubDate></item><item><title><![CDATA[Weather module with openmeteo sends wrong Data]]></title><description><![CDATA[@TiLow awesome! As moderator here, I think my job is to help users make and keep their mirrors running.  Watch for trouble and find ways to resolve it.
Your clear description of the problem helped identify a good resolution. I didn’t do any of the work. Just connected the dots.
]]></description><link>https://forum.magicmirror.builders/topic/20225/weather-module-with-openmeteo-sends-wrong-data</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20225/weather-module-with-openmeteo-sends-wrong-data</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Thu, 14 May 2026 18:12:50 GMT</pubDate></item><item><title><![CDATA[Apply color to future events in CalendarExt3]]></title><description><![CDATA[@KristjanESPERANTO I don’t run ext3 all the time, just to test. But this is such a core value.  I think because of the ext modules color and symbol were added to the broadcast data
Lots of features are turned on by default, week number, blah blah, and use css to turn them off.
This seems simple to be default and hard for others to do ( witness wasted time here and another
]]></description><link>https://forum.magicmirror.builders/topic/20228/apply-color-to-future-events-in-calendarext3</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20228/apply-color-to-future-events-in-calendarext3</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Wed, 13 May 2026 16:46:38 GMT</pubDate></item><item><title><![CDATA[Install scripts won&#x27;t install?]]></title><description><![CDATA[@heath1066 awesome.
]]></description><link>https://forum.magicmirror.builders/topic/20221/install-scripts-won-t-install</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20221/install-scripts-won-t-install</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Wed, 13 May 2026 16:40:04 GMT</pubDate></item><item><title><![CDATA[MMM-RTSPStream  with VLC issues]]></title><description><![CDATA[Your issue is that VLC on the Pi 4 renders video in a separate window by default, ignoring the MagicMirror module position. To fix it, set pixel dimensions instead of percentages and add localPlayerArgs: ‘–no-video-on-top --width=640 --height=360’ so VLC respects the module container.
Example:
position: "top_center",
moduleWidth: 640,
moduleHeight: 360,
localPlayer: 'vlc',
localPlayerArgs: '--no-video-on-top --width=640 --height=360'

]]></description><link>https://forum.magicmirror.builders/topic/19805/mmm-rtspstream-with-vlc-issues</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/19805/mmm-rtspstream-with-vlc-issues</guid><dc:creator><![CDATA[miriamburrell]]></dc:creator><pubDate>Wed, 13 May 2026 08:39:55 GMT</pubDate></item><item><title><![CDATA[MMM-FOSHKplugin-PWS-Observations no data displayed]]></title><description><![CDATA[
@RonR said:
http://192.168.1.41/observationscurrent?stationId=FOSHKplug1n&amp;format=json&amp;units=e&amp;apiKey=MMM

Hi!
Sorry for the delay - I somehow missed your message here. Sorry!
Your FOSHKplugin appears to be running on 192.168.1.122:8081 – so the apiBase in the MMM configuration must also be set accordingly:
apiBase: 'http://192.168.1.122:8081/observations/',

Beside that, pws and apiKey should remain unchanged in order to receive additional data from FOSHKplugin:
pws: 'FOSHKplugin',
apikey: 'MMM',

The URL in apiBase must be entered with the correct case and the correct placement of the slashes ‘/’.
Otherwise, the MMM plugin will not receive any data from FOSHKplugin and continuously says: “Loading”.
Regards, Oliver
]]></description><link>https://forum.magicmirror.builders/topic/20070/mmm-foshkplugin-pws-observations-no-data-displayed</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20070/mmm-foshkplugin-pws-observations-no-data-displayed</guid><dc:creator><![CDATA[olicat]]></dc:creator><pubDate>Tue, 12 May 2026 13:34:42 GMT</pubDate></item><item><title><![CDATA[MM-Remote Android App]]></title><description><![CDATA[Thanks for sharing.
]]></description><link>https://forum.magicmirror.builders/topic/13539/mm-remote-android-app</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/13539/mm-remote-android-app</guid><dc:creator><![CDATA[AhmirArnold]]></dc:creator><pubDate>Tue, 12 May 2026 12:33:27 GMT</pubDate></item><item><title><![CDATA[April update says  &quot;New major version of npm available&quot; - should I install this?]]></title><description><![CDATA[@Richard238 generally I recommend sticking with the one that comes w the nodejs version.
]]></description><link>https://forum.magicmirror.builders/topic/20240/april-update-says-new-major-version-of-npm-available-should-i-install-this</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20240/april-update-says-new-major-version-of-npm-available-should-i-install-this</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Tue, 12 May 2026 12:09:44 GMT</pubDate></item><item><title><![CDATA[JavaScript error]]></title><description><![CDATA[@Lmagenis ok, understood
We changed npm start to use the Wayland compositor, instead of x11 because the pi os has that as default now
If you used my install script and selected pm2, then my startup script (mm.sh) detects which compositor is running, and issues the appropriate start command
]]></description><link>https://forum.magicmirror.builders/topic/20242/javascript-error</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20242/javascript-error</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Tue, 12 May 2026 12:05:20 GMT</pubDate></item><item><title><![CDATA[MMM-MonthlyCalendar not showing all events]]></title><description><![CDATA[@Drunkenkun yes, calendarweek  does need the config, it fetches the events itself too
]]></description><link>https://forum.magicmirror.builders/topic/20241/mmm-monthlycalendar-not-showing-all-events</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20241/mmm-monthlycalendar-not-showing-all-events</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Mon, 11 May 2026 18:30:27 GMT</pubDate></item><item><title><![CDATA[MMM-CalendarExt3Agenda not showing updates]]></title><description><![CDATA[@MarNog one thing about the ext3 family of modules.
They get the events from the default calendar module. But the events are broadcast by url separately.
Some will take longer than others.
Ext3 doesn’t want to flash the screen every time it receives a block of events.  It doesn’t know when the events will come. So, it has its own refreshInterval time (10 mins default), then it draws whatever it has, and then waits again
But, you don’t want to wait 10 minutes for the first display , so it has a second timer
waitFetch:5000, 5 second wait before drawing any events
If the events arrive after 5 seconds, they dont get displayed til refreshInterval time.
So, you can adjust those two to improve your viewing experience
Note that longer waitFetch means more time after start before any events are displayed
If you use pm2 to launch MagicMirror, it captures the log messages about startup and events being broadcast.
You could examine those time stamps to determine how long each cal Might take, and use that as a guide to waitFetch time
The longer waitFetch means no events are displayed after startup til waitFetch expires
]]></description><link>https://forum.magicmirror.builders/topic/20214/mmm-calendarext3agenda-not-showing-updates</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20214/mmm-calendarext3agenda-not-showing-updates</guid><dc:creator><![CDATA[sdetweil]]></dc:creator><pubDate>Wed, 06 May 2026 19:48:23 GMT</pubDate></item><item><title><![CDATA[PIR &#x2F; MQTT - Presence sensor(s) revived]]></title><description><![CDATA[MMM-PresenceScreenControl — two new releases (ecoMode + Notification API)
Dear all
a small but meaningful round of updates for MMM-PresenceScreenControl just landed on main. Both started from a single GitHub issue, so I thought I’d write up the chain of reasoning rather than just drop a changelog — maybe useful for anyone evaluating a migration from MMM-Pir, and definitely useful as a reminder to myself to check the parent project’s feature surface more carefully when forking.
Part 1 — ecoMode (Issue #5)
Rocket78 opened issue #5 with a really well-argued request: even with the screen physically off, Electron keeps repainting hidden DOM. On a Pi 3 with X11, MMM-PresenceScreenControl was leaving things like Newsfeed cross-fades running every 20 seconds — and those repaints showed up clearly as CPU spikes in his graph. He asked for an equivalent of MMM-Pir’s ecoMode, which hides every other module while the screen is off, so the browser skips layout/paint/composite for them.
So I built it, but tried to keep it lean:
ecoMode: false,        // opt-in, default off → no surprise
ecoModeIgnore: []      // module names to keep visible

Implementation notes that might interest other module authors:
Rocket78 also dropped a great ddcutil snippet in the issue for monitors that show a “no signal” splash when the video output is cut — that splash is genuinely immersion-breaking, and ddcutil setvcp D6 sends the actual DDC/CI power command, which is much closer to pressing the hardware power button:
onCommand:  ddcutil setvcp D6 1 --skip-ddc-checks
offCommand: ddcutil setvcp D6 5 --skip-ddc-checks

Added to the README’s offCommand examples. The --skip-ddc-checks is needed because some monitors stop responding to DDC queries when powered off but still process incoming power-on commands — so the check would fail before the command is even sent.
→ Issue #5 closed, commit 42b68a6.
Part 2 — what else did I miss?
Closing the issue could have been the end of it. But Rocket78’s request raised an uncomfortable question: I never used ecoMode in MMM-Pir myself, so I didn’t notice it was missing. What else did I overlook when reviving MMM-Pir?
Three items jumped out as actual gaps that other modules in the ecosystem could legitimately depend on:


MMM_PIR-USER_PRESENCE — MMM-Pir broadcasts this notification on presence transitions. Other modules (Remote-Control, voice assistants, smart-home bridges) can listen for it.


MMM_PIR-WAKEUP / LOCK / UNLOCK / END — incoming notifications that let other modules control the screen logic externally.


MMM_PIR-SCREEN_POWERSTATUS — broadcast when the physical screen turns on or off.


Without these, anyone migrating from MMM-Pir to my fork would suddenly find their automations dead — because they’d be listening for MMM_PIR-USER_PRESENCE and nothing was coming through. Even worse, they wouldn’t know why it stopped working; the screen-on/off behavior would seem fine, but cross-module integration would be silently broken.
So I built a parallel notification API, namespaced MMM_PSC-* rather than impersonating MMM-Pir’s MMM_PIR-*:
Outgoing notifications — emitted on state transitions only:
MMM_PSC-USER_PRESENCE       payload: true / false
                            fires when combined presence changes

MMM_PSC-SCREEN_POWERSTATUS  payload: true / false
                            fires when physical screen turns on/off

Both fire only on actual transitions — no spam every poll cycle.
Incoming notifications — consumed by the module
MMM_PSC-WAKEUP   wake screen, reset timer (equivalent to a touch)

MMM_PSC-END      force screen off immediately

MMM_PSC-LOCK     freeze presence handling — sensors are still tracked internally, but no longer change screen state

MMM_PSC-UNLOCK   resume normal presence handling and re-evaluate the current sensor state

Implementation detail worth flagging: the LOCK guard sits in updatePresence(), which is the single funnel through which all sensor inputs (PIR, MQTT, touch, external wakeup socket) eventually pass. So whatever the trigger source, it’s correctly suppressed while locked. UNLOCK calls updatePresence() again, which re-evaluates the current sensor state — so if you’ve unlocked while a person is still in front of the PIR, the screen comes back on immediately. No need for the caller to send a WAKEUP after UNLOCK.
Useful patterns this enables:
// Wake the mirror when a doorbell event arrives:
this.sendNotification("MMM_PSC-WAKEUP");

// Force-off cleanly from outside (smart-home rule, etc.) without
// bypassing the module and going straight to the screen command:
this.sendNotification("MMM_PSC-END");

// Take exclusive control of the display for a video call,
// then hand it back when done:
this.sendNotification("MMM_PSC-LOCK");
// ... your module is showing its full-screen content ...
this.sendNotification("MMM_PSC-UNLOCK");

END is the clean way to force-off the screen from outside without touching offCommand directly — the module’s internal state stays consistent, all the right outgoing notifications still fire, and any other listeners (logging, analytics, smart home) see the transition.
Tested live end-to-end via MMM-Remote-Control’s notification API:
curl -X GET "http://localhost:8080/api/notification/MMM_PSC-LOCK"
curl -X GET "http://localhost:8080/api/notification/MMM_PSC-END"
    → screen off, stays off
curl -X GET "http://localhost:8080/api/notification/MMM_PSC-WAKEUP"
    → ignored (locked)
curl -X GET "http://localhost:8080/api/notification/MMM_PSC-UNLOCK"
    → screen back on

All four routes verified, log trace clean, outgoing notifications fired in the right order on every transition.
→ Commit 10000ca.
Update / install
If you’re already on the module:
cd ~/MagicMirror/modules/MMM-PresenceScreenControl
rm -rf node_modules
git pull
npm install

Both changes are backwards-compatible. ecoMode is opt-in (default false), and the new notifications are additive — nothing existing is modified. So you can update without touching your config and pick up only what you need.
A genuine thank-you to Rocket78 for the well-reasoned issue and the ddcutil tip — it triggered the full audit, which in turn closed a much bigger latent gap.
Exactly the kind of feedback that improves a fork. If you’ve migrated from MMM-Pir and notice anything else missing that you’d consider load-bearing, please open an issue.
Hope you find it useful.
Warmest regards,
Ralf
]]></description><link>https://forum.magicmirror.builders/topic/19829/pir-mqtt-presence-sensor-s-revived</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/19829/pir-mqtt-presence-sensor-s-revived</guid><dc:creator><![CDATA[rkorell]]></dc:creator><pubDate>Tue, 05 May 2026 11:40:15 GMT</pubDate></item><item><title><![CDATA[MMM-Charms - Rotating affirmations, reminders, quotes, and themed text packs]]></title><description><![CDATA[MMM-Charms is a MagicMirror² module for displaying rotating affirmations, reminders, reflective prompts, and curated quote/dialogue packs from multiple named sets.
It supports local JSON packs, simple text sets, manual switching between packs, tap/click cycling, and optional time-based pack switching.
Current packs include:

General
Calm
Confidence
Family
Gentle Reminders
Hard Days
Grounding
Quotes
Bollywood
Video Game Quotes

The idea behind MMM-Charms came with a desire to add quotes from Bollywood movies and video games :) .  It then became an attempt to make the mirror feel a little more reflective and customizable. It can now be used for personal affirmations, family-oriented prompts, calmer household messaging, themed quote packs, reminders for timed chores or fun pop-culture rotations. I am curious to find out what packs users might come up with. It is rightly placed under ‘Entertainment’ on this forum. Please remember this  is not a substitute for professional mental health, medical, therapeutic, or crisis support.
Screenshots:
[image: 1777864439580-mmm-charms-2.png]
[image: 1777864453706-mmm-charms-1.png]
Download:
[card:testingonlypi/MMM-Charms]
The readme file clearly states the use of AI to create this module. I am not and will never be a coder of any standard, and would never seek  to replace those who are more experienced, committed and better at this… same as I can take photos, but may not be a professional photographer.
Version 0.1.0

First public release
Added support for multiple named packs
Added manual switching between packs
Added optional tap/click cycling
Added optional time-based pack switching
Added JSON pack support
Included curated packs for General, Calm, Confidence, Family, Gentle Reminders, Hard Days, Grounding, Quotes, Bollywood, and Video Game Quotes

]]></description><link>https://forum.magicmirror.builders/topic/20238/mmm-charms-rotating-affirmations-reminders-quotes-and-themed-text-packs</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20238/mmm-charms-rotating-affirmations-reminders-quotes-and-themed-text-packs</guid><dc:creator><![CDATA[testingonlypi]]></dc:creator><pubDate>Mon, 04 May 2026 03:19:40 GMT</pubDate></item><item><title><![CDATA[MMM-XboxFriends - Showing your xbox online friends and their status]]></title><description><![CDATA[
@iamktothek said:
Thanks for the node-fetch advice @kristjanesperanto , Ill look to refactor in the near future
@rmonkey What would that look like for you? Would you want to put the gamertags into the config to only select those particular profiles? I believe I could get that implemented

I think you have the right idea. Say I have a hundred people in my XBL friends list, but maybe only 5 that I’d want the status on. “Ah, iamktothek is playing Power Wash Simulator, lemme jump on and join him.”
Ideally, I could tell it to filter to those 5, and maybe even hide the module entirely if no one on the filter list is on.
This is in the “Would Be Nice If Robot Monkey Had Everything Personalized To Him” category – there’s nothing wrong with the already great module you shared.
]]></description><link>https://forum.magicmirror.builders/topic/20215/mmm-xboxfriends-showing-your-xbox-online-friends-and-their-status</link><guid isPermaLink="true">https://forum.magicmirror.builders/topic/20215/mmm-xboxfriends-showing-your-xbox-online-friends-and-their-status</guid><dc:creator><![CDATA[rmonkey]]></dc:creator><pubDate>Sun, 03 May 2026 22:51:58 GMT</pubDate></item></channel></rss>