Never Missing the Train Again

Original Article ↗ Hacker News Discussion ↗

Hobbyists are repurposing Kindles, tablets, and small displays into always‑on transit boards that show the next nearby buses and trains at a glance, often powered by public GTFS/real‑time APIs. Commenters weigh this DIY, wall‑mounted approach against existing phone apps like Transit, Citymapper, and OneBusAway, citing trade‑offs around convenience, data privacy, and how well different systems expose or interpret live vehicle data. The thread also highlights broader issues in public transport tech, from inconsistent realtime accuracy and limited APIs in some countries to the lack of official “kiosk mode” support on e‑ink devices and opportunities for open‑source tooling.

Physical next‑departure displays

  • Many commenters like always‑on, glanceable displays at home, especially when services run every 10–20 minutes.
  • People describe similar setups using Tidbyt, Home Assistant on repurposed tablets, Raspberry Pi screens, Arduino/TFT, and custom LED/physical departure boards.
  • Several emphasize that a wall display reduces “phone friction” and avoids the distraction of opening an app.

Kindle and e‑ink implementation details

  • Some note you can use the Kindle’s built‑in browser plus disabled screensaver to show a webpage, avoiding jailbreak and image rendering.
  • Others report that debug commands like ~ds to disable sleep have been removed on newer firmware; older Kindles remain more hackable but lack updates and store access.
  • HTTPS certificate issues on older devices mean many users would host a local server.
  • There’s interest in an official “kiosk mode” for old Kindles as a sanctioned reuse path.

Existing transit apps and alternatives

  • Multiple apps already provide “next departures near me”: Transit, Citymapper, Apple/Google Maps, local agency tools, and various open‑source projects (e.g., OneBusAway, Öffi, region‑specific apps).
  • Enthusiasts praise some UIs and features (widgets, mixed‑mode routing, local‑first design) but others object to extensive data sharing with third parties.

Data sources and realtime reliability

  • Many agencies expose GTFS/GTFS‑Realtime APIs; some are praised for good API design, others for poor or missing feeds.
  • Experience with realtime accuracy is mixed: some say predictions are “to the minute,” others describe buses appearing when apps say they’re minutes away or “delayed.”
  • Explanations offered include GPS dropouts, traffic variability, and differences between schedule‑based vs. GPS‑based predictions.

Design, language, and implementation debates

  • Some argue a simple “next few departures” view solves everyday, routine travel better than full route planners; others say they always need multimodal, alternative‑aware trip planning.
  • There’s a side debate over “buses” vs. “busses” as the plural of “bus.”
  • A few question using Rust and PNG rendering instead of a browser and simpler languages, while others stress that the main gains came from architectural changes (dropping headless Chrome) rather than language choice.