v1 · Shipping
Read-only rules.
Alarms and notifications on any bus event. Full trigger coverage across every NMEA-2000 parameter, Victron readings, AIS events, and GPS state. Rules stored as YAML in the boat config repo.
Platform · Automation
When this happens, do that.
Rules that fire across every device on the boat — not locked to one brand's app, not requiring a weekend of wiring Node-RED together. The automation engine is part of 32°N from the start.
What rules look like
Concrete actions, not alarm-only.
Rules read from the bus and, where permitted, write back through capability-scoped tokens. The trigger side covers every sensor on the bus. The action side starts with alerts and grows to control in later releases.
When anchor depth changes by more than 5 m from drop point
→ sound alarm + send push notification to crew devices
Anchor watch When house-bank state of charge (SOC) drops below 30%
→ shed loads in the configured priority order
Load shedding When NMEA-2000 (National Marine Electronics Association 2000) wind speed at masthead exceeds 25 knots
→ alert on all screens + log event
Wind alarm When boat enters the marina geofence
→ activate marina mode (nav lights off, alert volume low, anchor watch disarmed)
Scenes When passage route completes anchor drop sequence
→ start depth logging + arm anchor watch automatically
Scenes When bilge pump run-time in 24 h exceeds 10 minutes
→ send alert + add inspection reminder to maintenance log
Maintenance Under the hood
Rules live in your repo, not inside a vendor's cloud.
Rules are YAML files stored alongside your boat configuration. No proprietary format, no account-tied storage. The engine reads from the bus and writes through the same capability-scoped tokens the rest of 32°N uses.
Cross-vendor by design.
Victron battery monitors, NMEA-2000 instruments, AIS receivers, WiFi-attached sensors — the rule engine sees them all as the same typed bus events. A rule that fires on battery SOC works whether the battery monitor is Victron, Mastervolt, or anything else that feeds the bus.
Scoped, audited write access.
Write actions — load shedding, relay control, autopilot waypoint changes — are gated behind explicit capability tokens. A rule that sheds loads has to declare that capability up front. Every action lands in the audit log. Nothing fires silently.
Scenes compose rules into moments.
"Marina mode" and "anchor mode" are scenes: named groups of rules that activate together. Drop the hook and the scene arms the anchor watch, starts depth logging, and adjusts alert volumes in one step. Scenes can be triggered manually, on a schedule, or by a bus event.
AI proposes, you approve.
In a later release the AI agent will observe your patterns — "you always arm the anchor watch after dropping the hook at 18:00" — and propose a rule. You read it, approve it, and it drops into your repo as YAML. The agent never activates rules on its own.
Roadmap
Where this is going.
The rule engine ships in phases. Each phase adds more of the action side — the trigger side is complete from v1 because the whole bus is already readable.
v1.5 · Next
Write actions.
Load shedding, relay control, and autopilot waypoint changes — each gated by explicit capability tokens and requiring user approval per rule type before the first activation.
v2 · Later
AI-proposed rules.
The AI agent observes patterns in the log and proposes new rules. Proposals come to you as diffs against your YAML config — approve, reject, or edit before anything activates.
Read about the full platform.
The demo lets you explore 32°N without any hardware. The platform page has the full five-layer picture — where automation fits in alongside the bus, OS, and cloud layers.