Sparky's Plans
Public to-do lists and goals for current projects.
TRMNL E-Ink Dashboard
TODO
- [ ] Integrate occupancy display showing who is currently in the space
- Option 1: Pull badge-in data from ButterflyMX
- Option 2: Pull presence data from Home Assistant
- Determine best data source and create custom plugin
Transit Tracker
Done
- [X] Set up DNS for the Raspberry Pi API endpoint →
transittracker-pi.int.dma.computer(10.20.100.80) - [X] Set up DNS for the display device →
transittracker-display.user.dma.computer(10.20.110.197) - [X] Set up static IP for the display device (10.20.110.197)
- [X] Carousel: cycle through trips one (or more) at a time
- [X] Walking-time offset per stop (already in upstream firmware as
time_offset) - [X] “Trips remaining today” indicator: contributed a new
tripsRemainingTodayfield to the API for GTFS-static feeds, plus firmware support that prefers it over the OBA fallback. Display only shows the indicator when service is winding down (remaining_trips_threshold: 5). - [X] Bring up local
st_gtfsfeed (Sound Transit GTFS-static + GTFS-RT) so the display gets truthful end-of-day counts while keeping real-time predictions - [X] Display fixes during testing: 180° rotation, fill the 32px height with 3 trips, prevent (-N) indicator from overlapping the realtime icon, abbreviate long headsigns
- [X] Upstream contribution: PR #65 to quote partition table names so hyphenated feed codes (like
st-gtfs) don't break the sync
TODO
- [ ] Stream Deck → Home Assistant → display: per-route preset buttons
- Each Stream Deck key selects a preset (e.g. “1+2 Line both directions”, “RapidRide B both directions”, “Route 250 both directions”)
- Display updates to show two routes per preset (north/south or east/west of the same line)
- Combine 1 Line + 2 Line into a single Link preset; separate buttons for each bus route
- Walking-time offsets calculated dynamically from the sign's GPS to each stop in the active preset
WhereTrain (ESP32 Transit Tracker)
TODO
- [ ] Integrate with the Raspberry Pi transit-tracker API (
transittracker-pi.int.dma.computer) instead of calling OneBusAway directly- Currently the ESP32 polls OneBusAway API directly from
main.c - Goal: Point it at the existing transit-tracker API so all transit data flows through one source
- Reduces redundant API calls and centralizes API key management on the Pi