UK Transport

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 30 requests a day, which is sufficient for a single sensor refreshing every 48 minutes.

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: YOUR_APP_ID
    app_key: YOUR_APP_KEY
    queries:
      - mode: train
        origin: MAL
        destination: WAT

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.

These attributes are available for each departing train:

• origin_name
• destination_name
• status
• scheduled: (API attribute is aimed_departure_time)
• estimated: (API attribute is expected_departure_time)
• platform
• operator_name

Refer to the API reference webpage for definitions.

Attributes can be accessed using the template sensor as per this example:

# Example configuration.yaml entry for a template sensor to access the attributes of the next departing train.
template:
  - sensor:
    - name: Next train status
      state: >- 
        {{state_attr('sensor.next_train_to_wat', 'next_trains')[0].status}}
    - name: Next train origin
      state: >-
        {{state_attr('sensor.next_train_to_wat', 'next_trains')[0].origin_name}}
    - name: Next train estimated
      state: >- 
        {{state_attr('sensor.next_train_to_wat', 'next_trains')[0].estimated}}
    - name: Next train scheduled
      state: >-
        {{state_attr('sensor.next_train_to_wat', 'next_trains')[0].scheduled}}
    - name: Next train platform
      state: >-
        {{state_attr('sensor.next_train_to_wat', '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:

1. On OpenStreetMap.org zoom right in on a bus stop you’re interested in.
2. Click the layers picker button on the right hand side.
3. Tick the ‘map data’ layer, and wait for clickable objects to load.
4. Click the bus stop node to reveal its tags on the left.

The destination must be a valid location in the “direction” field returned by a GET query to /uk/bus/stop/{atcocode}/live.json as described 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: YOUR_APP_ID
    app_key: YOUR_APP_KEY
    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.
template:
  - sensor:
    - name: Next bus route
      state: "{{state_attr('sensor.next_bus_to_wantage', 'next_buses')[0].route}}"
    - name: Next bus direction
      state: "{{state_attr('sensor.next_bus_to_wantage', 'next_buses')[0].direction}}"
    - name: Next bus scheduled
      state: "{{state_attr('sensor.next_bus_to_wantage', 'next_buses')[0].scheduled}}"
    - name: Next bus estimated
      state: "{{state_attr('sensor.next_bus_to_wantage', 'next_buses')[0].estimated}}"

Managing API requests

If you wish to manage the rate of API requests (e.g., to disable requests when you aren’t interested in travel, so that you can request updates more frequently when you do travel) set a really long scan_interval in the configuration options, and use the service homeassistant.update_entity to request the update of an entity, rather than waiting for the next scheduled update.

Powered by transportAPI