evancohen/smart-mirror: a voice-controlled Raspberry Pi mirror you build yourself

What smart-mirror actually is, and who the repository is written for

This is a JavaScript application that runs full screen on a Raspberry Pi and draws a dashboard onto a monitor placed behind a two-way mirror. The README describes it as "a voice controlled life automation hub, most commonly powered by the Raspberry Pi." The repository topics list diy, home-automation, raspberry-pi, smart-home and voice-control, which is an accurate summary of the audience: someone who owns a Pi, a monitor and a piece of mirrored acrylic, and who is willing to wire them together.

It is not a product. There is no companion phone app in the repository, no account system, and no hosted service. The pieces you get are an Electron shell (main.js), a browser-side app under app/, a plugin directory, a wake-word model pair (smart_mirror.pmdl and smart_mirror.umdl), a motion sensor script (motion.js) and a standalone speech helper (sonus.js). Everything the mirror displays comes from one of those plugins, so the practical question for a new user is not "does it work" but "does the plugin I want exist, and is it still wired to a working API."

How the voice path and the render path fit together

The architecture is two processes talking to a browser window. On the Node side, sonus.js handles the audio pipeline: it listens for the wake word encoded in smart_mirror.pmdl and smart_mirror.umdl, then forwards captured speech to a recogniser. The dependency list includes @google-cloud/speech and @grpc/grpc-js, so the speech-to-text path is built around Google Cloud Speech rather than an on-device model. That matters for anyone building an offline mirror: the wake word is local, but the transcription step expects network access and, by implication, credentials for that service.

On the display side, main.js starts Electron and loads index.html, which pulls in the Angular-based app under app/. Plugins live in plugins/ and are the unit of extension. The repository also ships remote.js and a remote/ directory, which suggests a separate control surface, and motion.js, which is run with sudo and depends on johnny-five and raspi-io for GPIO access. The package.json exposes that as a separate install step rather than a default, so motion sensing is opt-in.

One consequence of the Electron choice is visible in the start script: it forces software rendering with swiftshader and disables GPU compositing. On a Pi that is a sensible default, but it means the UI is CPU-rendered, and a heavy plugin will compete with the speech pipeline for the same limited cores.

Installing on a Raspberry Pi and launching the mirror

The README gives a single quick-install path for the Raspberry Pi 2 and later. It pipes a script from the repository into bash, so read the script before running it if you care what lands on the machine.

curl -sL https://raw.githubusercontent.com/evancohen/smart-mirror/master/scripts/pi-install.sh | bash

The script is the supported entry point; the README points to a manual installation page at docs.smart-mirror.io for anyone who wants to do the steps by hand. After installation, the app is launched through the npm start script, which sets DISPLAY to :0 if it is unset and starts Electron against main.js.

npm start

On the smart-mirror screen you should see the dashboard window. To develop against it, the README documents a debug variant that attaches a developer window, and notes that ctrl-shift-i toggles that window on the mirror itself.

npm start dev

Two other scripts are worth knowing before you start. The install script runs bower through npx, and the preinstall and postinstall hooks run bash scripts/installcblas and bash scripts/fix-electron-macos, so an install is not a plain npm install. There is also a model-training entry point, npm run train-model, for anyone who wants to rebuild the wake-word model rather than use the one in the repository.

Where smart-mirror gets in your way

The biggest constraint is that the interesting parts are not in the repository. Configuration, troubleshooting and the development guide all live on docs.smart-mirror.io, and the README does not document configuration keys, plugin APIs or the shape of a plugin at all. If that site is unreachable or out of date, you are reading source. For a project whose value is the sum of its plugins, that is a real cost.

The second constraint is the speech dependency. Because transcription goes through Google Cloud Speech, a mirror with no internet connection loses voice input even though the wake word is detected locally. The README does not document an offline or self-hosted recogniser option.

The third is hardware scope. The quick install is documented for the Raspberry Pi 2 and later, and motion sensing needs a separate npm install of johnny-five and raspi-io plus sudo to run motion.js. Nothing in the repository suggests a supported path for running the mirror on a desktop as a permanent installation, and nothing suggests touch input, so a touchscreen build would be your own work.

Finally, the license field in package.json says MIT while the repository metadata carries no license identifier. That is a discrepancy worth resolving before you redistribute anything based on this code.

How it differs from MagicMirror²

The obvious alternative is MagicMirror², the other well-known open source mirror platform. The difference is where the intelligence sits. smart-mirror ships voice as a first-class concern: a wake-word model, a speech pipeline, and a sonus.js entry point you can run on its own. MagicMirror² is a module host first, with a large third-party module ecosystem and a configuration file as the primary interface.

In practice that means choosing smart-mirror buys you a voice loop out of the box and a smaller, more opinionated codebase you may end up patching. Choosing MagicMirror² buys you a broader set of ready modules and a configuration-driven setup, with voice arriving as an add-on rather than a core assumption. If your build is a display with a calendar, weather and a news ticker, the second path is less work. If the point of the build is talking to it, smart-mirror starts closer to the finish line.

Maintenance, upgrades and what the license line means for you

The repository is not archived, and the last push was on 2026-09-22, which is recent. The version in package.json is 0.0.32, and there are no retrieved releases, so upgrades happen by pulling the branch rather than by installing a tagged version. The package.json anticipates that with an update script that runs git pull followed by npm install.

npm run update

That script is also the honest description of the upgrade cost: because there are no releases to pin, an update moves you to whatever is on the branch, and the install hooks (bower via npx, installcblas, fix-electron-macos) run again. For a mirror that is working, updating is a deliberate act, not something to schedule blindly.

On licensing: the README has a License section reading "MIT", and package.json declares "license": "MIT". The repository metadata does not carry a license identifier. MIT is permissive, but if you plan to redistribute a built mirror or ship the code inside something commercial, confirm the license file situation yourself rather than relying on the metadata field. This is a description of what the files say, not legal advice.

Editorial conclusion

Adopt smart-mirror if you want a weekend-scale Raspberry Pi build and are comfortable editing files under plugins/ and app/ rather than clicking through settings. Skip it if you need a managed product, a phone app, or a touch interface, none of which the repository provides. Before buying glass, confirm two things: that the docs.smart-mirror.io configuration page still resolves, and that scripts/pi-install.sh completes on your Pi model, because the README only claims support for the Raspberry Pi 2 and later.

Frequently asked questions

Official sources

1. evancohen/smart-mirror on GitHub
2. Issues
3. Project website
4. README