SK
Signal K•2mo ago
AdrianP

AdrianP - MOB (POB) Notification dataThe Notif...

MOB (POB) Notification data The Notification specification is silent on how to provide additional data in notifications. This has left it up to plugins and apps to do their own thing, which is fine for most cases but not for Alarms such as Person Overboard. There is an outstanding Freeboard-SK issue regarding the "alignment" of MOB notifications from various sources, so in an attempt to get alignment here is my proposed MOB Alarm notification to allow us to move forward (and inform any update to the spec) : 
{
   "state": "emergency", // as per the current spec
   "method": ["visual","sound"], // as per the current spec
   "message": "alarm text!", // as per the current spec
   "position": {"latitude": 25.34, "longitude": 9.345},  // position where alert was raised
   "createdAt": "2025-03-17T05:49:23.869Z",  // datetime at which alert was raised
   "properties": { ... }  // key-value pairs to hold additional data as required.
}
{
   "state": "emergency", // as per the current spec
   "method": ["visual","sound"], // as per the current spec
   "message": "alarm text!", // as per the current spec
   "position": {"latitude": 25.34, "longitude": 9.345},  // position where alert was raised
   "createdAt": "2025-03-17T05:49:23.869Z",  // datetime at which alert was raised
   "properties": { ... }  // key-value pairs to hold additional data as required.
}
3 Replies
Владимир Калачихин
Владимир Калачихин•2mo ago
I don't find it convenient and won't use it in my apps. In my GaladrielMap SK ed, E-InkDashboardModern and netAIS I use a different set of information and I'm not going to change anything.
AdrianP
AdrianPOP•2mo ago
For those interested in interoperability please provide your feedback / comments.
A.R.
A.R.•2mo ago
I think there are a few items to consider for an MOB message. 1. The definitions for the NMEA 0183 and 2000 sentences: https://paperzz.com/doc/8831733/nmea-0183-man-overboard--mob----national-marine-electronics NMEA 2000 is PGN 127233 for which I cannot find a document. This for interoperability In general: - An ID for the MOB message unique to the this mob alert (can be inferred from the path, see below) - An MOB position - An indicator for if the type of position (dynamic (MOB responder is in reach and sending a position), alert postion - when the alarm was raised, last seen - the last position an MOB sensor was last seen) (I think this is also in the link above) - An MOB alert source, this could/should be in the extra data. - Wether it is an update or an initial alert. This can also be inferred by the notification path using the format of ....notification.mob.<unique-id> as per the notification spec. Also applications handeling the MOB alert (and others) should handle the proper notifacation paths so that acknowledging an alert (and thus silencing the alert, but not yet resolbing) is handled so crew does not need to silence all alarms in a situation that probably went from normal to super stressfull in an instant. Last sentence can perhaps be clarified. If an MOB currently is raised, openplotter, KIP, FreeboardSK and perhaps others will sound audible alerts. If I test this now I need to silence KIP (which will silence other KIP running devices) FreeboardSK and openplotter alert manager. An alert acknowledged update notification with the same path should silence them all.

Did you find this page helpful?