Module Developers

Private

You have developed a module for the MagicMirror? Join the group and get a “Module Developer” badge!

Posts

  • RE: New Module MMM-EnregyFlow

    @fischi87 Thanks :)

    And don’t forget to add your module to the module list.

  • RE: New Module MMM-EnregyFlow

    @fischi87 Looks nice!

    I noticed you marked it as UNLICENSED.

    I’m not a lawyer, but in my understaning, this means ‘All Rights Reserved’ by default, so others cannot legally clone, use, or modify your code, even though it’s public.

  • RE: Upgrade

    @sdetweil Yeah, warnings come from 11.16.0+

  • RE: Upgrade
  • 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

  • RE: MMM-Bring v2 — a maintained, zero-dependency fork with app-identical category sorting

    @rkorell Cool! Would be nice if you would switch on “Issues” in your repos.

  • 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

  • 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

  • RE: NewsFeed - how to adjust the description text size?

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