MagicMirror Forum
    • Recent
    • Tags
    • Unsolved
    • Solved
    • MagicMirror² Repository
    • Documentation
    • 3rd-Party-Modules
    • Donate
    • Discord
    • Register
    • Login
    1. Home
    2. rkorell
    A New Chapter for MagicMirror: The Community Takes the Lead
    Read the statement by Michael Teeuw here.
    R Offline
    • Profile
    • Following 0
    • Followers 1
    • Topics 28
    • Posts 439
    • Groups 1

    rkorell

    @rkorell

    Module Developer
    94
    Reputation
    26
    Profile views
    439
    Posts
    1
    Followers
    0
    Following
    Joined
    Last Online

    rkorell Unfollow Follow
    Module Developer
    • PIR / MQTT - Presence sensor(s) revived

      Dear MagicMirror-ians

      As may already known I was a real fan of MMM-Pir.
      For also good known reasons this nice module is not longer maintained.

      I have a local clone which runs OK but in the meantime I had switched to MMM-MQTTScreenOnOff wich attaches a “better” (radar-) sensor to my mirror. But I’ve missed the progress bar, the dimming and cron-like functionality. In addition the radar sensor is much slower than PIR- caused by a 5 second update intervall as minimum.

      After plenty of tinkering and testing, and above all torturing AI heavily I’m excited to announce:
MMM-PresenceScreenControl is finally out! 🎉

      This module brings together the best of both worlds:
      • The beloved timer bar and auto-dimming from MMM-Pir,
      • The reliability, MQTT support, and simplicity of MMM-MQTTScreenOnOff,
      • All cleaned up, without unnecessary complexity, cryptic cron strings, or weird build tricks.

      A few highlights:
      • Presence detection with PIR, MQTT, or both (whichever triggers first wins)
      • A visual timer bar so you always know how long the screen will stay on
      • Straightforward “ignore” and newly introduced “always-on” time windows using plain times and days—no cryptic cron needed
      • Customizable screen on/off commands—works on Pi, PC, X11, Wayland, CEC, and more
      • Touch mode for remote or manual override (yes, you can poke your mirror awake remotely!)

      If you’re after spinning circles or relay magic, this isn’t your thing (yet 😉).

      But if you want a solid, readable, and maintainable presence module that just works—even (hopefully) after updates—this is for you.

      Give it a try, share your feedback, open pull requests, or ask questions right here or on GitHub:

      Happy mirroring!


      Ralf

      posted in System
      R
      rkorell
    • MMM-Globe: Meteosat imagery broken — fork with fix available

      Dear community,

      just a heads-up for those of you using MMM-Globe with the europeDiscNat or europeDiscSnow
      style — you’ve probably noticed that the satellite image has been stuck since around
      February 22. Turns out EUMETSAT has pulled the plug on their old static image server at
      eumetview.eumetsat.int. They moved to a shiny new platform at view.eumetsat.int, but
      unfortunately it’s a JavaScript app now — no more simple image URLs we can point a module
      at.

      I’ve also opened an issue on the original repo for reference:
      https://github.com/LukeSkywalker92/MMM-Globe/issues/22

      I realize this probably flew under the radar for most of you — if your globe is pointed at
      the Americas or Asia, everything’s fine. But for the small but proud club of European globe
      watchers, it’s been a rough week staring at the same cloud pattern wondering if the weather
      had simply stopped.

      Since the original MMM-Globe hasn’t seen any updates in a while, I went ahead and created a
      fork that adds a new “meteosat” style. It pulls Meteosat full-disk imagery from the CIRA
      SLIDER service (run by NOAA/RAMMB at Colorado State University). The GeoColor product looks
      really nice on the mirror — natural color during the day, and city lights on a Blue Marble
      background at night. I think you’ll like it!

      Big thanks to Luke Scheffler (@lukecodewalker) for creating MMM-Globe in
      the first place — his idea of turning satellite images into a globe with a simple CSS circle
      clip is just brilliant. This fork builds on his work.

      If you want to give it a try:
      cd ~/MagicMirror/modules
      rm -rf MMM-Globe
      git clone https://github.com/rkorell/MMM-Globe.git

      Then change your config to:
      {
      module: “MMM-Globe”,
      position: “lower_third”,
      config: {
      style: “meteosat”,
      imageSize: 600,
      updateInterval: 15 * 60 * 1000
      }
      },

      The fork also fixes an annoying startup issue where the globe would stay blank after a
      reboot if the network wasn’t ready yet — something that probably bugged a few of us running
      this on a Raspberry Pi.

      All the details, available styles and config options are in the README:
      https://github.com/rkorell/MMM-Globe

      Happy mirroring! 🪞

      posted in Showcase
      R
      rkorell
    • MMM-Bring v2 — a maintained, zero-dependency fork with app-identical category sorting

      Hi everyone,

      I’ve tried a longer time ago without success - recently I gave it a second try and surprisingly it’s “working” right now: David Werth’s MMM-Bring.
      It is a lovely little module and I want to be clear up front that all the original credit goes to him. The trouble is that it has not seen any maintenance in roughly six years (the original dates back to 2019), and my recent npm install started throwing security warnings at me.
      Rather than let it bit-rot, I reworked it fairly thoroughly and published the result as a fork: https://github.com/rkorell/MMM-Bring.

      I thought it might be useful to others here, so here is what changed and, more importantly, why.

      1. The original has been unmaintained for ~6 years

      The original module goes back to 2019 and has effectively been dormant since. That is not a criticism — it simply did its job and life moved on. But six years is a long time in Node land: it was written against an older dependency and rendering style, and nobody was around to react when its dependencies started aging out. If you install it today on a current MagicMirror / Node setup, you feel that age immediately (see the next point). My goal with the fork was not to reinvent it, but to bring it back to a state where it installs cleanly, runs on current Node, and can be maintained going forward.

      2. The npm security issues — now zero runtime dependencies

      This is what actually pushed me to act. Installing the original pulls in axios ^0.21.2 (released back in 2021) and data-store. On that axios line, npm audit reports two high-severity advisories — credential leakage across an HTTP-to-HTTPS redirect, and a prototype-pollution issue — plus a transitive follow-redirects advisory. For a module that authenticates with your Bring! account, shipping a known-vulnerable HTTP client is not great.

      Instead of merely bumping versions, I removed both dependencies entirely. The fork now has zero runtime dependencies. All HTTP goes through Node’s built-in fetch (Node 18+), and the auth-token cache is a tiny fs-based JSON file that replaces data-store. The upshot: npm audit is clean, there is nothing to compile, and there is no npm install step at all anymore — you just clone it. Fewer moving parts, no native build, and nothing that can rot silently in the background.

      3. The headline feature: app-identical category sorting

      This is the part I am most happy with. The original shows the list in whatever raw order the API returns. The Bring! app, however, groups items into categories (Fruits & Vegetables, Milk & Cheese, Meat & Fish, …) and sorts those categories in an order you can customise per list. I worked out how the app reconstructs that and reproduced it faithfully.

      There is a new option, useSections, with three modes:

      • "off" — the classic flat list in raw API order (the old behaviour).
      • "on" (the default) — items sorted into your list’s category order as one continuous list, without visible headers. Same layout footprint as before, just in the right order.
      • "show" — the same sorting, plus a text header per category, exactly like the app.

      The grouping is genuinely app-identical rather than a guess: it follows your list’s own saved section order (listSectionOrder), honours the sections you have hidden, and shows the localized category names and item names for your list’s language. Items you typed that are not in Bring!'s catalog land in an “own items” section — and even that fallback label is localized (13 language files covering all 20 Bring! locales). Under the hood the canonical item id is kept separate from the translated display name, so marking things bought and adding items keeps working regardless of language. There are screenshots of all three modes in the README if you want to see the difference.

      Other improvements worth mentioning

      • Backend-driven polling with a cached last-good state. The node helper owns the refresh cycle, so a browser reload shows data instantly and a transient network blip never blanks the list.
      • Modern auth. The access token is refreshed via its refresh token, with a full password re-login only as a fallback.
      • showCount. An optional count in the title line when the list is longer than maxItems, so you can see there is more than what is shown.
      • Font licensing tidied up. The bundled paid “Museo Sans 300” weight was removed; the free 500 weight stays with proper exljbris attribution, and the spec label falls back to the MagicMirror default font.
      • Touch support retained. You can still mark items bought and add items via MMM-Keyboard.

      Install

      cd ~/MagicMirror/modules
      git clone https://github.com/rkorell/MMM-Bring.git
      

      That is it — no npm install. Then add the module block to your config.js (there is a full options table in the README). If you already run the original module, you can simply replace the folder; your config.js entry stays the same. Step-by-step migration notes are in the README.

      Credits and the usual caveat

      All credit for the original module goes to David Werth (https://github.com/werthdavid/MMM-Bring). The API-interaction design was inspired by miaucl/bring-api (https://github.com/miaucl/bring-api), the well-maintained Python client, as a reference for a current, state-of-the-art Bring! implementation.

      Standard caveat: Bring! offers no official public API, so this — like every Bring! integration — talks to the same private endpoints the app uses. They could change at any time. It has been stable for years, but be aware of that.

      Repo, README and changelog: https://github.com/rkorell/MMM-Bring. Feedback, issues and pull requests are very welcome.

      Hope you will find it useful.
      Warmest regards,
      Ralf

      posted in Showcase
      R
      rkorell
    • New Mirror

      Hello to all,
      I’ve started end of last week and today I’m nearly happy with my modules and arrangement.

      Had struggled somtimes with several modules, not all of interest are currently maintained so sometimes I cannot get run it properly.
      Just now I’m “ready” with config - future steps are purchasing the mirror (sample pack is shipping) and build up the frame.
      Tomorrow the PIR sensor will arrive so in addition I have to figure out if and how this works and intergrate this sensor into the build.

      Future step is the integration of a background LED stripe - not sure about this because I’m currently not sure if I’m able to switch this LED on/off in conjunction with monitor (out of MMM-Pir).

      Here a current screenshot:
      MagicMirrorProto.jpg

      I’ve used standards (weather, clock, newsfeed) and:

      MMM-Globe
      MMM-MyGarbage
      MMM-CalendarExt3Agenda
      MMM-Strava
      MMM-NowPlayingOnSpotify
      MMM-ToDoist
      birthdaylist
      MMM-SystemStats
      MMM-SystemInfo
      (MMM-Pir - “installed” but lacking sensor, so disabled and not tested)

      Target Monitor is a 27’’ Samsung device and I will mount this behind a 120cm*60cm mirror.
      (Will post an image, if ready…)

      I’m thinking about enriching the szenario with an 8’’ android tablet for streaming, but not sure…

      Nice rest of the day to all of you, thanks for your really GREAT work and highly motivated assistance in this forum.

      Warmest regards,
      Ralf

      posted in Show your Mirror
      R
      rkorell
    • RE: MMM-Globe: Meteosat imagery broken — fork with fix available

      @plainbroke said:

      Will that work in the USA ? I like the prettier styling…

      Dear @plainbroke ,
      well, I owe you an apology — and a thank you!

      When you asked, I answered “wrong satellite” and moved on. Technically correct, but I completely missed the obvious next question: “So… can we get the
      RIGHT satellite?”

      Turns out, we can. The CIRA SLIDER service that provides the beautiful Meteosat GeoColor imagery (with the night city lights) serves four geostationary
      satellites — and one of them is GOES-19, parked right over the Americas at 75.2°W. Same API, same image quality, same stunning day/night visualization.
      I just never looked.

      Your question made me look. So as of v3.1.0, MMM-Globe now supports:

      ┌─────────────────┬────────────────────┬───────────────────────────┐
      │      Style      │     Satellite      │           View            │
      ├─────────────────┼────────────────────┼───────────────────────────┤
      │ geoColorEurope  │ Meteosat (0°)      │ Europe / Africa           │
      ├─────────────────┼────────────────────┼───────────────────────────┤
      │ geoColorUSA     │ GOES-19 (75.2°W)   │ Americas ← this is yours! │
      ├─────────────────┼────────────────────┼───────────────────────────┤
      │ geoColorPacific │ GOES-18 (137.0°W)  │ Pacific                   │
      ├─────────────────┼────────────────────┼───────────────────────────┤
      │ geoColorAsia    │ Himawari (140.7°E) │ Asia / Australia          │
      └─────────────────┴────────────────────┴───────────────────────────┘
      

      Just set style: “geoColorUSA” and you’re good to go. Same auto-polling every 60 seconds, same beautiful globe, just the right half of the planet this
      time. 😊

      So thank you for what I should have recognized as a feature request instead of a geography lesson. Sometimes the best contributions come disguised as
      simple questions.

      Warmest regards,
      Ralf

      posted in Showcase
      R
      rkorell
    • RE: New Mirror

      And here the target monitor in action - 27’’ Samsung…

      MagicMirrorHardwareSmallresolution.jpg

      Keep you posted.

      Regards,
      Ralf

      posted in Show your Mirror
      R
      rkorell
    • RE: Screen "offline" during specific time of day

      @_V_ My module MMM-PresenceScreenControl Offers a comfortable way to switch on or off during defined times - as much as you like per day as much days as you like.

      Regards,
      Ralf

      posted in Troubleshooting
      R
      rkorell
    • MMM-NowPlayingOnSpotify: surviving Spotify's 6-month refresh-token expiry (a maintained fork)

      Hi all,

      if you use MMM-NowPlayingOnSpotify (raywo’s lovely “now playing” module), there’s a
      change coming from Spotify that will quietly break it — and I wanted to share both the
      problem and a fix.

      The problem

      Spotify announced that, starting 20 July 2026, user refresh tokens will expire after 6
      months (blog (https://developer.spotify.com/blog/2026-06-18-refresh-token-expiration)).
      Until now those tokens were effectively permanent, so the module just stored one and
      kept minting access tokens forever. Once a refresh token expires, Spotify returns an
      invalid_grant error, and the app is expected to discard it and send the user through
      the sign-in flow again.

      The original module doesn’t handle that case: it logs the error and silently falls back
      to the “nothing is playing” logo. So one day your mirror would just… stop showing
      songs, with no hint why — while hammering the API once per second with a dead token.

      First attempt: the polite way

      I opened an issue on the original repo to flag it. Unfortunately the project has been
      unmaintained for ~6 years, and there was no response. So rather than let everyone’s
      module quietly die this summer, I forked it and did the work.

      The fix: a fork with proper token handling

      👉 https://github.com/rkorell/MMM-NowPlayingOnSpotify (v2.0.0)

      What it does now:

      • Detects invalid_grant, stops retrying, and shows a clear red re-authorization banner
        on the mirror instead of pretending nothing’s playing.
      • Proactive warning ~2 weeks before the hard expiry (a smaller banner above the cover
        art) — the music keeps playing, so it’s never a surprise outage.
      • Self-managed token store (tokens.json, git-ignored) instead of tokens in config.js,
        so rotated/renewed tokens are actually persisted. You only keep clientID, clientSecret
        and redirectURI in your config now.
      • Integrated re-authorization: the module runs a tiny local auth server; you
        re-authorize from a browser and it recovers in-process, no restart.
      • Under the hood: a full refactor to native fetch/http — the deprecated request/express
        dependencies are gone, so it’s now zero runtime dependencies — plus a proper backend
        poll loop and English/German translations.

      One wrinkle worth knowing (loopback + SSH tunnel)

      Spotify only accepts http redirect URIs for loopback addresses now — a LAN IP or
      hostname over http is rejected at runtime as insecure, and localhost isn’t allowed
      either. So the redirect URI is http://127.0.0.1:8888/callback. Since a mirror is
      headless, the easiest way to re-authorize from your laptop is a one-line SSH tunnel:

      ssh -L 8888:127.0.0.1:8888 pi@<mirror-ip>
      

      …then open http://127.0.0.1:8888 in your laptop’s browser. Full details are in the
      README.

      Happy to help anyone getting it running, and a big thank-you to raywo for the original
      module that many of us have enjoyed for years.

      posted in Showcase
      R
      rkorell
    • Problems with WLAN connectivity - solved

      Dear mirror fans,
      for your information and reference some findings with my mirror.
      I’m running a MagicMirror on a PI5 with an NVME HAT as boot device.
      My first approach was to de-assemble an original Pi power supply (because of its form factor) and to build this internally into the mirror-frame.
      As reported earlier in a different thread this power supply died due to overheating.

      My next approach was to use a new PI-power supply - this time externally.
      Caused by the circumstances of my installation (power plug far below mirror position and Pi mounted on the top of the mirror) I have used a USB-C to USB-C cable (150cm, 5A) to extend the standard-cable.

      As it turns out now this wasn’t a good idea, ether:
      It worked pretty long (several weeks) good and without any problem.
      But since some days I got more and more really stubborn WLAN losses which were often unrecoverable - only plugging out power supply to reforce a restart helped (I’m working headless as majority of you).

      In the meantime I was able to implement a tiny service which automatically detects the connectivity loss and restarts the WLAN, so a sufficient symptomatic treatment is in place - this discovers connectivity every five minutes, which is OK to me.

      While I was just tinkering I’ve thought it could be a nice idea to identify the root cause and so I added some logging features in the mentioned service.

      Now the interesting (unexpected) finding: Obvious root cause was an undervoltage!

      I’ve searched around (because initially I failed to remember my “cable-extension”) but couldn’t find any reason for this (nothing attached else than the NVME and my mirror doesn’t have anything heavily using the harddisk)…

      Then the additional cable came in my mind and - voilà - this was the root cause - despite its thickness and 5A specification.
      For now I have added some 230V cabeling to the top of the mirror, installed there (outside the mirror frame) a third (de-assembled) PI power supply and connected the standard-long cable of this power supply to the Pi.
      Since then no undervoltage detected (prior to this every few minutes).

      So my learning: Pi is bitchy with cable extensions and tiny undervoltages can lead to heavy WLAN problems.

      May one or the other can benefit from these findings.

      Warm regards,
      Ralf

      posted in General Discussion
      R
      rkorell
    • RE: First MM project - family dashboard

      @cpcode
      Really cool!

      For your families’ whishes: A nice module für RTPS strems of security cams is “MMM-MPlayer” …
      There are several other modules around but the other ones do have several dependencies and requirements.
      MMM-Mplayer use (as name suggest) simply mplayer.
      Works like a charm …
      @myfingersarecold has done a really nice job with this.

      Regards,
      Ralf

      posted in Show your Mirror
      R
      rkorell
    • RE: MMM-Bring v2 — a maintained, zero-dependency fork with app-identical category sorting

      Dear Kristjan, @KristjanESPERANTO ,
      Thanks for this hint!
      Wasn’t aware that forks obviously need this.
      For sure enabled right now for all of my module forks.

      Warm regards,
      Ralf

      posted in Showcase
      R
      rkorell
    • RE: Family Command Center – Pi 5 Touch Mirror with 19 Pages, AI Comics & Presence Control

      Dear @soldatino,
      very (!) impressive!
      Not really MY usecase because of my explicite approach to use my mirror as a viewing port but really nice.

      To my big surprise I found your fifth screen with Bring! integration and was therefore inspired to try this again (longer time ago for some strange reasons the module didn’t work on my installation and i stopped trials around that, assuming that +six years old code doesn’t work at all).

      With your awesome setup I gave it a second try - and it worked.
      But: It throws severe security issues and in addition it doesn’t work exactly as desired (by me).

      That’s the reason why I forked & refactured the original module.
      You can check the whole story behind my approach in this post - if you like.

      I would like to say “thanks” to you for this “kick” and inspiration.

      Warm regards,
      Ralf

      posted in Show your Mirror
      R
      rkorell
    • MMM-Bring v2 — a maintained, zero-dependency fork with app-identical category sorting

      Hi everyone,

      I’ve tried a longer time ago without success - recently I gave it a second try and surprisingly it’s “working” right now: David Werth’s MMM-Bring.
      It is a lovely little module and I want to be clear up front that all the original credit goes to him. The trouble is that it has not seen any maintenance in roughly six years (the original dates back to 2019), and my recent npm install started throwing security warnings at me.
      Rather than let it bit-rot, I reworked it fairly thoroughly and published the result as a fork: https://github.com/rkorell/MMM-Bring.

      I thought it might be useful to others here, so here is what changed and, more importantly, why.

      1. The original has been unmaintained for ~6 years

      The original module goes back to 2019 and has effectively been dormant since. That is not a criticism — it simply did its job and life moved on. But six years is a long time in Node land: it was written against an older dependency and rendering style, and nobody was around to react when its dependencies started aging out. If you install it today on a current MagicMirror / Node setup, you feel that age immediately (see the next point). My goal with the fork was not to reinvent it, but to bring it back to a state where it installs cleanly, runs on current Node, and can be maintained going forward.

      2. The npm security issues — now zero runtime dependencies

      This is what actually pushed me to act. Installing the original pulls in axios ^0.21.2 (released back in 2021) and data-store. On that axios line, npm audit reports two high-severity advisories — credential leakage across an HTTP-to-HTTPS redirect, and a prototype-pollution issue — plus a transitive follow-redirects advisory. For a module that authenticates with your Bring! account, shipping a known-vulnerable HTTP client is not great.

      Instead of merely bumping versions, I removed both dependencies entirely. The fork now has zero runtime dependencies. All HTTP goes through Node’s built-in fetch (Node 18+), and the auth-token cache is a tiny fs-based JSON file that replaces data-store. The upshot: npm audit is clean, there is nothing to compile, and there is no npm install step at all anymore — you just clone it. Fewer moving parts, no native build, and nothing that can rot silently in the background.

      3. The headline feature: app-identical category sorting

      This is the part I am most happy with. The original shows the list in whatever raw order the API returns. The Bring! app, however, groups items into categories (Fruits & Vegetables, Milk & Cheese, Meat & Fish, …) and sorts those categories in an order you can customise per list. I worked out how the app reconstructs that and reproduced it faithfully.

      There is a new option, useSections, with three modes:

      • "off" — the classic flat list in raw API order (the old behaviour).
      • "on" (the default) — items sorted into your list’s category order as one continuous list, without visible headers. Same layout footprint as before, just in the right order.
      • "show" — the same sorting, plus a text header per category, exactly like the app.

      The grouping is genuinely app-identical rather than a guess: it follows your list’s own saved section order (listSectionOrder), honours the sections you have hidden, and shows the localized category names and item names for your list’s language. Items you typed that are not in Bring!'s catalog land in an “own items” section — and even that fallback label is localized (13 language files covering all 20 Bring! locales). Under the hood the canonical item id is kept separate from the translated display name, so marking things bought and adding items keeps working regardless of language. There are screenshots of all three modes in the README if you want to see the difference.

      Other improvements worth mentioning

      • Backend-driven polling with a cached last-good state. The node helper owns the refresh cycle, so a browser reload shows data instantly and a transient network blip never blanks the list.
      • Modern auth. The access token is refreshed via its refresh token, with a full password re-login only as a fallback.
      • showCount. An optional count in the title line when the list is longer than maxItems, so you can see there is more than what is shown.
      • Font licensing tidied up. The bundled paid “Museo Sans 300” weight was removed; the free 500 weight stays with proper exljbris attribution, and the spec label falls back to the MagicMirror default font.
      • Touch support retained. You can still mark items bought and add items via MMM-Keyboard.

      Install

      cd ~/MagicMirror/modules
      git clone https://github.com/rkorell/MMM-Bring.git
      

      That is it — no npm install. Then add the module block to your config.js (there is a full options table in the README). If you already run the original module, you can simply replace the folder; your config.js entry stays the same. Step-by-step migration notes are in the README.

      Credits and the usual caveat

      All credit for the original module goes to David Werth (https://github.com/werthdavid/MMM-Bring). The API-interaction design was inspired by miaucl/bring-api (https://github.com/miaucl/bring-api), the well-maintained Python client, as a reference for a current, state-of-the-art Bring! implementation.

      Standard caveat: Bring! offers no official public API, so this — like every Bring! integration — talks to the same private endpoints the app uses. They could change at any time. It has been stable for years, but be aware of that.

      Repo, README and changelog: https://github.com/rkorell/MMM-Bring. Feedback, issues and pull requests are very welcome.

      Hope you will find it useful.
      Warmest regards,
      Ralf

      posted in Showcase
      R
      rkorell
    • RE: NewsFeed - how to adjust the description text size?

      @thartley cool.
      Happy that it works.
      Have fun!
      Warm regards,
      Ralf

      posted in Troubleshooting
      R
      rkorell
    • RE: NewsFeed - how to adjust the description text size?

      @thartley
      The text size of the newsfeed description is controlled via the global CSS class .small which the template assigns to the element.
      Defined in ~/MagicMirror/css/main.css:

      .small { font-size: var(--font-size-small); }
      

      If I see it right::

      • default/newsfeed/newsfeed.css does not contain a font-size for the description — only list and layout rules.
      • The description-specific class .newsfeed-desc does exist, but it does not set a font size.

      If you want to change the description size independently of other .small elements , the cleanest approach would be an override in css/custom.css:

      .newsfeed  .newsfeed-desc { font-size: your_desired_font_size_as_number)
      

      (do not alter the global .small).

      HTH.
      Warm regards,
      Ralf

      posted in Troubleshooting
      R
      rkorell
    • RE: MMM-NowPlayingOnSpotify: surviving Spotify's 6-month refresh-token expiry (a maintained fork)

      Dear @KristjanESPERANTO ,
      thanks :-)
      Good idea - I’ve added a screenshot right now.
      (closed a documentation error regarding first / re-authorization in parallel).

      Warm regards,
      Ralf

      posted in Showcase
      R
      rkorell
    • MMM-NowPlayingOnSpotify: surviving Spotify's 6-month refresh-token expiry (a maintained fork)

      Hi all,

      if you use MMM-NowPlayingOnSpotify (raywo’s lovely “now playing” module), there’s a
      change coming from Spotify that will quietly break it — and I wanted to share both the
      problem and a fix.

      The problem

      Spotify announced that, starting 20 July 2026, user refresh tokens will expire after 6
      months (blog (https://developer.spotify.com/blog/2026-06-18-refresh-token-expiration)).
      Until now those tokens were effectively permanent, so the module just stored one and
      kept minting access tokens forever. Once a refresh token expires, Spotify returns an
      invalid_grant error, and the app is expected to discard it and send the user through
      the sign-in flow again.

      The original module doesn’t handle that case: it logs the error and silently falls back
      to the “nothing is playing” logo. So one day your mirror would just… stop showing
      songs, with no hint why — while hammering the API once per second with a dead token.

      First attempt: the polite way

      I opened an issue on the original repo to flag it. Unfortunately the project has been
      unmaintained for ~6 years, and there was no response. So rather than let everyone’s
      module quietly die this summer, I forked it and did the work.

      The fix: a fork with proper token handling

      👉 https://github.com/rkorell/MMM-NowPlayingOnSpotify (v2.0.0)

      What it does now:

      • Detects invalid_grant, stops retrying, and shows a clear red re-authorization banner
        on the mirror instead of pretending nothing’s playing.
      • Proactive warning ~2 weeks before the hard expiry (a smaller banner above the cover
        art) — the music keeps playing, so it’s never a surprise outage.
      • Self-managed token store (tokens.json, git-ignored) instead of tokens in config.js,
        so rotated/renewed tokens are actually persisted. You only keep clientID, clientSecret
        and redirectURI in your config now.
      • Integrated re-authorization: the module runs a tiny local auth server; you
        re-authorize from a browser and it recovers in-process, no restart.
      • Under the hood: a full refactor to native fetch/http — the deprecated request/express
        dependencies are gone, so it’s now zero runtime dependencies — plus a proper backend
        poll loop and English/German translations.

      One wrinkle worth knowing (loopback + SSH tunnel)

      Spotify only accepts http redirect URIs for loopback addresses now — a LAN IP or
      hostname over http is rejected at runtime as insecure, and localhost isn’t allowed
      either. So the redirect URI is http://127.0.0.1:8888/callback. Since a mirror is
      headless, the easiest way to re-authorize from your laptop is a one-line SSH tunnel:

      ssh -L 8888:127.0.0.1:8888 pi@<mirror-ip>
      

      …then open http://127.0.0.1:8888 in your laptop’s browser. Full details are in the
      README.

      Happy to help anyone getting it running, and a big thank-you to raywo for the original
      module that many of us have enjoyed for years.

      posted in Showcase
      R
      rkorell
    • RE: electronSwitches in config.js — am I reading the code wrong, or does it not actually work?

      @sdetweil , @kristjanesperanto ,
      I’ve decided to resolve it by myself - with Sam’s hint/advice/helper-file.
      It seems to work - will double check my cache size in a few days.

      Thanks again for your great support.
      Migration is a bigger task and wihout any need currently too much - even cache-growth wouldn’t change this.

      • never touch a running system :-)

      Warm regards,
      Ralf

      posted in Troubleshooting
      R
      rkorell
    • RE: electronSwitches in config.js — am I reading the code wrong, or does it not actually work?

      @sdetweil OK, thanks!
      Still doesn’t sound THAT safe …

      regards,
      Ralf

      posted in Troubleshooting
      R
      rkorell
    • RE: electronSwitches in config.js — am I reading the code wrong, or does it not actually work?

      @sdetweil , yes.
      I’ve really thought about this.

      How do you see the update?
      I’m currently on 2.34.
      Switch to 2.35 is SUBSTANCIAL !

      • changes of standard-module location, changes of location for custom.css, electron new …

      Will this break my system?
      Or am I fine with just using your great update-script?
      Thanks for any advice (I KNOW that you cannot provide any guarantee. I’m just interested in gut-feeling…)

      (and: if it brake: is there a way back??? )

      Warmest regards,
      Ralf

      posted in Troubleshooting
      R
      rkorell