This is a roll-up of pre-releases 0.5.9.x
Features for local-stop config:
- local stop entities that show 'tomorrow' departures now also show their realtime departures, if provided; before these were hardcoded as 'tomorrow'
- local stop entities are now properly sorted nby departure time in the entity attributes, this is especially visible when the entity shows departures before/after midnight
Fixes for local-stop config:
- config flow pygtfs issue when setting up/refreshing local stop entities
- coordinator backfired when a stop was not presented from the db, e.g. when no departures today
- incorrect display of trips 'today' with a departure time 'today' but which are actually 'tomorrow', addresses; #163
- new attribute to show the upcoming arrivals next to the existing upcoming departures (max 10), addresses #178
Features for start/stop config:
- there is now a geojson file created (in www/gtfs2) that contains all the stops for that route and current trip. This file can be used with e.g. geojson import and the entities then displayed in a map card along the vehicle position. As routes having different trips: with changing trips the file can contain different stops as stops can be skipped/added based on the (time of) day. thanks @Pulpyyyy
Fixes for start/stop config:
- for feeds using calendar_dates (table) for departures: in certain cases the feed does not provide consistent information for trips that start today but in reality are for tomorrow. Also the offset was not properly applied, addresses: #166 and #164
- when a local_stop setup had an exceptional non-service day after midnight then the gtfs2 integration would not pick it up
- when realtime vehicle data does not provide a route_id then the gtfs2 integration would not pick it up
- Next RT departures listings were limited to the route with which the entity was setup, whereas the entity covers all(!) scheduled/direct trips between start/stop locations, i.e. also trips for other routes, addresses: #171
- for realtime vehicle tracking, the geojson file contained an id using the trip_id, this to make it unique. By using the trip_id, this led to a a high amount of orphaned entities when the geojson integration removed them after the trip ended. Now the id uses the vehicle_id to make it unique (if vehicle_id does not exist, it will still take the trip_id as basis). This allows geojson entities to be reused much quicker and substantially reduce the risk of orphaned entities. Since the name of the entity changes (slightly) this may lead to a reconfig of the card(s) that you are using for this purpose, thanks @Pulpyyyy
- with a failing refresh/update of the entity, the error mechanism was poor, thanks @Pulpyyyy
- RT calls failed with an error when there was no next trip (e.g. no trip tomorrow), now this is properly avoided, thanks @Pulpyyyy
- For realtime data at a stop, it used the expected stop-arrival time as RT time-stamp but in cases of longer terminal stops or layover, that could be incorrect when the RT departure time is many minutes later. Now the RT time-stamp is the 'latest' chosen between RT departure and RT arrival times, thanks @Pulpyyyy
Other:
- when the source feed url failed (e.g. changed or unreachable), then the existing feed file/database was already deleted, leaving the user with 'nothing'. This is now improved, addresses: #168
- for local-stop conig: removed all references to a config with 'include tomorrow', as this option is not available since long (minor fix)
- more debug statements to help analyse specific cases (need to be reviewed in next releases)