3. Configuring options

Configuration for routes between per-selected start / end stops

After you have set up a proper route, you can configure certain options

• refresh frequency: choose wisely to not query the database if the frequency of your transport is low. In this case, the bus-line runs every 10 mins, so reduced it to 5
• offset: this allows to skip certain departures if they are not within reach. Example: if you need 10 minutes to get to the stop then you may not interested in early departures as hese are not feasible
• real-time data: allows to add realtime datasources, depending on your gtfs provider

Configuration for acquiring realtime data

In this case, the service provides realtime

• tripupdates, for your departure stop
• without an api-key

Note: alerts may prove to be flaky

Field content for autorizatoin via api-key's:

• API key : usually a long string
• API key name: depends on the service provider, known key-names are:
  • Authorization , default value and covers key previsously labeled as 'api_key'
  • x_api_key
  • apiKey
  • ocp_apim_subscription_key

You are free to type in any 'key name' that applies to your provider requirements

If your provider requires an authentication method with a (x_)api_key, you can apply this either in a 'header' or as part of the url 'query_string. Check with the provider which method applies

Example for this entity, you will find additional attributes :

gtfs_updated_at: "2023-12-17T06:28:17.493348+00:00"
origin_stop_alert: no info
destination_stop_alert: no info
attribution: Palmbus
device_class: timestamp
icon: mdi:bus
friendly_name: Palmbus B to Mouans
gtfs_rt_updated_at: "2023-12-17T06:29:18.728897+00:00"
next_departure_realtime: "2023-12-17T06:43:00+00:00"
delay: unknown
latitude: ""
longitude: ""

You can now setup a Service Call to automate a data refresh or add visualization

Configuration for local stop departures

After you have properly configured sensors to acquire departure times of local stops, you can further fine-tune this

• Refresh interval (default: 15min): decrease if you use a 'person' and are frequent on the move and need (!) this new inisght. Carefully choose this as it will have an effect on performance.
• Radius (default 200m): the integration will try to find stop within an approximate (!) radius around the location of the configured 'person' or 'zone'*
• Departure in future (detault 30min): the departures in the future from the moment of refresh, i.e. at the moment of refresh it will by default only select departures 30minutes in the future.
• offset: this allows to skip certain departures if they are not within reach. Example: if you need 10 minutes to get to the stop then you may not interested in early departures as hese are not feasible
• Configure realtime, here you can use a URL to the trip data to show realtime data with your individual trips

In this case, the data for realtime tripupdates refers to a local file (www/gtfs2) which is downloaded using a service call

*Although entities of type 'zone' have a radius, this is not (yet) taken into account, this to avoid that a large zone triggers a massive set of data to be collected

Tip: depending on the frequency of transport around you, select a proper combination of refresh interval and departure in the future. i.e. with a low frequency of vehicles departing, the refresh interval does not have to be short but you can then select a larger value for departures in the future.