Thanks for this. It’s interesting that this has arrived at the same time as National Rail Lifts & Escalators version 2 which, rather shockingly, actually works this time.
As I implemented the NR API first, I’ve got objects which look like this which seem to be linked to a primary key “sensorId” which you can use a all of the objects
"location": "Platform 1",
"description": "Lift 1, Platform 1",
"displayName": "Lift 1 Platform 1"
there’s a separate call to get the state of all the sensors, which come back as one of three values
This compares with the TfL call https://api.tfl.gov.uk/Disruptions/Lifts/v2 which lifts just disruptions.
I’ve looked at the stops.txt CSV file in https://api.tfl.gov.uk/stationdata/tfl-stationdata-gtfs.zip and this is a list of stations that can then be used with the pathways.txt CSV part of the ZIP.
This gives the pathway_id as the useful index, and you can create the name of the lift by using the from_stop_id and to_stop_id for “from” and “to” where pathway_mode=5 (for “lift”).
The only annoying thing is matching the data from Disruptions/Lifts/v2 as these disruptedLiftUniqueIds are partial matches to the end of pathway_id.
SELECT * FROM public.liftsandescalators where "sensorId" ilike '%940GZZDLPRE-Lift-2'
But otherwise this is very useful and easily linked to having single table for National Rail and TfL lifts, so thanks.