v3.0.0 - Bike stations & refined departure card

Naolib bike stations arrive, and the departure card gets a clearer, better coloured layout.

Bike stations

• New "bike station" config entry: pick a station on the map or search it by name, exactly like a stop.
• Two sensors per station: available bikes and free docks, with the payment terminal and the last update as attributes.
• Dedicated naolib-bike-card Lovelace card and its visual editor: live counts, out-of-service banner, and an optional list of nearby stations with their distance.
• Station names are spelled like stop names, and docks are marked with a rhombus so they never read as bikes.
• Diagnostics cover bike entries as well.

Next departures

• Everything under a departure is regrouped into a single tinted strip: the clock the countdown stands for, the following passage, and the "last of the day" marker. The tint carries the state, so a delay or a last departure reads without being parsed.
• The next passage time is now bold and in the primary text colour, distinct from the following one in parentheses.
• Line badges are coloured from the official GTFS palette instead of a hand-kept list, so every line — bus, tram, busway, navibus — gets its real colour.
• Entity pickers in the editors are narrowed to the relevant domains, and the misleading reading timestamp is gone.

Under the hood

• compose.yaml ships with the repository: docker compose run --rm python (ruff + pytest) and docker compose run --rm node (eslint + vitest + build) run the suites without a local toolchain.
• The card frontend gains a src/bike module and a shared entity helper; 88 JS tests.
• Python tests cover the bike coordinator, the config flow and the setup paths, 100% coverage maintained.

v2.7.0 - Redesigned card and schedules for the following days

Card display redesign and day-by-day navigation in schedules.

Next departures

• Departures now become tiles (line badge, destination, transport mode) instead of dense rows.
• Delay/early badges are replaced by a crossed-out scheduled time / actual time pair: the absolute passage time is always visible, in red if the vehicle is late, in green if it is early.
• The "last passage" marker remains displayed next to the time.

Timetable view

• Line badges are moved up into the header: one less vertical section.
• The direction is announced as a destination (→ Direction / Terminus), with a reverse button to switch to the opposite terminus.
• "Next HH:MM · in X min" banner above the grid.
• New day selector ‹ Wednesday, August 5 ›: navigation up to D+6, with the date written out in full and a relative label (Today / Tomorrow / Day after tomorrow / In N days). When switching to another day, nothing is grayed out and the banner announces the first departure of the day. Schedules are cached per day.
• The highlighted time follows the next passage rather than the current clock: at 5:57 PM with a passage at 6:05 PM, the 6 PM block is highlighted.

Configuration

• Adding a stop now offers two methods: search around a location on the map (like before) or search by name, ignoring case and accents (comme finds Commerce).

Under the hood

• The card frontend is split into modules (src/render, src/styles, src/time.js) and covered by a vitest suite (57 tests) executed in CI.
• The naolib/get_data WebSocket command accepts a day_offset (0-6) and returns the served date.
• 64 Python tests, 100% coverage.

v2.6.0 - Configurable card, action & silver quality scale

A large release: the integration was reworked from the inside out, the card became configurable, an action was added, and the quality scale moved from bronze to silver.

Performance

• A single coordinator polls the whole Naolib network once per interval and every stop filters it locally, so the rate-limited endpoint is hit once whatever the number of stops you follow.
• SIRI responses are parsed off the event loop, and only the quays of your stops are turned into objects.
• The theoretical timetables moved from one large JSON file to a SQLite database read one station at a time.

Dashboard card

• A visual editor, with filters on lines, on direction and on walking time (hides the departures you can no longer catch), a compact mode and a limit on the number of rows displayed per direction.
• The card measures its own height, so the timetable view is never clipped and no empty space is left below the departures.
• Delays against the theoretical timetable and the last passage of the day are shown next to the time they describe.

Action

naolib.get_departures returns the filtered departures of a stop for your scripts and templates, with lines, direction, walk_time and limit parameters.

Quality scale: silver

• Every module of the integration is covered at 100% (57 tests), config flow included.
• An API outage is logged once when the feed goes away and once when it comes back, instead of staying silent.
• ruff, eslint and the test suite run in CI.

Upgrading

Nothing to do: the entities, their attributes and the card keep working. If you tried a 2.6.0 pre-release and set max_departures on a card, the option is now max_lines and applies per direction; set it again from the card editor.

Full changelog: 2.5.0...2.6.0

v2.5.0 - Live countdown & reliable card loading

Highlights

This release focuses on the Lovelace card: a live countdown, real-time delays, and a frontend registration that no longer breaks after a restart or a browser reload.

Improvements

• Live countdown: the card now refreshes the remaining time every second instead of waiting for the next poll.
• Last departure badge: the last service of the day is flagged so you know there is nothing after it.
• Real-time delay: the delay reported by the Naolib feed is shown under the departure time it applies to.
• Card layout: departure markers are aligned on a shared row and the short-time colour coding is back.

Fixes

• No more "Configuration error" at startup. The card is served by the integration and loaded through a small loader module that retries the import until the custom element registry is usable, then repairs any error card Lovelace already rendered.
• The Lovelace resource stays registered across integration reloads and Home Assistant restarts.
• The departures attribute is excluded from the recorder, which stops the database from growing for nothing.

Technical

• The frontend is registered from async_setup, before Lovelace builds its views.
• The legacy config/www copy and the Lovelace resource created by earlier versions are cleaned up on startup.
• Repository history and releases were consolidated: only the milestone versions are kept.

v2.4.0 - Home Assistant 2026.6 ready (Bronze)

⚠️ Breaking change — action required: The sensor state is now a timestamp. The "next departures" sensor exposes the next departure as a timestamp device class (an actual date/time) instead of a localized string like "5 mn" or "Aucun bus". Home Assistant now renders the relative time natively (e.g. in 5 min), and the state is usable in history and automations.

If you referenced the raw state text in templates or automations, update them to use the timestamp (the human-readable list remains available in the next_departures attribute).

The bundled Lovelace card is unaffected — it keeps reading departures over WebSocket.

Highlights

This release modernizes the integration to align with Home Assistant 2026.6 standards and reaches the Bronze quality scale.

Improvements

• Diagnostics: download config entry diagnostics from the integration page (coordinator status, indexed quays; latitude/longitude redacted).
• Config flow: nearby-stop lookups are now guarded against network errors and surface a clean error instead of failing.
• Translations: added field descriptions (data_description) for the location, stop and update-interval inputs (English & French).
• Logging: transient upstream gateway errors (502/503/504) and timeouts are kept out of the error log to reduce noise.

Technical

• integration_type switched to device; added loggers and quality_scale: bronze to the manifest.
• Adopted config-entry typed entity callbacks (AddConfigEntryEntitiesCallback, typed runtime_data) and PARALLEL_UPDATES.
• Added a data attribution ("Données Naolib / Okina").

v2.3.0 - Naolib rebrand & HACS default store readiness

Highlights

• Rebranded to Naolib: all user-facing names, branding and references now use the official Naolib identity for the Nantes public transport network.
• HACS default store ready: added the required brand/ assets and cleaned up the HACS manifest so the repository passes HACS validation without ignored checks.
• Fixed card departure colors: corrected the departure time color coding in the Lovelace card.

Under the hood

• Added custom_components/naolib/brand/icon.png (256×256) and icon@2x.png (512×512) for Home Assistant brand rendering.
• Removed the obsolete render_readme key from hacs.json.
• Removed ignore: brands from the HACS validation workflow so the repository now validates cleanly against HACS requirements.

Notes

This release contains no functional changes for existing users. It is a cosmetic and administrative update to meet HACS inclusion criteria.

Full Changelog: 2.2.0...2.3.0

v2.0.0 - Migration to the new Naolib real-time API (SIRI)

⚠️ Breaking change — action required: the legacy open.tan.fr API was shut down by TAN (December 2025) and no longer returned any data. This release migrates the integration to the new Naolib real-time API (SIRI format).

After updating, you must remove and re-add your stops: stop identifiers changed with the new API.

Highlights

• Real-time restored via the Naolib/SIRI API (api.okina.fr), using public keyless access
• Local stop search: pick your stop on the map, instant and offline (no network call when adding a stop)
• Embedded stop index (1,134 stations) generated from the official GTFS feed, auto-refreshed monthly via GitHub Actions

Under the hood

• A single network request fetches the whole network (913 quays), shared across all your stops → respects the API limit (1 req / 30 s) no matter how many stops you track
• Shared global coordinator (ref-counted): each stop filters its own quays locally
• SIRI StopMonitoring client (XML parsing, real-time times + delays)
• Lovelace card unchanged (data format kept compatible)

How to migrate

1. Update the integration (HACS) and restart Home Assistant
2. Settings → Devices & Services → Tan Nantes: remove your existing stops
3. Re-add them via Add Integration (pick the stop on the map)

v1.0.0 - First stable release

What's New

• First stable release of the Tan Nantes integration!
• Auto-detection of the nearest stop via GPS.
• Native Lovelace card included with schedule and traffic management.
• Performance and loading optimizations.

Installation

Available via HACS (see README.md)