4 ms·

If you need a demo use case, we provide an open MQTT feed of some 1500 public transport vehicles, soon once per second (plus per-stop departure prediction feeds

If you need a demo use case, we provide an open MQTT feed of some 1500 public transport vehicles, soon once per second (plus per-stop departure prediction feeds): host mqtt.hsl.fi, port 443 and 1883, topic /hfp/#

wcummings 9y ago
Out of curiosity, which vehicles/city?
- tuukkah 9y ago
  HSL provides the bus, tram, suburban rail, subway and ferry system in the Helsinki metropolitan area.
  - stevekemp 9y ago
    I've written a few toys that use their GraphQL API to show real-time displays of trams. Pretty neat system.
    - tuukkah 9y ago
      Thanks! Waiting for your MQTT integration ;-)
- helb 9y ago
  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/ 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"}}
- deleted 9y ago
  [deleted]
alexhultman 9y ago
Ah, kool. I first need to finish this up to a stable state though. Right now it just barely passes the benchmarks test.
StavrosK 9y ago
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.
- tuukkah 9y ago
  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/ 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.)
problems 9y ago
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.
- andai 9y ago
  lol. i just wish mine would put departure times on the website...
deft 9y ago
Are implementation details for this available? What's the stack?
- tuukkah 9y ago
  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/swagger-ui.html#/vessel-location-controller 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 https://digitransit.fi/en Specifically, the switchbox for realtime data is a simple NodeJS application: https://github.com/HSLdevcom/navigator-server https://github.com/HSLdevcom/navigator-server
  - deft 9y ago
    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!

wcummings 9y ago

Out of curiosity, which vehicles/city?

tuukkah 9y ago
HSL provides the bus, tram, suburban rail, subway and ferry system in the Helsinki metropolitan area.
- stevekemp 9y ago
  I've written a few toys that use their GraphQL API to show real-time displays of trams. Pretty neat system.
  - tuukkah 9y ago
    Thanks! Waiting for your MQTT integration ;-)
helb 9y ago
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/ 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"}}
deleted 9y ago
[deleted]

alexhultman 9y ago

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

StavrosK 9y ago

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.

tuukkah 9y ago
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/ 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.)

problems 9y ago

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.

andai 9y ago
lol. i just wish mine would put departure times on the website...

deft 9y ago

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

tuukkah 9y ago
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/swagger-ui.html#/vessel-location-controller 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 https://digitransit.fi/en Specifically, the switchbox for realtime data is a simple NodeJS application: https://github.com/HSLdevcom/navigator-server https://github.com/HSLdevcom/navigator-server
- deft 9y ago
  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!