Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
| members:sparky:plans [2026/01/10 23:28] – created Sparky | members:sparky:plans [2026/09/14 23:54] (current) – Sparky | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| # Sparky' | # Sparky' | ||
| - | | + | Public to-do lists and goals for current projects. |
| - | | + | ## TRMNL E-Ink Dashboard |
| - | ### TODO | + | <WRAP alert> |
| - | - [ ] Integrate occupancy | + | **Deprecated.** The space runs a different e-ink display |
| - | - Option 1: Pull badge-in data from ButterflyMX | + | </ |
| - | - Option 2: Pull presence data from Home Assistant | + | |
| - | - Determine best data source and create custom plugin | + | |
| - | | + | ### 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 |
| - | - [ ] Set up DNS for the Raspberry Pi API endpoint | + | |
| - | | + | ### Done |
| - | - Goal: `transit-tracker.int.dma.space` (int.dma.space is for member projects not on the services rack) | + | - [X] Set up DNS for the Raspberry Pi API endpoint |
| - | - [ ] Set up DNS for the display | + | - [X] Set up DNS for the display device → `transittracker-display.user.dma.computer` (10.20.110.197) |
| - | - Current: `10.20.110.197` | + | - [X] Set up static IP for the display device (10.20.110.197) |
| - | - Goal: `transit-display.int.dma.space` | + | - [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 `tripsRemainingToday` field 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: | ||
| + | - [X] Bring up local `st_gtfs` feed (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: | ||
| + | - [X] Stream Deck preset buttons: a 15-key Stream Deck on the Pi runs [streamdeck-transit](https:// | ||
| + | - [X] Presets in place: Link (1 Line + 2 Line combined), Bus 8, Bus 10, Bus 12, First Hill Streetcar | ||
| + | - [X] Walking-time offsets calculated from the sign's GPS to each stop in the active preset (`sign_location` + `walk_speed_ms`), | ||
| + | - [X] Display power and brightness exposed to Home Assistant (`switch.hangout_transit_tracker_cycling_display_power`, | ||
| + | - [X] Fixed a King County Metro outage: a `sync_lock` row orphaned since July blocked that feed from syncing for 60 days, its schedule data expired, and every KCM route went blank. Forced a resync and restarted the API to clear cached empty results. | ||
| + | |||
| + | ### TODO | ||
| + | - [ ] Ship the API fixes for that outage: reclaim sync locks older than six hours, and retire a feed's cached data after an import so a resync | ||
| + | - [ ] Flip the walking pip sign from `+7w` to `-7w`; `-` matches the actual math (arrival minus walk equals leave-by) | ||
| + | - [ ] Use the spare matrix row as a header showing the active preset name, so it is obvious which preset is on screen | ||
| + | - [ ] Return the Orange Pi lent for the button project. The Stream Deck runs on the existing transit Pi, so it was never needed. | ||
| + | - [ ] Label the Stream Deck keys physically, or add a legend nearby, so the presets are usable without asking anyone | ||
| + | |||
| + | ## Big LED Signs (transit display embiggening) | ||
| + | |||
| + | Two salvaged LED signs are earmarked | ||
| + | Asks and offers collected in #facilities > "next train display | ||
| + | |||
| + | ### Done | ||
| + | - [X] Identified sign 1: iNOVA C08160S2, two lines of 160x8, a call-center wallboard. Recovered 12 original PDFs from the Wayback Machine; | ||
| + | - [X] Confirmed the RJ11 "net in" jack is an RS485 daisy-chain port, 9600 baud by default, not a phone line | ||
| + | - [X] Identified sign 2: Adaptive ALPHA 9200TRI, tri-color. Its protocol is public (Adaptive doc 9708-8061) and the python | ||
| + | - [X] Established a fallback for the iNOVA: its native command set is not published anywhere, so the panels can be driven directly instead, per the eyadid/ | ||
| + | - [X] A USB to RS485 adapter was donated and is at the space, on top of the yellow rack | ||
| + | |||
| + | ### TODO | ||
| + | - [ ] Collect the donated RS485 adapter from the yellow rack | ||
| + | - [ ] Find a sacrificial RJ11 cable and try talking to the iNOVA sign at 9600 baud | ||
| + | - [ ] Get the ALPHA 9200TRI into the space. It currently fails self-test and its fan is very loud, though all the LED panels light. Then try `alphasign` over the Lantronix bridge (data on TCP 3001, config via telnet on 9999). | ||
| + | - [ ] Decide where it mounts. Suggestions so far: above the cork board, or roughly 8ft up on the north wall above the toolbox. | ||
| + | - [ ] Pick which sign to target first. The ALPHA is far less work because its protocol is documented. | ||
| + | |||
| + | ### Layout requests from the thread | ||
| + | - [ ] Show four trains at once, which the current 32px display | ||
| + | - [ ] Put a clock on it. The existing space clock is unpopular. One suggestion was trains on the left, clock on the right. | ||
| + | - [ ] Colocate with the 1+2 line PCB so all the transit displays live in one area | ||
| + | - [ ] Scrolling messages on the two-line sign rather than static text | ||
| + | - [ ] A "days since someone tried to drive on the track" counter | ||
| + | |||
| + | ## 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 | ||
| - | --- | ||