-
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request]: Migration path from ha-deutschebahn #4
Comments
That is a real good feature request. Right now the API just provides entering one station to track, no start/destination. I think that this maybe can be implemented, but needs to be added to the backend api provider first (https://dbf.finalrewind.org/ / https://github.com/derf/db-fakedisplay/tree/main) |
I will start providing some informations here: https://github.com/FaserF/ha-db_infoscreen?tab=readme-ov-file#migrating-from-ha-deutschebahn |
Coming here via FaserF/ha-deutschebahn#59 (comment) from https://github.com/FaserF/ha-db_infoscreen?tab=readme-ov-file#migrating-from-ha-deutschebahn. So happy to read this. Installed the 3.0.5 update of the old integration and of course the new one, but did not restart HA yet. I have so intensively used GUI customization and information in automations etc., that before productively using the new integration I need to know exactly which attribute of which sensor in the new integration matches the ones from the old one. Seeing we don't even (yet) have a track (from station A to station B) as sensor sounds like it's a quite long way to go still. Anyway, as said: reaaaaaally great to see development progress here. I did not expect a complete new integration. Awesome! |
Ok, I'll make a start. With the new integration, I have a sensor for Berlin Central Station and would now like to know which connections there are to Leipzig. With the following template, I get the same output as with the previous integration (try it out first in the template editor): {%- set target = "Leipzig Hbf" -%}
{%- set number = 0 -%}
{%- set connections = state_attr('sensor.berlin_hbf_departures', 'next_departures') | selectattr('destination', 'equalto', target) | list -%}
{% if connections is not none and connections | length > number %}
{% set connection = connections[number] %}
{% set product = connection.train %}
{% set departure = connection.scheduledDeparture %}
{% set delay = connection.delayDeparture | int %}
{{ product }} um {{ departure }}{% if delay > 0 %} +{{ delay }}{% endif %}
{% else %}
--
{% endif %} You first enter the destination station in “target”. The variable “number” determines which connection we are interested in. “0” corresponds to the current one, ‘1’ to the next one, etc. The rest of the template can initially be used unchanged and should give you the following output: IC 495 um 22:28 +1 I have created a new template sensor with this template. The sensor provides information about the current connection from Berlin to Leipzig, the time, which train type and, if applicable, its delay. I use a second sensor to query the next connection by using the same template with “number: 1”. If there is none, “--” is output instead. This works for my dashboard for the time being in order to have the same functionality as before. |
Thank you very much for this new integration. I like that it is now possible to see track and which train. Regarding selection of target. Could option „nur Fahrten über“ in dbf.finalrewind be used? With that option we could get only data of relevant trains. |
Awesome that you port it now, really looking forward to it. Maybe one addition to the Readme -- dbf_data doensn´t show all options/stations directly and e.g. "Godorf Bahnhof, Köln" was not working -- while copying it from the URL as "godorf bahnhof, köln" resulted in a properly configured sensor. Might be worth to add that to the readme. Thanks for developing that! |
I have now fixed this, should be working with the upcoming release 2025.01.2 - in both ways, lowercase, uppercase and with spaces
This feature will also be available with release 2025.01.2 |
Thank you for this Great new Version. I will Jump tomorrow into Template Sensors. The data and selection should suit my needs. I would only propose to have the „via“ Information in Sensor Name as well. E.g. I Need to change Train in Cologne, but it is not allowed to have Station cologne twice. I would need it for selection between way to work and way Home. |
feature is now implemented with release 2025.01.3 |
Based on the Template #4 (comment) i've edited it a bit.
The result of this morning 07:15 is then "ICE 2935 um 07:15" instead of "ICE 1575 um 07:15" Thanks to Kanecaine for the preparatory work |
@kaffeetrinker71 how do i use these in a dashboard? im quite confused |
I've added this snippet in my configuration.yaml
Now you have a new entity with the name you assigned in the line -name: “next train to Hannover”. It is then called (in my example) sensor.next_train_to_Hannover. Now you can use this in the dashboard |
For anyone interested, I will start working (with less priority) on another Homeassistant Integration: The reason is, that the https://bahnvorhersage.de/ API contains a "Start + Destination" way instead of just the station way. It's main purpose is to display a prediction of the train delay based on Data from the last years, but it also shows the planned departure and its current delay, so this maybe could serve as a better replacement for all of you who wanted a start + destination combination. Unfortunatly their API is nowhere documented, and it looks like its also not meant to use their API publicly, I just found their API on their source code. |
So maybe check the API status first with them. From what you describe that the data allows this definitely sounds (more) interesting. TBH I'm a bit confused now as the former integration is dead, I did not implement the new one yet (takes me at least 2 hours) and now there's an outlook even a better one (without the need to do templating to gather basic information) might be available soon. Therefore idk what's the best option, next to maybe just wait a few more days and see how things develop. |
I understand the confusement, first I did not find any reliable API source which offers typing in a destination and start, that was the reason I started with this integration. I could have moved to the official DB deutsche_bahn_api , but this also offers just putting in a station, no start/stop and requires an API key + didnt seem really good to me. For now I will focus on making db_infoscreen more stable and afterwards I will take more time for bahnvorhersage, which currently is in a not working state and needs more time. |
In the meantime, I have extended my original template a little with the help of AI. Previously, it only returned results if the final stop was the destination station. But if the destination station is in the middle of the route, the template has to be adapted: {%- set my_station = "Berlin Hbf" -%}
{%- set target = "Leipzig Hbf" -%}
{%- set number = 0 -%}
{%- set connections = state_attr('sensor.berlin_hbf_departures', 'next_departures') | default([]) | selectattr('isCancelled', 'equalto', 0) -%}
{%- set valid_connections = namespace(connections=[]) -%}
{%- for connection in connections -%}
{%- set route = connection.route | default([]) | selectattr('name', 'defined') | map(attribute='name') | list -%}
{%- if my_station in route and target in route and route.index(target) > route.index(my_station) -%}
{%- set valid_connections.connections = valid_connections.connections + [connection] -%}
{%- endif -%}
{%- endfor -%}
{%- if valid_connections.connections | length > number -%}
{%- set connection = valid_connections.connections[number] -%}
{%- set product_raw = connection.train | default('Unknown') -%}
{%- set product = product_raw | regex_replace('^(Bus).*|^([A-Z]{2})\\s?\\d*', '\\1\\2') | replace("S ", "S") -%}
{%- set departure = connection.scheduledDeparture | default('--') -%}
{%- set delay = connection.delayDeparture | default(0) | int -%}
{{ product }} {{ departure }}{% if delay > 0 %} +{{ delay }}{% endif %}
{%- else -%}
--
{%- endif -%} I also added the filter for canceled trains, but haven't tested it. The new template also replaces various train numbers, as only the train type is important to me. If you don't want this, you can omit the replacements in product or directly output product_raw. In my case, I will stick with the template solution for the time being. The back and forth with the Bahn API recently has already cost me enough time and nerves. Even if I would very much prefer a solution that works without templates, it works for now. Since I am not an expert in Jinja2, I would be very happy if someone would check, correct or extend my template. Any contribution is welcome :) |
I have now dropped a first beta test release of the other integration for anyone being interested: https://github.com/FaserF/ha-bahnvorhersage/releases |
First stable release of ha-bahnvorhersage is here: https://github.com/FaserF/ha-bahnvorhersage/releases |
What a pity. Why on earth does Bahn.de not simply provide a usable API. It really starts to annoy to switch and test and ditch integrations on an almost weekly basis. Maybe for a regular user not urgently relying on train information in HA it might be best to sit and wait a few weeks and see if another approach comes up - without the need to template stuff or API limitations. The former integration was awesome. Hopefully we can return to something as close as possible to that feature set. |
The request
First of all, thanks for starting this new integration. As you advertise it as the superior of ha-deutschebahn, it would be very nice to have a migration path / detailed upgrade info. As i have understood for now, this new integration behaves slightly different: instead of defining 2 stations you can only specify 1 station and see all arrivals and departures.
So when i am interested in one specific connection between 2 stations, i assume that i have to do it myself by evaluating all the entity attributes and filter out only relevant connections (e.g. where my destination station is part of the route). Maybe you can provide an example of how to do this with a template sensor or something approbiate.
Many thanks in advance.
Is your feature request related to a problem?
Additional information
No response
The text was updated successfully, but these errors were encountered: