Add data attribute to Alarm object used in Notification messages

[panaaj]

Current state:
Currently the alarm object used in notification messages lacks the ability to convey values (other than in the message text).
Consider the standard alarm MOB (man overboard), one would expect that the position at which the alarm was raised is included in the alarm object. instead the position can only be added as text in the message which is likely to vary from implementation to implementation and making it more difficult to parse.

{
    "method": ["visual", "sound"],    
    "state": "emergency",    // enum string value
    "message": "Man Overboard!  latitude: 60.2345, longitude: 14.1234"   // position included in message text
}

Proposal:

• Add an attribute to the Alarm object used in notifications to hold data relevant to an alarm
• Define minimum required attributes for the standard alarms.

STANDARD ALARMS:

• 'mob'
• 'fire'
• 'sinking'
• 'flooding'
• 'collision'
• 'grounding'
• 'listing'
• 'adrift'
• 'piracy'
• 'abandon'

Example: vessels.self.notifications.mob

{
    "method": ["visual", "sound"],    
    "state": "emergency",   
    "message": "Man Overboard!",
    "data": {      // optional object to hold addiditonal alarm information
        "position": {"latitude": 60.2345, "longitude": 14.1234}
    }
}

[bergie]

This is a very good idea. Now in signalk-meshtastic we try to find the corresponding "vessel" from Signal K data model to find the position:
meri-imperiumi/signalk-meshtastic@609f553

We could maybe experiment with this in https://github.com/meri-imperiumi/signalk-mob-notifier which raises notifications.mob when it sees beacons

[VladimirKalachikhin]

There can be more than one MOB, so the "data" must be a geoJSON object.

[bergie]

In signalk-mob-notifier we raise notifications.mob.<MMSI> so there can be multiple MOBs but each gets their own notification (the message also contains distance and bearing)

[VladimirKalachikhin]

Does only one MOB drop from each mmsi?

[bergie]

Each MOB beacon should have its own unique MMSI

I guess the way the spec is written there could be MMSI collisions, but the likelihood of two colliding ones firing at same time in same area is probably pretty low:

The MOB (Man overboard) device that transmits DSC and/or AIS should use an identity
972XXYYYY, (where xx = manufacturer ID 01 to 99 assigned by CIRM; yyyy = the sequence number 0000 to 9999. When reaching 9999 the manufacturer should restart the sequence numbering at 0000.The manufacturer ID xx = 00 is reserved for test purposes). Combination DSC AIS devices will transmit one common user ID

https://www.cruisersforum.com/forums/f134/personnal-ais-mob-beacon-unique-mmsi-182594.html

[VladimirKalachikhin]

Does every mob drop with a buoy?

[bergie]

Non-beacon MOBs are out of scope for signalk-mob-notifier. Assumedly you'd want to raise those in some app like Freeboard and record the position there.

Some fancy navigation systems try to estimate the drifting of the mob based on wind and current conditions.

[VladimirKalachikhin]

I think the format of the MOB information should be the same everywhere.

[bergie]

There's nothing preventing from a plotter app (say, Freeboard) from adding a position when MOB button is pushed.

[panaaj]

Freeboard-SK does add a position and a timestamp.
It also ensures the notification has an id so it can be cleared, silenced etc.

[bergie]

@panaaj is the format compatible to the one proposed here?

Here's how it looks like with the mob-notifier plugin:

path: `notifications.mob.${mmsi}`,
value: {
  message,
  data: {
    mmsi,
    position: mobPosition,
  },
  state: 'emergency',
  method: ['visual', 'sound'],
},

I'm happy to make modifications to align with Freeboard-SK if needed, but then we should document the format in spec.