mark1foley/ha-gtfs-rt-v2

Arrival times without a time field are ignored

Opened this issue · 2 comments

calvinbui commented

Hey there đź‘‹

Your fork has been the most up to date I have found.

I have found that trains that arrive at my station without a time field in the StopTimeEvent type are ignored.

In the GTFS reference, it says that Either delay or time must be provided within a StopTimeEvent - both fields cannot be empty.

The code however only checks for the time field:

ha-gtfs-rt-v2/custom_components/gtfs_rt/sensor.py

Lines 243 to 251 in ecca8d9

for stop in entity.trip_update.stop_time_update:
stop_id = stop.stop_id
if not departure_times[route_id][direction_id].get(stop_id):
departure_times[route_id][direction_id][stop_id] = []
# Use stop arrival time; fall back on stop departure time if not available
if stop.arrival.time == 0:
stop_time = stop.departure.time
else:
stop_time = stop.arrival.time

For example, the entity in HA shows the next train in 16:48 and the one after at 19:50:

image

However, there's a train in 16:33 it's missing and many more between 16:48 and 19:50:

image

And looking at the API response, the train at 19:50 has a arrival.time value


    stop_time_update {
      arrival {
        delay: 0
        time: 1676019000
      }
      departure {
        delay: 0
        time: 1676019030
      }
      stop_id: "2137171"
    }

and the trains that do not have a lot more information, but do not have the time field, only a delay field:

    stop_time_update {
      arrival {
        delay: 0
      }
      departure {
        delay: 0
      }
      stop_id: "2137171"
      schedule_relationship: SCHEDULED
      departure_occupancy_status: MANY_SEATS_AVAILABLE
      [transit_realtime.carriage_seq_predictive_occupancy] {
        position_in_consist: 1
        departure_occupancy_status: MANY_SEATS_AVAILABLE
      }
      [transit_realtime.carriage_seq_predictive_occupancy] {
        position_in_consist: 2
        departure_occupancy_status: MANY_SEATS_AVAILABLE
      }
      [transit_realtime.carriage_seq_predictive_occupancy] {
        position_in_consist: 3
        departure_occupancy_status: MANY_SEATS_AVAILABLE
      }
      [transit_realtime.carriage_seq_predictive_occupancy] {
        position_in_consist: 4
        departure_occupancy_status: MANY_SEATS_AVAILABLE
      }
      [transit_realtime.carriage_seq_predictive_occupancy] {
        position_in_consist: 5
        departure_occupancy_status: MANY_SEATS_AVAILABLE
      }
      [transit_realtime.carriage_seq_predictive_occupancy] {
        position_in_consist: 6
        departure_occupancy_status: MANY_SEATS_AVAILABLE
      }
      [transit_realtime.carriage_seq_predictive_occupancy] {
        position_in_consist: 7
        departure_occupancy_status: MANY_SEATS_AVAILABLE
      }
      [transit_realtime.carriage_seq_predictive_occupancy] {
        position_in_consist: 8
        departure_occupancy_status: MANY_SEATS_AVAILABLE
      }
    }
mark1foley commented
calvinbui commented

So, I think merging the GTFS core and the gtfs-rt integrations into one is probably the best option going forward. But I would need to talk to the HA developers about this.

The GTFS integration page mentions there is no realtime support due to protobuf parsing issues.

I also need to modify the integration to support the operator’s gtfs-realtime.proto file

The user should be providing this file if possible.

So, I think merging the GTFS core and the gtfs-rt integrations into one is probably the best option going forward. But I would need to talk to the HA developers about this.

Definitely.