EFA-based local transit APIs have two kinds of stop identifiers: numbers such as 20009289 and codes such as de:05113:9289. travelynx needs a single type of ID, and this post is meant mostly for myself to find out which ID is most useful. The numeric one would of course be ideal, as travelynx already uses numeric IDs in its stations table.

Numbers

DM_REQUEST: Available as stopID in each departureList entry.

STOPSEQCOORD_REQUEST: Available as parent.properties.stopId in each locationSequence entry.

STOPFINDER_REQUEST: Available as stateless and ref.id.

COORD_REQUEST: missing.

Codes

DM_REQUEST: missing.

STOPSEQCOORD_REQUEST: Available as parent.id in each locationSequence entry. Outside of Germany, the format changes, e.g. placeID:27006983:1 for a border marker (not an actual stop) and NL:S:vl for Venlo Bf.

STOPFINDER_REQUEST: Available as ref.gid.

COORD_REQUEST: Available as id and properties.STOP_GLOBAL_ID in each locations entry.

API Input

• DM_REQUEST: Accepts stop names, numbers, and codes
• STOPSEQCOORD_REQUEST: Accepts stop numbers and codes

Examples

• LinzAG Ebelsberg Bahnhof: 60500470 / at:44:41121
• LinzAG Linz/Donau Hillerstraße: 60500450 / at:44:41171
• NWL Essen Hbf: 20009289 / de:05113:9289
• NWL Münster Hbf: 24041000 / de:05515:41000
• NWL Osnabrück Hbf: 28218059 / de:03404:71612
• VRR Essen Hbf: 20009289 / de:05113:9289
• VRR Nettetal Kaldenkirchen Bf: 20023754 / de:05166:23754
• VRR Venlo Bf: 21009676 / NL:S:vl

Conclusion

Looks like numeric stop IDs are sufficient. They're missing from the COORD_REQUEST endpoint, but that's not a dealbreaker -- all database-related operations work with DM_REQUEST and STOPSEQCOORD_REQUEST data. Also, there seems to be no universal mapping between the two types of stop IDs.

Travel-Status-DE-VRR-3.04.tar.gz (signature)

• EFA: Add NWL service definition

Travel-Status-DE-DeutscheBahn-6.15.tar.gz (signature)

• HAFAS: add SaarVV service definition

Travel-Status-DE-DeutscheBahn-6.13.tar.gz (signature)

• HAFAS->station: correctly identify referenced stations in non-DB backends

Travel-Status-DE-DeutscheBahn-6.14.tar.gz (signature)

• DB service: Bump HCI Core and ext versions. Note that the service no longer reports route data for stationboard results after this change.
• ZVV service: Update HAFAS endpoint URL.

Travel-Status-DE-DeutscheBahn-6.12.tar.gz (signature)

• Do not cache upstream CGI_NO_SERVER and CGI_READ_FAILED errors. These are typically temporary.

Travel-Routing-DE-HAFAS-0.09.tar.gz (signature)

• Improve handling of backend messages and errors

Travel-Status-DE-VRR-3.03.tar.gz (signature)

• efa-m: handle undefined platforms
• Trip->polyline: pass fallback => 1 to return beeline between stops if the backend did not provide a polyline.

Travel-Status-DE-VRR-3.02.tar.gz (signature)

• Stop: Add ar_delay, dep_delay, delay, stop_id accessos
• EFA: Fix place_candidates
• EFA: Add stop and stops functions
• EFA: Add static get_servicesmethod
• efa-m: Add -j/ --with-jidoption
• efa-m -Oa, -Ob, -Of: Show delays
• EFA, efa-m: Add stopfinder ("?foo") and stop search ("lat:lon") modes
• Add ...::Trip and ...::Info modules
• Info, Stop, Trip: Note that the API of these modules is not yet final and may change between minor versions

Travel-Status-DE-DeutscheBahn-6.11.tar.gz (signature)

• HAFAS: Add mobiliteit service definition

Travel-Status-DE-VRR-3.01.tar.gz (signature)

• Fix Departure->route_interesting
• efa-m: Add --json option

Travel-Status-DE-VRR-3.00.tar.gz (signature)

• Drop XML::LibXML dependency
• New dependencies: DateTime::Format::Strptime, JSON
• Switch API language from XML to JSON
• Rename Travel::Status::DE::EFA::Result to Travel::Status::DE::EFA::Departure
• EFA: Add static get_service_ids function
• EFA: Add bwegt backend service
• EFA: Remove identified_data accessor (not supported by JSON backends)
• EFA: Remove static get_efa_urls function; use get_service_ids instead
• EFA->new, EFA->new_p: Add optional cache key
• Result/Departure: Add hints accessor
• Result/Departure: Remove info accessor; use hints instead
• Stop: Add place, full_name and occupancy accessors
• Line: Add number accessor
• Stop: Remove name_suf accessor; use name instead
• efa-m: -Oa, -Ob, -Of: show per-stop occupancy, if available

Travel-Status-DE-DeutscheBahn-6.10.tar.gz (signature)

• HAFAS: Hardcode request seconds to 00 to improve caching
• hafas-m: Cache backend replies by default (if Cache::File is available)

I usually carry a PowerCore 5000 powerbank with an attached USB-A to USB-C cable in my purse. In hindsight, always having the cable attached to it (rather than just when using it) is not the best idea, as it exercises quite some leverage forces on the USB port. So, to little surprise, at some point the output port stopped working unless the cable connected to it was pressed into the right direction.

Luckily, the powerbank is quite easy to open up, repair, and re-assemble.

Caution: This powerbank contains a 18.5 Wh LiIon cell. In normal operation, the (dis)charge PCB is in charge of battery management tasks like short circuit protection. Disassembly exposes the raw 26650 LiIon cell, which likely does not contain a built-in protection circuit. Puncturing, shorting, heating, or otherwise mishandling it can lead to fire and/or explosion. Don't disassemble a powerbank unless you know what you are doing. Don't work with soldering irons close to LiIon cells unless you really know what you are doing.

Teardown

The connector side of the power bank features a glued-on plastic cover on top of a screwed-on plastic cover.

The glued-on cover can be pried open with moderate effort by placing a suitable object between the two plastic covers, revealing the screwed-on second plastic cover.

With the powerbank placed on a table (not held in your hands), you can now take a PH00 screwdriver to release the three screws that hold it in place. Once that is done, simply lift the case up, revealing the actual circuitry (LiIon cell and PCB). If you were holding the powerbank in your hands while removing the screws, the circuitry likely fell out instead.

The innards are quite simple: A single 26650 LiIon cell; a single PCB; and a two-part plastic assembly featuring a button and LED diffusors.

Repair

In my case, the culprit was a loose solder connection between the USB-A output port and the PCB. Nudging the capacitor out of the way and carefully applying some additional solder to its GND and VCC pins solved the issue. Just be wary of the fact that you're operating a soldering iron next to a LiIon cell that does not like triple-digit temperatures…

Re-Assembly

• Slide the button assembly and diffusor back into the case until it locks into place.
• Slide the LiIon cell and PCB assembly back into the case.
• Place the powerbank on its bottom (i.e., so that the USB ports face up).
• Place the plastic cover on top of the PCB assembly and tighten its three screws.
• Put the glued-on top cover back on. It comes with alignment pins; in my case I did not have to apply new glue.

Travel-Status-DE-DeutscheBahn-6.09.tar.gz (signature)

• Improve handling of services which do not provide intermediate stops
• HAFAS: Add Resrobot service definition
• HAFAS: get_service et al.: return coverage data provided by transport-apis, if available