What's Changed
Fix: Lovelace card compatibility — train_number now uses integer index
The train_number attribute previously contained the HAFAS product name string (e.g. "RE 4632"). Both lovelace-my-rail-commute-card and lovelace-cfl-commute-card use train_number to construct entity IDs for the more-info popup (sensor.{name}_train_{train_number}). A string value produced invalid entity references like sensor.morning_commute_train_RE 4632.
Changes:
train_numberis now the 1-based integer position (1, 2, 3…) matching entity naming (sensor.{name}_train_1,train_2, etc.)- New
service_idattribute preserves the original product name string (e.g."RE 4632") for display and categorisation
This affects three sensor locations:
- Summary sensor
all_trainslist entries - Next Train sensor attributes
- Individual Train sensor attributes
Compatibility with lovelace cards
| Card | Minimum version | Compatible? | Notes |
|---|---|---|---|
| lovelace-cfl-commute-card | 2.7.0+ | ✅ | Full dual-format support — reads service_id with train_number fallback |
| lovelace-cfl-commute-card | < 2.7.0 | ❌ | train_number was a string for category/number display; now an integer — will break |
| lovelace-my-rail-commute-card | 1.0.0+ | ✅ | Uses all_trains; entity ID resolution works with integer train_number; service_id available as fallback |
Breaking change for templates/automations
If you have any custom templates or automations that read train_number expecting the product name string (e.g. "RE 4632"), switch to the new service_id attribute instead.