Equipment vendors, network protocols, and BoatKit rules all express problems differently. BoatKit translates supported conditions into a common alarm state, then presents that state beside the tank, engine, power system, watermaker, position, or other data that explains what is happening.
Detected sensor and engine measurements can carry direct low and high limits. Power System settings expose the values and statuses reported by each item as named rows, so an operator can configure a battery state-of-charge limit, a voltage or current boundary, or an abnormal charger, inverter, converter, or availability state without building a separate rule. Incoming NMEA 2000 engine alarms are monitored by default for visible, active engines.
Supported Shelly devices use the same direct model. Each discovered signal has a typed settings row: numeric values can carry independent low and high limits, on/off values can alert on either state, and any signal can alert if the device or value becomes unavailable. Temperature thresholds follow the operator’s preferred units, and hiding a signal from ordinary gauges or history does not silently disable its alert.
The same Advanced Monitoring controls apply across these direct alerts: choose warning or alarm severity, require a condition to persist before it triggers, require recovery to persist before it clears, and add hysteresis to numeric thresholds to prevent chatter around a boundary. Limits still come from the equipment manufacturer and the vessel’s installation guidance.
On the boat, an alarm can appear in the Viewer, sound through an attached audio output, and—where the integration supports it—be sent to a compatible chartplotter network. Those local paths do not need an internet round trip.
BoatKit Cloud adds selectable mobile push, SMS, and verified-email delivery while the vessel is connected. Destinations and event types can be chosen deliberately, so routine changes do not become remote noise and critical conditions can reach the people responsible for the boat.