Better direction filtering and auto-fixing broken ones

🚀 Release Notes v0.1.6

This update makes direction filtering way easier and removes a lot of setup friction. 🙌 No more hunting down cryptic stop IDs just to configure a direction.

✨ What’s New

A) Intermediate-stop setup is now much easier: instead of manually hunting down cryptic Stop-IDs, we rebuilt the whole workflow and now guide you through a comfortable station search directly in the config flow. 🧭

B) Did you previously save an intermediate stop as plain text instead of a Stop-ID? No worries — v0.1.6 automatically fixes that for you during migration. 🔧

💬 Why this matters

Less technical setup, fewer mistakes, faster results.

Update, configure in plain language, and go. ✅

Change log

Added

• Direction filter config flow: Search by station name instead of numeric Stop-ID; multi-match dropdown; optional skip
• Auto-migration: Existing configs with Stop-Names automatically converted to Stop-IDs on setup with smart product matching
• Config input validation: excluded_stops (255 char limit, numeric IDs only) and walking_time (0-60 min bounds)

Changed

• Centralized timeout: All API calls use unified 30-second timeout (replaces hard-coded 240s/30s values)
• Direction migration reliability improved: Secondary endpoint success is now handled correctly, stop product data is preserved for matching, and previously failed migrations are retried on next setup

Fixed

• CRITICAL: Resolved HTTP 500 errors "direction must be an IBNR" caused by Stop-Names instead of numeric Stop-IDs. Fully mitigated through config flow + auto-migration

Thanks to @NikRpk for highlighting the direction issue.

v0.1.6-preview3

🚀 Release Notes v0.1.6

This update makes direction filtering way easier and removes a lot of setup friction. 🙌

No more hunting down cryptic stop IDs just to configure a direction.

✨ What’s New

A) Intermediate-stop setup is now much easier: instead of manually hunting down cryptic Stop-IDs, we rebuilt the whole workflow and now guide you through a comfortable station search directly in the config flow. 🧭

B) Did you previously save an intermediate stop as plain text instead of a Stop-ID? No worries — v0.1.6 automatically fixes that for you during migration. 🔧

💬 Why this matters

Less technical setup, fewer mistakes, faster results.

Update, configure in plain language, and go. ✅

[0.1.6] - 2026-07-09

Added

• Direction filter config flow: Search by station name instead of numeric Stop-ID; automatic validation; multi-match dropdown; optional skip
• Auto-migration: Existing configs with Stop-Names automatically converted to Stop-IDs on setup with smart product matching
• Config input validation: excluded_stops (255 char limit, numeric IDs only) and walking_time (0-60 min bounds)

Changed

• Centralized timeout: All API calls use unified 30-second timeout (replaces hard-coded 240s/30s values)
• Direction migration reliability improved: Secondary endpoint success is now handled correctly, stop product data is preserved for matching, and previously failed migrations are retried on next setup

Fixed

• CRITICAL: Resolved HTTP 500 errors "direction must be an IBNR" caused by Stop-Names instead of numeric Stop-IDs. Fully mitigated through config flow + auto-migration

v0.1.6-preview2

[0.1.6] - Upcoming

Added

• Direction filter config flow: Search by station name instead of numeric Stop-ID; automatic validation; multi-match dropdown; optional skip
• Auto-migration: Existing configs with Stop-Names automatically converted to Stop-IDs on setup with smart product matching
• Config input validation: excluded_stops (255 char limit, numeric IDs only) and walking_time (0-60 min bounds)

Changed

• Centralized timeout: All API calls use unified 30-second timeout (replaces hard-coded 240s/30s values)
• Direction migration reliability improved: Secondary endpoint success is now handled correctly, stop product data is preserved for matching, and previously failed migrations are retried on next setup

Fixed

• CRITICAL: Resolved HTTP 500 errors "direction must be an IBNR" caused by Stop-Names instead of numeric Stop-IDs. Fully mitigated through config flow + auto-migration

v0.1.6-preview1

[0.1.6] - Upcoming

Added

• Direction filter config flow: Search by station name instead of numeric Stop-ID; automatic validation; multi-match dropdown; optional skip
• Auto-migration: Existing configs with Stop-Names automatically converted to Stop-IDs on setup with smart product matching
• Config input validation: excluded_stops (255 char limit, numeric IDs only) and walking_time (0-60 min bounds)

Changed

• Centralized timeout: All API calls use unified 30-second timeout (replaces hard-coded 240s/30s values)
• Imports and type hints updated across config_flow.py, sensor.py, and init.py

Fixed

• CRITICAL: Resolved HTTP 500 errors "direction must be an IBNR" caused by Stop-Names instead of numeric Stop-IDs. Fully mitigated through config flow + auto-migration

Redundancy & Reliability Update

🎯 Highlights

✨ Dual-API Failover System (New)

Your integration is now bulletproof. We implemented a resilient failover chain to ensure maximum uptime:

🔴 Primary (v6.vbb.transport.rest)
    ↓ fails immediately
🟡 Secondary (we1external.dynv6.net:8500)
    ↓ fails immediately  
🟢 BVG Fallback API (with exponential backoff)

• No delays between failovers — instant fallback when primary goes down
• Endpoint-aware caching — separate ETags prevent API conflicts
• Stop search resilience — Config UI also uses dual-API for better UX
• Smart data retention — Last successful departures stay visible during outages

🔧 Critical Fixes

Direction Parameter Bug (HTTP 500 errors)
Fixed a showstopper where empty direction parameters were sent as direction= instead of being omitted. This caused API rejects with "direction must be an IBNR" for ~70% of sensors without direction filtering.

📊 What's New

• BVG Fallback Integration — When transport.rest is down, data flows from BVG API with smart merge of delay info
• Better Error Messages — Config UI now shows specific errors ("API rate limited", "timeout", "unreachable") instead of vague messages
• Optimized Backoff — Reduced max backoff from 15→10 minutes, smarter retry strategy
• Enhanced Logging — See which API is serving data, cache hits, merge statistics

📚 Documentation

• Updated README with dual-failover feature
• New FAQ: "What happens if the primary API fails?"
• Enhanced Troubleshooting: Failover sequence explained
• docs/liesmich.md (German): Full dual-API description

---

Need Help? Check the FAQ or Troubleshooting guides.

v0.1.5-preview9

NEW > 🔄 Automatic BVG API Fallback

When transport.rest fails, the integration automatically switches to the BVG API during backoff periods. Cached data is kept valid for up to 15 minutes and served during outages, keeping your automations running uninterrupted. Note: The BVG API has limited filtering capabilities, so you may see more results (including unfiltered departures) during fallback. But I thought seen too much data is better then seeing no data.

Fixed

• CRITICAL: Fixed API query parameter bug where empty direction values were sent as direction= (empty string) instead of omitting the parameter entirely. This caused HTTP 500 errors "direction must be an IBNR" for all sensors without direction filtering. Direction parameter is now only included when it contains a valid value.

Changed

• Set a proper User-Agent header for all API requests, dynamically built from manifest.json (version + documentation URL). Previously, transport.rest requests used the generic Home Assistant User-Agent; BVG API requests used a static placeholder string.
• Enabled BVG fallback API when transport.rest experiences outages. BVG now serves as an active fallback during transport.rest failures, applying only transport type filters (bus, subway, etc.). Direction filtering is not possible due to limitations of the API used. BVG API integration based on the work by @select.
• Smart merge of BVG delays into cached departures: When transport.rest fails but we have cached data, the integration now merges fresh delay information from BVG API into the previously filtered departures. This preserves the user's direction filtering while keeping delays up-to-date.
• Optimized backoff strategy: Reduced maximum backoff from 15 to 10 minutes. BVG fallback is now called immediately on transport.rest failure, but subsequent retries respect the backoff period (no redundant API calls every 120 seconds during backoff).
• Improved fallback logging to show the impact of transport type filters (raw departures vs. after filtering) and data merge statistics (matched/unmatched departures).
• Improved config flow error messages: When stop search fails, the UI now shows specific error details (e.g., "API rate limited", "timeout", "unreachable") and actionable guidance ("Try again in a few minutes") instead of a generic error. Also distinguishes between API failures and "no stops found" scenarios with appropriate guidance.

v0.1.5-preview8

NEW > 🔄 Automatic BVG API Fallback

When transport.rest fails, the integration automatically switches to the BVG API during backoff periods. Cached data is kept valid for up to 15 minutes and served during outages, keeping your automations running uninterrupted. Note: The BVG API has limited filtering capabilities, so you may see more results (including unfiltered departures) during fallback. But I thought seen too much data is better then seeing no data.

Changed

• Set a proper User-Agent header for all API requests, dynamically built from manifest.json (version + documentation URL). Previously, transport.rest requests used the generic Home Assistant User-Agent; BVG API requests used a static placeholder string.
• Enabled BVG fallback API when transport.rest experiences outages. BVG now serves as an active fallback during transport.rest failures, applying only transport type filters (bus, subway, etc.). Direction filtering is not possible due to limitations of the API used. BVG API integration based on the work by @select.
• Smart merge of BVG delays into cached departures: When transport.rest fails but we have cached data, the integration now merges fresh delay information from BVG API into the previously filtered departures. This preserves the user's direction filtering while keeping delays up-to-date.
• Optimized backoff strategy: Reduced maximum backoff from 15 to 10 minutes. BVG fallback is now called immediately on transport.rest failure, but subsequent retries respect the backoff period (no redundant API calls every 120 seconds during backoff).
• Improved fallback logging to show the impact of transport type filters (raw departures vs. after filtering) and data merge statistics (matched/unmatched departures).
• Improved config flow error messages: When stop search fails, the UI now shows specific error details (e.g., "API rate limited", "timeout", "unreachable") and actionable guidance ("Try again in a few minutes") instead of a generic error. Also distinguishes between API failures and "no stops found" scenarios with appropriate guidance.

v0.1.5-preview7

NEW > 🔄 Automatic BVG API Fallback

When transport.rest fails, the integration automatically switches to the BVG API during backoff periods. Cached data is kept valid for up to 15 minutes and served during outages, keeping your automations running uninterrupted. Note: The BVG API has limited filtering capabilities, so you may see more results (including unfiltered departures) during fallback. But I thought seen too much data is better than seeing no data.

Changed

• Set a proper User-Agent header for all API requests, dynamically built from manifest.json (version + documentation URL). Previously, transport.rest requests used the generic Home Assistant User-Agent; BVG API requests used a static placeholder string.
• Enabled BVG fallback API when transport.rest experiences outages. BVG now serves as an active fallback during transport.rest failures, applying only transport type filters (bus, subway, etc.). Direction filtering is not possible due to limitations of the API used. BVG API integration based on the work by @select.
• Smart merge of BVG delays into cached departures: When transport.rest fails but we have cached data, the integration now merges fresh delay information from BVG API into the previously filtered departures. This preserves the user's direction filtering while keeping delays up-to-date.
• Optimized backoff strategy: Reduced maximum backoff from 15 to 10 minutes. BVG fallback is now called immediately on transport.rest failure, but subsequent retries respect the backoff period (no redundant API calls every 120 seconds during backoff).
• Improved fallback logging to show the impact of transport type filters (raw departures vs. after filtering) and data merge statistics (matched/unmatched departures).
• Improved config flow error messages: When stop search fails, the UI now shows specific error details (e.g., "API rate limited", "timeout", "unreachable") and actionable guidance ("Try again in a few minutes") instead of a generic error. Also distinguishes between API failures and "no stops found" scenarios with appropriate guidance.

v0.1.5-preview11

🚀 v0.1.5 - Redundancy & Reliability Update

🎯 Highlights

✨ Dual-API Failover System (New)

Your integration is now bulletproof. We implemented a resilient failover chain to ensure maximum uptime:

🔴 Primary (v6.vbb.transport.rest)
    ↓ fails immediately
🟡 Secondary (we1external.dynv6.net:8500)
    ↓ fails immediately  
🟢 BVG Fallback API (with exponential backoff)

• No delays between failovers — instant fallback when primary goes down
• Endpoint-aware caching — separate ETags prevent API conflicts
• Stop search resilience — Config UI also uses dual-API for better UX
• Smart data retention — Last successful departures stay visible during outages

🔧 Critical Fixes

Direction Parameter Bug (HTTP 500 errors)
Fixed a showstopper where empty direction parameters were sent as direction= instead of being omitted. This caused API rejects with "direction must be an IBNR" for ~70% of sensors without direction filtering.

📊 What's New

• BVG Fallback Integration — When transport.rest is down, data flows from BVG API with smart merge of delay info
• Better Error Messages — Config UI now shows specific errors ("API rate limited", "timeout", "unreachable") instead of vague messages
• Optimized Backoff — Reduced max backoff from 15→10 minutes, smarter retry strategy
• Enhanced Logging — See which API is serving data, cache hits, merge statistics

📚 Documentation

• Updated README with dual-failover feature
• New FAQ: "What happens if the primary API fails?"
• Enhanced Troubleshooting: Failover sequence explained
• docs/liesmich.md (German): Full dual-API description

---

Need Help? Check the FAQ or Troubleshooting guides.

v0.1.5-preview10

NEW > 🔄 Automatic BVG API Fallback

When transport.rest fails, the integration automatically switches to the BVG API during backoff periods. Cached data is kept valid for up to 15 minutes and served during outages, keeping your automations running uninterrupted. Note: The BVG API has limited filtering capabilities, so you may see more results (including unfiltered departures) during fallback. But I thought seen too much data is better then seeing no data.

Fixed

• CRITICAL: Fixed API query parameter bug where empty direction values were sent as direction= (empty string) instead of omitting the parameter entirely. This caused HTTP 500 errors "direction must be an IBNR" for all sensors without direction filtering. Direction parameter is now only included when it contains a valid value.

Changed

• Set a proper User-Agent header for all API requests, dynamically built from manifest.json (version + documentation URL). Previously, transport.rest requests used the generic Home Assistant User-Agent; BVG API requests used a static placeholder string.
• Enabled BVG fallback API when transport.rest experiences outages. BVG now serves as an active fallback during transport.rest failures, applying only transport type filters (bus, subway, etc.). Direction filtering is not possible due to limitations of the API used. BVG API integration based on the work by @select.
• Smart merge of BVG delays into cached departures: When transport.rest fails but we have cached data, the integration now merges fresh delay information from BVG API into the previously filtered departures. This preserves the user's direction filtering while keeping delays up-to-date.
• Optimized backoff strategy: Reduced maximum backoff from 15 to 10 minutes. BVG fallback is now called immediately on transport.rest failure, but subsequent retries respect the backoff period (no redundant API calls every 120 seconds during backoff).
• Improved fallback logging to show the impact of transport type filters (raw departures vs. after filtering) and data merge statistics (matched/unmatched departures).
• Improved config flow error messages: When stop search fails, the UI now shows specific error details (e.g., "API rate limited", "timeout", "unreachable") and actionable guidance ("Try again in a few minutes") instead of a generic error. Also distinguishes between API failures and "no stops found" scenarios with appropriate guidance.