Why this exists

RFID tags & music albums

How to play a music album by tapping an RFID/NFC tag — a physical “remote control” for the music system that anyone in the house can use without a phone or a voice command.

Why this exists

Voice control needs a working mic and a network; the HA dashboard needs a phone. A tag taped to a bookshelf, a record, or the side of the music room door works for everyone, including kids and guests. Tap the tag, and the album it represents starts playing — no app, no speaking, no configuration.

Hardware

• Reader: a USB or serial MIFARE/NFC reader. The reader is connected to a small always-on computer or microcontroller that runs Home Assistant (or a companion integration that talks to it over the network).
• Tags: cheap MIFARE Classic (1 kbit) sticker tags. Each tag has a unique 4-byte UID, which is all HA ever needs — the tag contents are irrelevant, the UID is the identifier.
• The reader integration exposes each tap as a state change (or event) you can trigger on. If the reader is on a separate box, it publishes the UID to HA (e.g. via MQTT or a custom component); if it is on the HA box itself, the integration handles it directly.

The practical detail is where the reader plugs in. The simplest arrangement is a reader on the same machine (or LAN box) that runs the music server, so taps are visible to HA without extra wiring.

Concept: one tag = one album

Each tag’s UID maps to exactly one album. The mapping lives in one place — a YAML dict in the automation (or a template sensor) — so adding an album is a one-line change:

tag_map:
  '04:12:34:56': 'Abbey Road'      # UID -> album
  '04:9a:bc:de': 'Dark Side of the Moon'

A small template sensor turns the raw reader state into a readable “album tapped” value (or unknown), which makes testing and the debug log pleasant: instead of staring at UIDs, the log says which album.

Automation

alias: 'Media:Album Tag'
trigger:
  - trigger: state
    entity_id: sensor.rfid_reader
    to:
      - '04:12:34:56'   # or: any, if the template sensor does the lookup
condition:
  - condition: template
    value_template: >-
      {{ trigger.to in [ '04:12:34:56', '04:9a:bc:de' ] }}
action:
  - action: media_player.play_media
    target:
      entity_id: media_player.music_room_speakers
    data:
      media_content_id: 'mpd:album:Abbey Road'
      media_content_type: 'music'
mode: single

Design points:

• mode: single — a double-tap should not queue two albums.
• play_media with the library’s URI scheme (e.g. mpd:album:... for MPD, or a Jellyfin/Plex item ID) — the exact URI depends on which music integration serves the library.
• If you want “tap again to stop”, check the current media_content_id / state first: same album playing → media_player.stop, otherwise start the tapped album.

Tips & tricks

• Sticky-note the mapping. A small printed UID → album table next to the shelf makes debugging obvious (“this tag is DSOTM”).
• One tag per album, not per song — tapping is a coarse interaction; an album is a natural unit. If you want songs, that’s a job for the phone app.
• Test with the state change, not the tap. Reproduce the trigger from Developer Tools → Actions by setting the reader sensor to the tag’s state; it separates “reader not talking to HA” from “automation wrong”.
• Tags are not secure. Anyone who can read a UID can replay it (a phone with NFC can copy a MIFARE Classic UID). That’s fine for “play the music”; do not use the same mechanism for arming/disarming alarms without a second factor.
• Clustering: if you run an HA cluster, gate the automation on input_boolean.active so the standby doesn’t also start playback — see High Availability.

Related

• Automating with Google Home & HomeKit
• High Availability

Source Disclaimer

• AI Generated
• Human Generated
• AI Edited
• Human Edited