Hardware: Raspberry Pi Pico 2, TM1637 4-digit 7-segment display, two pushbuttons, Li-ion battery pack, 3D-printed enclosure.

Software: Custom MicroPython firmware controlling the display, button inputs, and animations.

Status: Prototyping complete — core display and button logic working on breadboard. Increment/decrement animations implemented, including “LUCH” boot animation, “5-flash” max indicator, and dramatic 1d4 reroll sequence when attempting to add a point above 5. Preparing to wire four identical units and design/print final case with panel-mounted buttons.

Next Steps:
1. Test wiring for 4× unit build.
2. Design 3D-printed enclosure with button mounts and display window.
3. Assemble battery-powered prototypes.
4. Field test at game table.

✅ Current Status

• Stable: Feature set is working well in live games with no blocking issues.
  
• Core functionality: Encounter management, combatant tracking, GM and Display views, bulk actions, import/merge staging, conditions, health bars, and save/load are all functional and tested.
  
• Recent improvements:
  • Fixed initiative order reset bug when removing combatants.
    
  • Bulk remove action added.
    
  • MonsterRepo now handles monsters.json cleanly (deduplicated, fixed save issues).
    
  • GM View styling updated (panelized “cockpit” layout, larger fonts, quicker access to Advance/Back).
    
  • Display View status bar added (shows conditions, with concentration called out).
    
  • Auto-refresh improvements (live updates for most actions, reduced flashing).

🔧 Known Issues / Polishing Needed** - Undo/Redo: UI visible, but stack not consistently updating across all actions. Needs refinement.
-Live refresh gaps: Certain updates (e.g. HP adjustments, condition changes) still require Advance before Display View reflects them.
-Condition icons/text: Current symbols are hard to read at table distance; need clearer, higher-contrast notation.
-monsters.json: Patched and stable, but long-term goal is to replace with external Artisanal DB.

🛣️ Roadmap v1.1 (Immediate polish) - Fix refresh gaps (HP/conditions update instantly).
- Improve readability of condition indicators (superscripts, bold/colored tags).
- Larger Display View “Now Acting + Initiative” area for table visibility.
- Small styling polish for GM View (restore bigger fonts, confirm shortcut keys).

v1.1.1 / v1.2 (PC death saves & tracker polish) - GM View: Add “Fail Save” / “Success Save” buttons for PCs in dying state.
- Auto-track successes/failures, stabilize or kill at 3 checks.
- Display View: Portrait overlays fade redder as saves fail.
- <title> in Tracker View shows round number (e.g. "Darkmoor – Round 5").

v2.0 (Major upgrade: Turnwright) - App rename: “Encounter Tracker” → Turnwright (service, repo, backups, README, page titles).
- Artisanal DB integration: Replace monsters.json with live 5eADB queries.
- Filtering UI for monster type, CR, tags, source.
- Optional encounter “phases”: preload staged waves, click-to-add mid-combat.
- Exportable encounter logs (per-session summaries).
- Optional wireless “Done” button (GPIO / BLE remote) to advance turns.

Hardware: Raspberry Pi (likely same one as DNS)

Software: Home Assistant, possibly Node-RED/MQTT

Features:
- Control WLED devices & Pico 2W tavern LEDs
- Integrate with Apple Home via HomeKit Bridge
- Future: smart bulbs, sound effects, coordinated scene triggers
- Status: Planning phase; software stack identified

Purpose
- 24/7 FM broadcast within property limits
- Curated Apple Music playlists with TTS track announcements
- Future AI-DJ: recap last few songs, tease upcoming tracks

Hardware
- CanaKit Raspberry Pi 5 (8 GB) Starter Kit PRO
- Behringer U-Control UCA222 USB audio interface
- UGREEN 3.5 mm → RCA cable to C.Crane Digital FM Transmitter 3
- TP-Link Omada ES220GMP 16-port PoE+ managed switch
- Cat6 patch cables (1’, 3’, 5’) color-coded by device type

Networking
- ES220GMP as primary closet switch, PoE+ powering the Pi5-radio
- Local DNS entries for consistent naming (radio.home.arpa)

Software (implemented)
- MPD for playback engine
- Flask-based web UI for control/search (play/pause/skip, queue, shuffle, volume)
- “Shows” system via shows.json + program clock: time-of-day playlists by genre/artist
- Web editor for shows (name, schedule, include/exclude filters)
- Reseed button to apply changes instantly without interrupting current song
- rsync-based Mac → Pi sync script for updating library, excluding protected .m4p

Current Status
- FM broadcast working across property, transmitter placement under test
- Web UI functional with Now Playing, Up Next, Library search, and Show banner
- Show editor live: can define time windows and filters (genres/artists)
- Sync pipeline established from MacBook → Pi via rsync
- Verified MPD reads embedded tags (artist, album, genre) from .m4a files
- First working genre-based program schedule running (e.g. Electronic + Daft Punk, Vangelis)

Next Steps
1. Improve tag consistency on MacBook (genre cleanup in Music.app or Kid3)
2. Extend Flask UI with a debug view (show → matching tracks)
3. Add lightweight logging of rsync + MPD genre stats after sync
4. Experiment with transition handling (bumper padding, end-time alignment)
5. Revisit antenna placement to maximize FM coverage without drift

Future Enhancements
- AI-DJ running on Mac mini with Ollama (announce last/next tracks)
- Guest “Now Playing” / request portal (Pi Zero kiosk or browser-based)
- Integration with Game Table Lighting Control Hub for scene/audio sync
- Audioreactive LED tie-in (via Dig-Uno + WLED)

Purpose
The project will deliver a video “wall” (36”X42”) of LEDs that can be triggered for mood effects during D&D games and that, otherwise, can present an audioreactive display for music playing in the wall’s vicinity.

Hardware
- Quinled Dig-Uno ESP32-based WLED controller - Mean Well LRS-200-5 power supply - 2812E LED strips (total 10 meters) - commodity lumber for the frame - Custom fabric cover

Software
- WLED project running on Dig-Uno

Current Status
- Dig-Uno running in 3D-printed case, powered by Mean Well - Strips cut to 53-LED lengths and 3-pin connectors soldered - Basic segment configuration defined for 9 segments - Fabric cover (wolf mural) received - Audioreactive microphone… initially tried to connect small digital mic. Never could get it to work, likely due to my poor soldering skills (a recurring theme). However, purchased analog mic and is now working well. - An intermittent flash began to occur with any type of animation. Worried that I had a wiring problem, but unplugging different legs of the install did not improve the flash. Reset Dig-Uno WLED to factory settings and reconfigured strips & segments and no flash! - Built frame. Like a dope, I cut the backboard to exactly (I mean… amateur woodworking exactly) 42” X 36” to accommodate the 53-LED strips… and then mounted the wooden frame pieces which shrunk the internal backboard space. Something I told myself to take into account, but did anyway. - 3D-printed clear PETG diffuser strips and fitted LED legs into the strips, SuperGlued diffuser to backboard… and it looks pretty good!

Next Steps
- Still thinking about how to attach Wolf mural and (probably) some more everyday cover. Adhesive-backed magstrips did not satisfactorily adhere to metal washers; washers suck at magnetism. Applied some metal strips which work better, but adhesive sucks at sticking metal to wood and my drill bits suck at cutting through 1/4” steel. Evaluating options.

Updated: 2025-09-26

Future Enhancements
- Integrate with Game Table Lighting Control Hub project

Purpose Using a local AI create unique virtual DJs that select songs and introduce them verbally as well as react to music requests and give home-specific PSAs. The project: - Inserts short spoken interludes between tracks (Stephen Hill–style ambient guide).
- Builds deliberate playlists (“shows”) instead of relying on MPD shuffle.
- Runs on the Mac Mini (dj account) and integrates with Pi5 for playback.

Hardware
- Apple Mac Mini (M4, 32 GB RAM, 512 GB SSD) – running AI-DJ logic and voice generation
- Raspberry Pi 5 (“radio”) – MPD/Liquidsoap/FM transmission
- Local LAN / Wi-Fi connection between mini and Pi5

Software
- macOS 15, dj user with per-user Homebrew + Python venv
- Python 3.12 (python-mpd2, mutagen, typer, rich)
- show_planner.py (prototype script to own MPD queue)
- MPD configured to bind on LAN (port 6600)
- SSH key auth (dj@mini → macuser@radio)
- Homebrew tools (per-user): mpc, nc, etc.

Next Steps
- ✅ Establish dj account and venv on Mac Mini
- ✅ Configure MPD on Pi5 for LAN access
- ✅ Build/test show_planner.py to generate ~30-min sets
- ⏳ Integrate Ollama (or other LLM) to generate playlist plans
- ⏳ Add TTS pipeline for voice stingers / commentary clips
- ⏳ Schedule planner runs via LaunchAgent (nightly or timed “shows”)
- ⏳ Develop “listener request/dedication” flow (insert forced lines)
- ⏳ Document end-to-end pipeline for backup & reproducibility

Future Enhancements
- Integrate with Game Table Lighting Control Hub project

Purpose
In this project, I’m updating the Raspberry Pi Zero that serves up my initiative tracking app (TurnWright) during game nights, to give it a second boot option of running a 2X2 dashboard of performance monitors for 4 different Raspberry Pis so the Pi & Monitor serve some purpose on non-game nights

Hardware
Raspberry Pi Zero 2W in 3d-printed case connected to 32” monitor on VESA-mount stand with casters. Attached to the same stand is my old, old Raspberry Pi B and a portable ASUS 14” display which serves up images (maps, NPCs, etc) at the game table, served via http from a Pi 3.

Software
- Raspberry Pi Lite (Debian Bookworm) - tmux - Glances - Chromium

Current Status
- Boot Menu: Added 30-second chooser at tty1 (default = Kiosk / Chromium, option 2 = System Monitor).

• Autologin Fix: Cleaned up getty@tty1 unit override → Pi0 now autologins directly as macuser and launches the chooser.

• Chromium Kiosk:   Re-experienced the “fun” of Chromium’s almost inescapable warning that “It is not recommended to run Chromium on devices with less than 1GB of RAM.” What’s the fix? Is it adding “–disable-low-memory-monitor” in .xinitrc? No. At least not by itself. Is it adding “–test-type” to .xinitrc? Same answer. The fix-fix? Call the chromium binary (likely at - /usr/lib/chromium/chromium or /usr/lib/chromium-browser/chromium-browser) rather than the wrapper script. e.g. “CHROMEBIN=””

  for p in /usr/lib/chromium/chromium /usr/lib/chromium-browser/chromium-browser $(command -v chromium || true); do

    [ -x “$p" ] && CHROMEBIN="$p” && break

  done” Also had issue with screen resolution in Chromium. Also also had issue with failed HDMI standard-Mini adapter. Also also also had issue with Glances version mismatch (3.3.1.1 on Pi0; 4.3.3 on the other Pis it is polling). Implemented Glances 4.3.3 (via venv in ~/venvs/glances433).  

Had brief issue, when trying to add functionality to quit the entire Glances session with a single “q” that one of the boxes I’m polling (my new Pi 3b that will be time-lapse video box) was powered off, and since it’s session failed, the entire dashboard failed.

Now running smoothly. Boots to option menu; defaults (in 30 seconds) to boot Chromium and TurnWright display; hitting “2” within that window boots to CLI and the 2X2 Glances dashboard.

Future Enhancements

• Add small UX improvements to chooser script (clearer messages, maybe countdown timer bar).
• Physical Switch:** Hardware toggle (GPIO or USB button) at boot to select Kiosk vs. Monitor instead of keyboard input.
• Ansible Integration:** Automate venv creation and pinned Glances deployment across all monitored Pis (ensure version lockstep).
• Minimal Browser Option:** Evaluate lighter alternatives to Chromium (e.g. surf, kweb) for kiosk mode on low-RAM Pi0.
• Monitoring Expansion:** Consider Grafana/Prometheus stack on Pi5 for longer-term stats; keep Pi0 as lightweight display node.

Updated: 2025-09-17

Purpose Add external camera to capture time-lapse of Bambu A1 (and possibly, via a 2nd camera A1-mini). May add 2nd (3rd?) camera to see status of AMS… which spools are connected, how much filament is left, etc. May also use Pi for other needs in garage.

Hardware
Raspberry Pi 3B in Flirc aluminum case (due to summer temps), existing Logitech webcam. Learned an important lesson about building the Pi while waiting for the case, and then installing in case with SD card still in Pi. Short version: don’t. Camera is currently just sitting on a plastic container. I’d like to get/print an arm with tripod mount to suspend the camera over the printer and get it off the floor.

Software
- Raspberry Pi OS(Debian Bookworm) - MotionEye – cool package! Used https://github.com/motioneye-project/motioneye#installation and no issues at all! - Custom script for copying files to Macbook (via ChatgPT) - Added to Glances dashboard, but Glances took a lot of Mem; so currently doing a Top snapshot and adding the results to tmux Glances via ssh

Current Status
In production. No issues.

Next Steps
Get camera off floor! Possible custom fan option to blow on Flirc case; though it’s pretty stable at ~45C even though it’s currently 90F outside! Might add another camera or two for A1-mini and AMS.

Updated: 2025-09-21

Build Variants Two prototypes will be developed: 1. Large Mirror (first option)

Hardware:: Adafruit ESP32-S3 Feather (4 MB Flash / 2 MB PSRAM) paired with the Adafruit 2.4″ TFT FeatherWing V2 touchscreen (using only the display + SD slot).

Features: - MicroSD storage for multiple portraits/animations. - FeatherWing form-factor simplifies stacking. - Powered by USB-C or 500–1200 mAh Li-ion via JST. - Use Case: Mounted in terrain as a wall-sized mirror for dramatic reveals.

2. Compact Mirror (alternate option)

• Hardware: Adafruit QT Py S3 (2 MB PSRAM) driving the Adafruit 1.47″ 320×172 round-rect ST7789 TFT.
• Features:
• Very small footprint, ideal for embedding in miniature props or handheld mirrors.
• Requires manual SPI wiring between QT Py and TFT.
• Assets stored in flash or on an external SPI microSD breakout (if needed).
  
• Use Case: More subtle or portable “magic hand mirror” for NPC props or close-up reveals.

Shared Elements

• Trigger options: pushbutton, reed switch + magnet, or proximity sensor.

Software: - CircuitPython with displayio + gifio for simple animation → static image transitions. - Terrain design: 3D-printed bezels with 1 mm lip to frame displays; optional one-way mirror film to complete illusion. - Power: USB-C for setup; Li-ion for wireless runtime (≈3–8 hrs depending on battery)

Status - Hardware received. Started with “compact mirror” (number 2 above.). Soldered connections on each… not well. Struggled with ST7789 driver in CircuitPython but got that worked out. However, while backlight turns on, display isn’t working properly. There’s at least one loose wire on TFT. Will likely remove and resolder entire TFT; stranded Dupont wires too messy on this project!

Next steps: design and print terrain enclosures sized for both screen types, allowing service access to SD/battery.

Updated: 2025-09-26

Hardware - Raspberry Pi 4 (2–4 GB model sufficient). - MicroSD card with Raspberry Pi OS or LibreELEC. - Wi-Fi (built-in). - HDMI output to projector. - Optional: small case, remote control app, or wireless keyboard.

Software Options - feh: simple, lightweight slideshow tool for looping images. - Kodi (LibreELEC): full media center with support for slideshows, video playlists, and remote control from phone. - mpv: for looping video files.

• Hardware: Raspberry Pi 3B
  
• Software: dnsmasq
  
• Features:
  • Local hostname resolution for LAN devices
  • Support for multiple aliases per host
  • Integrated with eero mesh network
    
• Status: Fully deployed & stable; optional automation features under consideration