@haselchen Ich kann diesen Adapter nicht maintainen, sorry.

• Ich nutze ihn selbst nicht, und habe im Übrigen keine Ahnung von iobroker.
• Ich würde nicht die Zeit dafür finden, ich schaffe es schon kaum, meine aktuellen Projekte zu pflegen.

@haselchen Ich kann diesen Adapter nicht maintainen, sorry.

• Ich nutze ihn selbst nicht, und habe im Übrigen keine Ahnung von iobroker.
• Ich würde nicht die Zeit dafür finden, ich schaffe es schon kaum, meine aktuellen Projekte zu pflegen.

Die Bahn hat die alt API abgeschaltet. Kannst du auf Github nachlesen.

• hafas-client-Issue: https://github.com/public-transport/hafas-client/issues/331
• public-transport-enabler-Issue: https://github.com/schildbach/public-transport-enabler/issues/610

Mittelfristig könntet ihr auf die neueren APIs der DB migrieren, z.b. mithilfe von db-vendo-client.

Viele Details sind aber noch unklar z.B. wie hoch die Rate-Limits sind, ob sich alle Details abrufen lassen, und ob sich die Antworten der APIs immer klar auf das bisherige Rückgabeformat von hafas-client mappen lassen.

grssnbchr created this issue in public-transport/hafas-client

open DB: API is not available anymore #331

Nibunnoichi created this issue in schildbach/public-transport-enabler

closed DB: SERVICE_DOWN #610

@tt-tom Ihr solltet definitiv auf hafas-client@6 migrieren, für hafas-client@5 werde ich keine solcher Fixes mehr veröffentlichen.
Aktuell gibt es Probleme mit der Verfügbarkeit der DB-HAFAS-API, aber das ist nochmal ein anderes Thema.

@australien Jetzt! https://github.com/public-transport/hafas-client/commit/31c4f17b107a5d962577a2135e1eac77f49f47fa

0 derhuerst committed to public-transport/hafas-client

ÖBB: change ver to 1.45 🐛

fixes #233

@australien Das könnte an https://github.com/public-transport/hafas-client/issues/233#issuecomment-2355939825 liegen.

gaudes created this issue in public-transport/hafas-client

closed OEBB: Parser error: root.svcResL.svcResL.res.common.rtSrcL.rtSrcL.type #233

@schuno2
Ich habe keine Ahnung vom Fahrplan-Adapter, aber bin der Author der darunterliegenden Library hafas-client.

Vor kurzem haben die Betreibenden der Deutsche-Bahn-HAFAS-API angefangen, die in der Dokumentation von hafas-client genannten User-Agents zu blocken.

Deswegen habe ich in hafas-client@6.0.3 auch erzwungen, dass ein andere User-Agent konfiguriert wird. U.u. werde ich das auch für die vom Fahrplan-Adapter verwendete 5er-Version tun.

Wenn ich den Fahrplan-Adapter-Source-Code richtig lese, verwenden alle Instanzen denselben User-Agent; Es ist also für die Gegenseite schwierig, die vielen Anfragen als einzelne Nutzer*innen auseinanderzuhalten.

Vielleicht ändert es etwas, die Nutzer*innen einen eigenen User-Agent vergeben zu lassen – am besten mit einer Kontaktmöglichkeit wie z.B. eine eigene Domain oder ein im Internet verwendeter Benutzername.

@qwerty1896 said in Test Adapter Fahrplan v0.2.x:
Ich bin der Entwickler von hafas-client, der Bibliothek, die dem Adapter zugrunde liegt. Ich kann also ein Stück weit weiterhelfen, von ioBroker oder diesem Adapter habe ich allerdings keine Ahnung.

Ich habe zufällig gesehen, dass ein Zugausfall mit Verspätung "0" dargestellt wird (auf bahn.de wurde der Zug bereits als Ausfall markiert). Unterwegs hatte ich jedoch keinen Zugriff auf die Objekte. Wie "identifiziere" ich einen Zugausfall?

Eigentlich gibt hafas-client ausgefallene Fahrten/Abfahrten/Ankünfte mit einem cancelled: true aus, zusätzlich zur letzten bekannten Verspätung (delay/departureDelay/arrivalDelay), letzten bekannten prognostizierten Zeit (prognosedWhen/prognosedDeparture/prognosedArrival), und der Fahrplan-Zeit (plannedWhen/plannedDeparture/plannedArrival).

Wo greift der Fahrplan die Daten ab? In der Nachbarnschaft ist ein Bahnhof, bei dem Stationfrom Platform und Stationfrom PlatformPlanned definitiv falsch sind. Auch hier gibt bahn.de die richtigen Daten an/aus.

hafas-client nutzt dieselbe API wie die DB-Navigator-App – bzw. die ganzen offiziellen mobil-Apps der Verkehrsverbünde allgemein. D.h. die Daten in deinem Fahrplan-ioBroker-Adapter sollten – von Verzögerungen beim Abruf mal abgesehen – immer denen in der App entsprechen.

Wenn das mal nicht der Fall ist, wäre es gut, wenn ihr hier, oder direkt im hafas-client-Repository den Fehler meldet. Um
nachvollziehen zu können, ob da wirklich ein Bug existiert, oder ob die DB-Daten einfach gerade falsch sind, braucht es dafür möglichst viele Daten; Im Nachhinein lassen sich diese Fälle ohne gespeicherte Daten eigentlich nicht nachvollziehen. @AggroRalf Dafür müssen die Leute hafas-client mit der Umgebungsvariable DEBUG=hafas-client laufen lassen, dann logged es alle rohen HAFAS-Anfragen und -Antworten.

Zu bahn.de: Es gibt manchmal kleinere Abweichungen zwischen bahn.de und der DB-Navigator-App, meistens sollten sie aber denselben Datenstand haben.

@gluecksmann Ja, das war leider ein Bot, der Issues nach ein paar Tagen Inaktivität schließt. Mal gucken, vielleicht macht das ja jemand wieder auf.

@gluecksmann Diese Möglichkeit hat übrigens auch ein MagicMirror-Plugin: MMM-PublicTransportHafas nutzt hafas-client, um eine konfigurierbaren HAFAS-API anzusprechen.

@oli Jo, kann ich machen. Welche denn?
Du kannst übrigens auch immer die IDs selbst herausfinden, indem du auf https://transport.rest die entsprechende API wählst (also DB, VBB, BVG, HVV) und dann https://v5.welche-api-hier.transport.rest/locations?poi=false&addresses=false&query=stationsname-hier aufrufst; Dieser API-Call gibt Stationen aus, die den entsprechenden Namen haben.