Bit late maybe but was busy with line 341 near Aalsmeer so looked at the 340 too. Can’t find this bus stop too.
The current bus stops should be in http://v0.ovapi.nl/line/CXX_M340_2
Change the _2 into _1 for the other direction.
For the 341 I couldn’t find my bus stop too. Using now the following format with the timing_point_code from the above link I could find it! Works beautifully. Remove the part of the url after the last slash to view all lines and search for yours by line number or beginning / end stop, etc.
I’ve been trying to figure out if I can use the OVAPI to pull information from a station for NS lines instead of just bus.
My local station is pretty small so I want to see all available departures instead of specific ones (like the official integration requires) to make a decision on which to take.
When checking the OVAPI website (which links to drgl.nl) I can narrow it down to the specific station and see all departures (which is both Sprinter and IC) but I can’t see that same information from any of the v0.ovapi.nl link.
Thanks fellow Houthavens neighbour. I noticed that the Pontsteiger timingstopcode shows both ferries and I wasn’t able to filter by F7. How did you go about this?
And to add, there is a ] %} missing at the end of one of the template lines:
- platform: rest
name: Next Bus 48 Departure
resource: "http://v0.ovapi.nl/tpc/30005093"
value_template: >
{% set ns = namespace(earliest_time="2070-01-01T00:00:01") %}
{% for key, pass_data in value_json['30005093']['Passes'].items() %}
{% if pass_data['ExpectedDepartureTime'] < ns.earliest_time %}
{% set ns.earliest_time = pass_data['ExpectedDepartureTime'] %}
{% endif %}
{% endfor %}
{{ ns.earliest_time }}
scan_interval: 180
- platform: rest
name: Next Ferry NDSM Departure
resource: "http://v0.ovapi.nl/tpc/30009900"
value_template: >
{% set ns = namespace(earliest_time="2070-01-01T00:00:01") %}
{% for key, pass_data in value_json['30009900']['Passes'].items() %}
{% if pass_data['ExpectedDepartureTime'] < ns.earliest_time and pass_data['DestinationCode'] %}
{% set ns.earliest_time = pass_data['ExpectedDepartureTime'] %}
{% endif %}
{% endfor %}
{{ ns.earliest_time }}
scan_interval: 180
- platform: template
sensors:
next_ferry_ndsm_departure_formatted:
friendly_name: "Next Ferry NDSM Departure Time"
value_template: >
{{ states('sensor.next_ferry_ndsm_departure')[11:16] }}
- platform: template
sensors:
next_bus_48_departure_formatted:
friendly_name: "Next Bus 48 Departure Time"
value_template: >
{{ states('sensor.next_bus_48_departure')[11:16] }}
EDIT: the fork here resolved my ferry issue. Now, also the line filter works as expected. I may not have been a line issue but just the fact that ingoing and outgoing times for the same line were pulled.
You can also use my gtfs2 integration. The downside is that you need to load the data locally and for the NL this is a large file which needs to update when new versions come-out … but also that can be automated, some providers update data-sets monthly, others (semi-)annually
I have not had any issues back from Dutch users but it is globally used and my daughter is fine in Amsterdam
EDIT, I am using also data from some other (same?) ovapi …one can check if it has the same errors in the back (checks stops.txt in the zipfile) . Index of /nl/
EDIT2: I checked the above v0/ovapi link and it also does not cover the stops my daughter is using…it is also a very small set for the whole of NL so not surprised
I managed to locate my bus stop in the stops.text file that I can’t find in the JSON of OVapi, but this list does not provide timing point codes. I will give GTFS2 a try to see if it still gives me the info I need.
gtfs data uses a combination of routes/trips/stops/stoptimes… you can see all these files in the zip. The gtfs2 integration creates a db out of them and then allows to configure things. There is a extensive doc as part of the integration but do note that I am not a tech. writer
I installed your integration. It deserves much more visibility. It’s incredibly capable and mature. Very well done.
My stop that I could not find on OVApi is there and works fine.
I’d say one thing it needs is better search optimisation as all my searches for public transport integrations didn’t surface it. I know now that GTFS is a standard(ish), but for the uninitiated, it doesn’t mean anything.
Maybe adding ‘Home Assistant’ to the GitHub repo name might also help with that. As would adding ‘public transport’ to the HACS title.
Thanks and changing the name is no longer an option as it defines the link to the repo, issues, etc… too much work to redo and all existing installs will fail to update. Never gave this any thought
My theory is that systems can triangulate timing for certain stops. So they don’t solely rely on TPCs. However, I also found that my stop Haparandaweg in Amsterdam is missing from 9292 and the halte page does not even exists on the GVB website, only as a stop on the bus route 48. The physical stop has moved a little due to building works nearby, and that seems to have resulted in it being dropped from the API. The stop is also skipped in the route I see on OVapi. So 1 → 3, 4, 6 etc., and 4, 5, → 7 in the other direction. But I can see the correct timings using the GTFS file from OVapi and @vingerha 's integration. So I would just drop OVApi alltogether and install GTFS2 and benefit from the failover options.
my city is listed in the other ‘timings’ overview, so I guess my understanding of the api is not yet complete…
as I would have liked to create a dynamic config, and not predefine the entities in yaml, I am not sure this integration will allow me to do so in the first place given the examples in the repo.
I simply want to have an origin and destination in dropdown, and then create the travel itinerary/time of several routes I usually take.
So, not requiring the full DB in dropdown but a few preselected ones would be nice in the UI, and then throw that at the integration,
I noticed that the Pontsteiger timingstopcode shows both ferries and I wasn’t able to filter by F7. How did you go about this?
