Route map with alarms

Route map with alarms

The standard trip map, plus the alarms raised along the route. Everything the trip map already does — tile providers, the route line, playback, widget actions — works unchanged. This page covers only what is added.

What this adds

• Alarms as markers, at the coordinates each alarm carries.
• Colour by severity, in the platform’s own colours, so the map agrees with any alarm table beside it.
• Active alarms pulse; a cleared one turns grey, goes still, and stays as a record.
• Live updates: escalate, acknowledge or clear an alarm and its marker follows, no reload.
• A card on click with the originator, severity, status, type, time and coordinates.
• Framing when the route is empty: if the device reported no positions, the view fits to the alarms.

An alarm appears wherever it happened, whether or not the device was reporting a position then.

Setting it up

Framing the view

If the route has drawn markers of its own, the trip layer frames the view and the alarms appear on top; nothing moves.

If it has not — the keys are there but the device reported no positions in this window — the map fits itself to the alarms instead, once, when they first arrive. One alarm is centred rather than fitted, since fitting to a point zooms to the maximum. Later updates never pull the view back, so panning survives.

Which alarms are drawn

• Raised by the entities in the datasource.
• Inside the dashboard timewindow — moving it changes the set.
• The hundred most recent, newest first.
• Only those with readable coordinates. The rest are skipped, not placed somewhere wrong.

What the alarms must carry

Only the coordinates need preparing. Everything else comes from the alarm. Put them in details:

{
  "latitude": 50.45370225625024,
  "longitude": 30.521168243145887
}

Where to write them

Alarm rules on a device profile — 4.3 and later. The rule’s Additional info takes a JSON template, and ${argument} substitutes a value from the rule’s condition:

{
  "latitude": ${latitude},
  "longitude": ${longitude}
}

Both arguments have to appear in that rule’s condition, otherwise there is nothing to substitute and the marker never gets a position.

A Create Alarm node in a rule chain — through its details script:

var details = {};
details.latitude = msg.latitude;
details.longitude = msg.longitude;
return details;

These shapes work too: nested under data, a JSON string, or a JSON string under data — { "data": "{\"latitude\":50.45,\"longitude\":30.52}" }.

Invalid JSON

If details do not parse, the numbers are read out of the text anyway and a warning goes to the console. That is a safety net, not a format to rely on.

Almost always the cause is the template itself. Semicolons instead of a comma is the common one — easy to type, and the Additional info field will save it without complaint:

{
    "latitude":${latitude};
    "longitude":${longitude};
}

No parser accepts that. It wants a comma between the two lines and nothing after the second.

Change that payload again — rename a field, quote a number — and the alarms vanish with nothing to explain why. Fix it where it is written.

Marker colours

The platform’s severity colours, so a theme that overrides them changes these too. Reduced-motion settings turn the pulse off.

The originator is always named on the card, including on a single-device dashboard; if it cannot be resolved the row shows a dash rather than disappearing.