Add MTA Next Train community ability

[chadnewbry]

What does this Ability do?

🚇 Adds MTA Next Train, a voice-first NYC subway arrivals ability for OpenHome. Users can save one default station for the fastest demo path, then ask things like "when's my next train?" or get more specific with line and station filters.

Suggested Trigger Words

• next train
• next subway
• when's my next train
• subway arrivals
• mta
• mta next train

Type

• New community Ability
• Improvement to existing Ability
• Bug fix
• Documentation update

External APIs

• No external APIs
• Uses external API(s): SubwayInfo.nyc for station search + live arrivals. No API key required.

Testing

• Tested in OpenHome Live Editor
• All exit paths tested (local ability flow and harness exit cases)
• Error scenarios tested (invalid station / no matches / remote fetch handling)

Local Verification

🚉 Fixture tests

• python3 -m unittest discover -s community/mta-next-train/tests -v

🚉 Ability validation

• python3 validate_ability.py community/mta-next-train

🚉 Local harness

• python3 community/mta-next-train/test_harness.py --phrase "when is the next northbound 6 train at astor place"

🚉 Live no-key endpoint check

• python3 community/mta-next-train/test_harness.py --live --phrase "next 6 train at astor place"

Example live output when tested locally:

At Astor Pl, next trains: southbound 6 in 1 minute, then 4 minutes; northbound 6 in 3 minutes, then 7 minutes.

Checklist

• Files are in community/mta-next-train/
• main.py follows SDK pattern (extends MatchingCapability, has register_capability + call)
• README.md included with description, suggested triggers, and setup
• resume_normal_flow() called on every exit path
• No print() in the ability runtime code — using editor_logging_handler
• No hardcoded API keys — using a no-key provider
• No blocked imports (redis, user_config)
• No asyncio.sleep() or asyncio.create_task() — using session_tasks
• Error handling on all external calls
• Tested in OpenHome Live Editor

Anything else?

🚆 Review route map:

• main.py keeps the OpenHome voice flow thin
• mta_next_train_core.py holds the query parsing, station matching, and SubwayInfo client
• test_harness.py gives a quick way to demo both fixture mode and live mode

🛤️ Fun demo path for review:

1. Install the ability
2. Say set my default station to Astor Place
3. Say when's my next train?

If this lands, it feels like a very clean subway-on-speakers demo: fast, specific, and zero setup friction for the user.

[github-actions]

✅ Community PR Path Check — Passed

All changed files are inside the community/ folder. Looks good!

[github-actions]

🔀 Branch Merge Check

PR direction: add-mta-next-train → dev

✅ Passed — add-mta-next-train → dev is a valid merge direction

[github-actions]

✅ Ability Validation Passed

📋 Validating: community/mta-next-train
  ⚠️  Found 5 classes — only one class per main.py is recommended
  ✅ All checks passed!

[github-actions]

🔍 Lint Results

✅ __init__.py — Empty as expected

Files linted: community/mta-next-train/main.py

✅ Flake8 — Passed

✅ All checks passed!

[uzair401]

Hello @chadnewbry, I’ve implemented several fixes and improvements across SDK compliance, trigger flow, intent parsing, and voice UX.

Trigger handling is now improved by parsing intent directly from the trigger text, allowing actions like get/set default and help to work without unnecessary prompts. Intent parsing has also been enhanced to support more natural phrasing (e.g., “in”, “for”, “per”), added fallback handling for incomplete commands, improved disambiguation with ordinal support, and resolved duplicate station name issues.

Voice UX has been refined to sound more natural and conversational by expanding EXIT_WORDS, improving exit detection, shortening prompts and responses, removing repetitive instructions, adding confirmations where needed, and replacing formal phrasing with more natural speech patterns.

There is still room for further improvement, and I encourage you to continue building on this. For example, intent extraction from trigger phrases can be made more efficient (e.g., “When is the next train from Washington Square”), and after setting a default station, queries for other stations should not fall back to the default.

I am approving it for the community. We will proceed with adopting this ability for a 30-day evaluation period to monitor performance, identify any bugs, and implement any necessary fixes or optimizations. If the ability proves stable and meets our quality standards during this period, we will move forward with publishing it to the marketplace, ensuring full credit is given to the original author for their work and contribution. We truly appreciate your effort and encourage you to continue developing and submitting new abilities. Contributions like yours help strengthen the ecosystem, and we look forward to seeing more of your work.

Please open a new PR with the updated improvements when ready.