OTA / MQTT messages used by RuterSalg

di/assignment_attempt/block

VIN

OUT

assignment_attempt

assignmentType: SIGNON
RuterSalg can fetch VIN automatically if there is an assignment_attempt message on the broker when first logging in to RuterSalg. If this is not present, a dialog is presented for manual entry.

assignmentType: SIGNOFF
When this message is received, the user is automatically logged out of RuterSalg if manual log out has not already been performed

pe/dpi/nextstop

Next stop ID (NeTeX)

IN

nextstop

Some time after leaving a stop, the vehicle receives a NextStop message. The message contains the field stopPlaceId which contains a NeTeX ID for the stop the vehicle is now approaching. RuterSalg uses this ID to lookup the corresponding tariffZone to set as the current zone in the app.

This has been replaced by oi/current_vehicle_journey/expected_call (see below). No longer needed.

pe/dpi/journey

sorted list of next stops (stopPlaceId)

IN

journey

List of stop places:
The journey message contains a sorted list of upcoming stops on the current journey. When RuterSalg receives a journey message it uses the first stopPlaceId from this list to lookup the zone that the journey starts in, and sets this as the current zone in the app. This is done to ensure we have the correct zone even before we receive the first nextStopMessage, which sometimes happens after the very first stop.

journeyRef:
RuterSalg stores the journeyRef for the current journey and includes this in all diagnostics messages.

oi/current_vehicle_journey/expected_call

Next quay

IN

expected_call

In early 2022 we were told that the nextstop topic would be deprecated and that the data we needed would be available in expected_call. We changed RuterSalg to first handle both nextstop and expected_call, and later to no longer consume nextstop. This now has the same function as nextstop did before.

pe/vehicle/api

ADT-version

IN

pe/vehicle/api

The sales app uses this topic to determine which ADT version the vehicle uses.

pe/sales/diagnostics

ruter/<sender>/<vehicleRef>/pe/sales/diagnostics

pe/sales/diagnostics

Primary use: This topic is intended for health status for the RuterSalg application on each vehicle. The health status is intended both as a real time surveillance of health status for each individual bus as well as aggregating data per operator to see larger, more general issues. The topic can also, when enriched with other data, determine whether or not RuterSalg was used and working on a specific departure. Failure to have a working sales setup during a journey constitutes an SLA breach.

Possible secondary use: This topic may also be used by the operators to quickly discover issues with their own devices, as well as getting a general fleet-wide status if aggregated.

pe/sales/saleresult

ruter/<sender>/<vehicleRef>/pe/sales/saleresult

pe/sales/saleresult

No longer in use by Ruter

pe/sales/validationresult

ruter/<sender>/<vehicleRef>/pe/sales/validationresult

pe/sales/validationresult

No longer in use by Ruter

operational/assignment/attempt/request

OUT

assignment/attempt/request

signOff → code: FINISHED
When this message is received, the user is automatically logged out of RuterSalg if manual log out has not already been performed

pe/sales/current_stop

A variety of data needed by the RuterSalg app

IN

current_stop

With ADT 3, the RuterSalg backend starts producing a topic sent to the vehicle, containing a variety of data that is used by the app, like the current stop and zone, NEXT stop and zone, lineId and chainId.

RuterSalg uses this topic from version 2.6

pe/vehicle/api

ADT-version, VIN

IN

pe/vehicle/api

pe/sales/diagnostics

ruter/<sender>/<vehicleRef>/pe/sales/diagnostics

pe/sales/diagnostics

Primary use: This topic is intended for health status for the RuterSalg application on each vehicle. The health status is intended both as a real time surveillance of health status for each individual bus as well as aggregating data per operator to see larger, more general issues. The topic can also, when enriched with other data, determine whether or not RuterSalg was used and working on a specific departure. Failure to have a working sales setup during a journey constitutes an SLA breach.

Possible secondary use: This topic may also be used by the operators to quickly discover issues with their own devices, as well as getting a general fleet-wide status if aggregated.