UK bus and train TransportAPI component. Requires developer account on http://www.transportapi.com/
The uk_transport
sensor will display the time in minutes until the next departure in a specified direction from of a configured train station or bus stop. The sensor uses transportAPI to query live departure data and requires a developer application ID and key which can be obtained here. The free tier allows 1000 requests daily, which is sufficient for a single sensor refreshing every 87 seconds. See Managing API requests at bottom of page.
Additional sensors can be added but at the expense of a reduced refresh rate. 2 sensors can be updated every 2*87 = 174 seconds, and so on.
Queries are entered as a list, with the two transport modes available being bus
and train
.
Train departure sensors require three character long origin
and destination
station codes which are searchable on the National Rail enquiries website (e.g. WAT
is London Waterloo). The validity of a route can be checked by performing a GET request to /uk/train/station/{station_code}/live.json
in the API reference webpage.
To add a single train departure sensor add the following to your configuration.yaml
file:
# Example configuration.yaml entry for a single sensor
sensor:
- platform: uk_transport
app_id: abc123
app_key: efg456
queries:
- mode: train
origin: MAL
destination: WAT
Configuration variables:
- app_id (Required): Your application id
- app_key (Required): Your application key
- queries array (Required): At least one entry required.
- mode (Required): One of
bus
ortrain
. - origin (Required): Specify the three character long origin station code.
- destination (Required): Specify the three character long destination station code.
A large amount of information about upcoming departures is available within the attributes of the sensor. The example above creates a sensor with ID sensor.next_train_to_wat
with the attribute next_trains
which is a list of the next 25 departing trains. The status of the next departing train is accessed using the template sensor below, as are the train origin, estimated and scheduled departure times, and the departure platform.
# Example configuration.yaml entry for a template sensor to access the attributes of the next departing train.
- platform: template
sensors:
next_train_status:
friendly_name: 'Next train status'
value_template: '{{states.sensor.next_train_to_wat.attributes.next_trains[0].status}}'
next_trains_origin:
friendly_name: 'Next train origin'
value_template: '{{states.sensor.next_train_to_wat.attributes.next_trains[0].origin_name}}'
next_trains_estimated:
friendly_name: 'Next train estimated'
value_template: '{{states.sensor.next_train_to_wat.attributes.next_trains[0].estimated}}'
next_trains_scheduled:
friendly_name: 'Next train scheduled'
value_template: '{{states.sensor.next_train_to_wat.attributes.next_trains[0].scheduled}}'
next_trains_platform:
friendly_name: 'Next train platform'
value_template: '{{states.sensor.next_train_to_wat.attributes.next_trains[0].platform}}'
Bus sensors require as their origin
a bus stop ATCO code which can be found by browsing OpenStreetMap data as
follows:
- On OpenStreetMap.org zoom right in on a bus stop you're interested in
- Click the layers picker button on the right hand side
- Tick the 'map data' layer, and wait for clickable objects to load
- Click the bus stop node to reveal its tags on the left
The destination
must be a valid location returned by the transportAPI query. Valid destinations can be checked by performing a GET query to /uk/bus/stop/{atcocode}/live.json
in the API reference webpage. A bus sensor is added in the following configuration.yaml
file entry:
# Example configuration.yaml entry for multiple sensors
sensor:
- platform: uk_transport
app_id: abc123
app_key: efg456
queries:
- mode: bus
origin: 340000368SHE
destination: Wantage
- mode: train
origin: MAL
destination: WAT
And the template sensor for viewing the next bus attributes.
# Example configuration.yaml entry for a template sensor to access the attributes of the next departing bus.
- platform: template
sensors:
next_bus_route:
friendly_name: 'Next bus route'
value_template: '{{states.sensor.next_bus_to_wantage.attributes.next_buses[0].route}}'
next_bus_direction:
friendly_name: 'Next bus direction'
value_template: '{{states.sensor.next_bus_to_wantage.attributes.next_buses[0].direction}}'
next_bus_scheduled:
friendly_name: 'Next bus scheduled'
value_template: '{{states.sensor.next_bus_to_wantage.attributes.next_buses[0].scheduled}}'
next_bus_estimated:
friendly_name: 'Next bus estimated'
value_template: '{{states.sensor.next_bus_to_wantage.attributes.next_buses[0].estimated}}'
Use the service homeassistant.update_entity
to request the update of an entity, rather than waiting for the next scheduled update. This means you can set a really long scan_interval
in the config options and then update on demand, ideal for those services where you have low API limit.
To display a timetable like the one below using Lovelace UI, first get the flex-table-card then edit your ui-lovelace.yaml
file to include something like:
resources:
- type: js
url: /local/flex-table-card.js
.
.
.
- type: custom:flex-table-card
title: Trains to Waterloo
entities:
include: sensor.next_train_to_wat
columns:
- name: Origin
attr_as_list: next_trains
modify: x.origin_name
- name: Destination
attr_as_list: next_trains
modify: x.destination_name
- name: Time
attr_as_list: next_trains
modify: x.scheduled
- name: Est
attr_as_list: next_trains
modify: x.estimated