Trip completed

Know the moment an asset arrives somewhere, with one message that says where it came from, where it got to, how far it went and how long it took. A trip completed rule turns a stream of positions into a single delivery event, so your own systems can react to arrivals instead of working out where a journey started and ended.

Use it to close out a delivery in an order system, start an unloading clock, tell a customer their consignment has landed, or keep a duty log without anyone writing one.

What a trip is

Blecon reads an asset's history as stops and the trips between them.

A stop is a period when the asset was still, at one place.
A trip is one movement between two stops.

Two workspace settings decide where one trip ends and the next begins. Trip distance is how far apart two stops must be to count as different places. Stop time is how long an asset must be still before the movement either side counts as two trips rather than one. Anything shorter is recorded as a pause on the trip, so a lunch break or a wait at a gate does not split one delivery run in two.

Both settings live under Settings then Trips, and both can be overridden per asset type. A forklift working a yard and a truck crossing a country do not agree on what a trip is.

How it works

The rule fires once when a trip finishes, which is the moment the asset settles at its destination for longer than the stop time. It does not fire while the asset is still moving.

Each trip produces exactly one notification per rule, however many times the asset is seen afterwards.

The message names the asset and the journey, for example:

Van 12 completed a trip from Cambridge Depot to MK Delivery (41.2 km)

The notification carries the full detail for anything reading it programmatically:

Field	Meaning
`trip_id`	Identifier for this trip, stable enough to link to
`started_at` / `ended_at`	Departure and arrival, in UTC
`started_at_local` / `ended_at_local`	The same moments as the local clock where the asset was
`timezone`	The zone that produced those local times
`duration_seconds`	How long the trip took
`distance_meters`	Straight line between the two stops
`distance_is_approximate`	True when a zone's centre stood in for a missing position
`path_meters`	Distance actually travelled, when the route was recorded
`path_confidence`	How much of the route was seen: high, medium or low
`origin` / `destination`	The zone or coordinates at each end
`pause_count`	Number of pauses recorded during the trip

Parameters

Every parameter is optional. A rule with none set tells you about every trip, which is usually what an integration wants.

Parameter	Description
`min_distance_meters`	Only trips at least this far. Trips with no measurable distance are skipped when this is set.
`min_duration_seconds`	Only trips that took at least this long
`destination_zone_id`	Only trips that ended in this zone
`origin_zone_id`	Only trips that started in this zone

Like every rule, you can set its severity and limit it to specific tags or asset types.

See the rule types reference for the full specification.

Example: closing out deliveries

A distributor wants their order system to mark a drop complete when the van reaches the customer.

Create a trip completed rule with min_distance_meters set to 1000, so moves around the depot yard are ignored.
Limit it to the "van" asset type.
Add a webhook notification pointing at the order system.
The order system receives one message per arrival, reads destination and ended_at_local, and closes the matching drop.

Notes

Trips with no measurable distance still exist. Two zones with no boundary drawn produce a trip with a duration but no distance, which a min_distance_meters filter will skip.
Changing the trip distance or stop time changes what counts as a trip, so past trips are re-read under the new settings.
Arrivals appear in the asset's history and in the notifications list whether or not a notification channel is configured.