This is an adaptation of the GTFS integration in HomeAssistant Core, enhancements:
- configuration via the GUI, no configuration.yaml needed
- Uses selected route to further select start/end stops
- Shows next 10 departures on the same stretch start/end , including alternative transport lines if applicable
- allows to load/update/delete datasources in gtfs2 folder from the GUI
- Option to add gtfs realtime source/url
- Option to add gtfs realtime vehicle location source/url, generates geojson file which can be used for tracking vehicle on map card
- A service to update the GTFS datasource, e.g. for calling the service via automation
- translations: English and French
Core GTFS uses start + stop, it then determines every option between them and provides the next best option, regardless of the line/route
- Pro: you receive the first applicable departure time and just have to check the type of transport (bus/tram/etc.)
- Con: you have to know exactly which start and stop you want and in the proper direction. Noting that the same stops exist with different ID for different routes/trips/directions
Solution/workaround in GTFS2: attribute added: next_departure_line shows all next departues with their line/means-of-transport. So even if you select a route first and then two stops, the attibutes will still show alternatives between those 2 stops, if applicable.
v0.1.6, stabilizing
- realtime vehile tracking with geojson output
- workflow tweaks
- extend update service call
- increase stability with reboots, loss of data(source)
v0.1.5, adding features:
- new attribute: next_departure_headsigns
- adding route shortname in selection/list to overcome data discrepancies been short name and long name
- for new datasource, allow to use a self-placed zip file in the gtfs2 folder. This for zip that are not available via URL or zip with data that may need modification to comply with extraction conditions by pygtfs
- timezone for next_departure is now used in order: agency (delivering data), if not > HA system, if not > UTC. This to resolve TZ issues for datasets without agency (timezone)
v0.1.9: initial version
- Issue when updating the source db: pygtfs error: at the moment unclear as errors fluctuate, posisbly a lack of resources (mem/cpu)
- get realtime data for sources that donot base on routes, e.g. France's TER realtime source only uses trip_id
- In HACS, select the 3-dots and then custom repositories, add :
- URL : https://github.com/vingerha/gtfs2
- Category : Integration
- In Settings > Devices & Sevices
- add the integration, note that this is GTFS2
Use the workflow
Example: https://github.com/vingerha/gtfs2/blob/main/example.md
As per v1.6, the vehicle tracking output coordinates to geojson file in your www folder, which in turn can then be consumed by the geosjon integration and map card https://www.home-assistant.io/integrations/geo_json_events/
- sources need to adhere to GTFS standards both for static data (zip/sqlite) as well as for real-time data (binary).
- certain providers publish large zip-files which in turn will result in much larger db files. Unpacking may take a long time (depending HA server perf.). Example for a 117Mb zip: ~2hrs to unpack to a 7Gb sqlite
- the integration uses folder /config/gtfs2 to store the datafiles (zip and sqlite)
- the integration uses folder /config/www for geojson files, only available when using verhical tracking sources
Data can be updated at your own discretion by a service, e.g. you can have a weekly automation to run the service Note: for "update" to work, the name should be the same as the existing source. It will first remove the existing one and reload the one as per your URL
or via yaml
Static gtfs:
- not complying to the pygtfs unpacking library, examples: missing dates in feed_info > manual fix
- calendar not showing if a service is run on a specific day > fix via adding calendar_dates to filter, only works if (!) calendar_dates is used alternatively for the same purpose
- missing routes/stops/times, transport runs but gtfs does nto show it > report issue with your gtfs data provider
- routes show A > B (outward) but stop selection shows inversed B > A, within one gtfs source both good as incorrect start/end can show up > report issue with your gtfs data provider
Realtime gtfs
- only a few realtime providers also add vehicle positions with lat/lon, these are not always up to date > report issue with your gtfs data provider
- format incorrect of incomming json/feed > report issue with your gtfs data provider, they should adhere to standards
- realtime data not always available, few refreshes are fine then nothing then fine again, often related to timeout from provider > report issue with your gtfs data provider
- @joostlek ... massive thanks to help me through many (!) tech aspects and getting this to the inital version
- @mxbssn for initiating, bringing ideas, helping with testing
- @Pulpyyyy for testing, ideas
- @mark1foley for his gtfs real time integration which was enhanced with its integration in GTFS2