v1.2.7 — Fix cross-regional line number resolution

Fixes the root cause of incorrect line numbers at stops served by
lines from a different regional entity (e.g. "KT" instead of "50").

The integration now uses the line's own entity from the API response
to resolve public line numbers and badge colors, instead of the stop's
entity. Removes the workaround introduced in v1.2.6.

v1.2.6

⚠️ This release contains an incomplete fix. Please upgrade to v1.2.7.

v1.2.5

What's changed

Sensors no longer go unavailable at night

Previously, when no buses were running (night, off-peak, RT outage),
departure sensors would become unavailable — causing Lovelace cards
to lose their badge colors, line numbers and destinations.

From v1.2.5:

• The sensor stays available as long as Home Assistant can reach the API
• When no departures are found, the state is empty (None) instead of unavailable
• All attributes from the last known departure are preserved in memory:
  line, destination, badge_background, badge_text, badge_border,
  badge_text_border, prediction, etc.
• Lovelace cards keep displaying correctly throughout the night

Note: the cached attributes are stored in memory only — they are lost
if Home Assistant restarts while no buses are running.
A full persistence solution (surviving restarts) is planned for a future release.

v1.2.4

Security hardening

Following a full security review, one minor issue was identified and fixed:

• API client: removed content_type=None from JSON parsing — the API
  response content-type is now properly validated, preventing the parser
  from silently accepting malformed or unexpected responses.

Security review summary

Check	Result
Hardcoded secrets or API keys	✅ None
Command / template injection	✅ None
Config flow input validation	✅ Validated
Entity ID sanitization	✅ Safe
Sensitive data in logs	✅ Never logged
External dependencies	✅ None (HA built-in only)
HTTPS enforced	✅

This is a stable release

The integration has been thoroughly tested and reviewed.
All core features are working reliably.

v1.2.3

What's changed

Settings menu now uses correct translations

The options menu (Configure → settings) was displaying hardcoded English
labels regardless of the HA interface language. It now reads labels from
the translation files, so French and Dutch users see the menu in their
language.

GitHub Actions added

Two automated validation workflows now run on every push and pull request:

• HACS Validation — verifies the repository meets HACS requirements
• Hassfest — validates the integration against Home Assistant standards
  (manifest.json, code structure, dependencies)

Both also run daily to catch upstream compatibility changes.

v1.2.2

What's changed

Stop summary fully translated and grouped

The final confirmation screen now shows stops grouped by location,
with platform numbers, warning icons and translated stop types:

• Sint-Pieters-Leeuw E. Ghijsstraat (304660, 304661, ⚠️ 354661) — Régulier + Temporaire
• Denderleeuw Station perron 2 (207104) — Régulier

No more duplicate lines for the same stop, and no more Dutch raw values
like TIJDELIJK or REGULIER.

All button labels translated

Every button and action choice in the config flow now uses the language
selected in step 1:

English	Français	Nederlands
Add this stop	Ajouter cet arrêt	Halte toevoegen
Search again	Nouvelle recherche	Opnieuw zoeken
Add another stop	Ajouter un autre arrêt	Nog een halte toevoegen
Finish	Terminer	Voltooien

Options flow also translated

Post-installation actions (add/remove stop, confirm) also use the
configured language from the integration settings.

v1.2.1

What's changed

Stop confirmation window redesigned

The confirmation screen now shows the full stop name with platform numbers
and warning icons at the top, followed by the explanation below:

Sint-Pieters-Leeuw E. Ghijsstraat (304660, 304661, ⚠️ 354661)
⚠️ L'arrêt 354661 (Sint-Pieters-Leeuw E. Ghijsstraat) est un arrêt temporaire.
Il peut disparaître ou ne pas avoir de données temps réel fiables.

Auto-migration for old config entries

Config entries created before v1.2.0 (when language support was added)
were missing the language field, causing all dynamic messages to appear
in Dutch regardless of the user's preference.

From v1.2.1, HA automatically adds the default language (nl) on startup.
If you want French, go to: Configure → Change display language → Français

v1.2.0

What's changed

Native French and Dutch translations

The config flow UI (titles, labels, error messages) now appears in the
correct language based on your Home Assistant interface language:

• translations/fr.json — French
• translations/nl.json — Dutch

Warning icons in stop search results

Stop numbers are now annotated with icons when a platform has a special type:

Sint-Pieters-Leeuw E. Ghijsstraat (304660, 304661, ⚠️ 354661)

A legend appears automatically below the dropdown when special stops are present:

• ⚠️ Temporary stop — may be removed when works end
• ℹ️ Flexbus stop — reservation required (015 40 88 88 or De Lijn Flex app)

Multilingual config flow messages

Warning and confirmation messages (TIJDELIJK, FLEX) now use the language
selected in step 1 of the installation — French or Dutch — from the very
first search onwards.

v1.1.2

What's changed

Device model now shows full group info

The device subtitle on the integration page now displays all stop numbers
and the combined stop types for the group:

304660, 304661, 354661 · Régulier + Temporaire

This replaces the previous behavior where only one stop's type was shown
(the last one processed), which was misleading for groups mixing regular
and temporary platforms.

All status attributes translated (NL / FR)

API value	Nederlands	Français
HEEN	Heen	Aller
TERUG	Terug	Retour
REALTIME	Realtime	Temps réel
GEENREALTIME	Dienstregeling	Horaire
GESCHRAPT	Geschrapt	Annulé
VERSTREKEN	Verstreken	Passé

Translation follows the language selected during installation (NL or FR).

v1.1.1

Bug fix

Service alert sensor now shows active alerts

The alert sensor was always showing 0 even when disruptions existed.

Root cause: the integration was only calling /haltes/storingen
which returns direct stop-level breakdowns (rare). The actual active
alerts (route diversions, construction works) are in /haltes/omleidingen
which was not being fetched.

Fix: both /storingen and /omleidingen are now fetched and merged
for every configured stop. The alert sensor correctly reflects all
active disruptions.

Test stop with active alert

To verify: add stop 207104 (entity: Oost-Vlaanderen) —
it has an active alert: "Werken aan stationsgebouw thv halte".