That's a pretty nice use case, especially with MQTT supporting persistent messages (which are messages that "stay around" and which the client will receive immediately upon subscription, no matter how long ago they were published). That way, you can publish the messages as rarely as they come, and a client that subscribes will still get the latest time available without having to wait for the next publish.

In practise we can't use persistent messages for this, but you can fetch the latest messages that correspond to your subscription from a REST API that caches the messages: https://api.digitransit.fi/realtime/vehicle-positions/v1/hfp...

(The reason is that we use MQTT topics creatively: instead of one topic per vehicle, the topic changes dynamically to provide more filtering criteria such as the route and the next stop of the vehicle. Thus, most of the per-topic persistent messages would be obsolete.)

That's awesome, wish my city would do something like this - you're lucky to get updates once per 2 or 3 minutes on their service.

lol. i just wish mine would put departure times on the website...

Ah, kool. I first need to finish this up to a stable state though. Right now it just barely passes the benchmarks test.

Are implementation details for this available? What's the stack?

We try to be as open as possible nowadays. However, these backend systems are from an old proprietary contract. There's a computer with a GPS receiver and driver UI in each bus and tram sending the MQTT messages to mqtt.hsl.fi (IBM MessageSight hardware for now) over 3G cellural data connection.

The subway can't use GPS but the trains read RFID tags installed along the tracks and there's wifi coverage. The suburban trains have Raspberry Pi's listening in promiscuous mode in the maintenance Ethernet ports and relaying the vehicle data to us.

The ferries send AIS radio data that we fetch from here: https://meri.digitraffic.fi/api/v1/metadata/documentation/sw...

The REST API is part of Digitransit, which is a fully open passenger information platform and journey planner. Docs and code here: https://digitransit.fi/en

Specifically, the switchbox for realtime data is a simple NodeJS application: https://github.com/HSLdevcom/navigator-server

Thanks for the information, hopefully you can move the MQTT to something open in the future :)

Digitransit is very interesting, and all of this is great work!

Out of curiosity, which vehicles/city?

If you want to have a quick look at how the feed looks like, there is a web client for mqtt at http://www.hivemq.com/demos/websocket-client/. Don't leave it open for too long though, it might kill your browser (Chrome struggled a bit on my old laptop).

    {"VP":{"desi":"N","dir":"2","oper":"XXX","veh":"H9449","tst":"2017-05-25T11:31:50.000Z","tsi":1495711910,"spd":2.22,"hdg":10,"lat":60.249649,"long":25.008106,"dl":0,"oday":"2017-05-25","jrn":"XXX","line":"XXX","start":"1439","stop_index":7,"source":"sm5logger"}}

HSL provides the bus, tram, suburban rail, subway and ferry system in the Helsinki metropolitan area.

I've written a few toys that use their GraphQL API to show real-time displays of trams. Pretty neat system.

Thanks! Waiting for your MQTT integration ;-)