Eeklin
Eeklin
IoT · Architecture
From device
to decision.
Production telematics and IoT stack — ingest, metrics, live portal, alarms, and reports on one path.
A platform already in production.
Devices publish. Parsers decode. The bus carries tracking, events, and alarms. Consumers write PostgreSQL. The metric engine derives distance, trips, fences, and violations. Alarms leave on SMS, email, voice, and more. Operators work in a live fleet portal; administrators run operations and ERP on the same auth.
Product overview: IoT platform. Engagement: See → Say → Build → Stay.
Data path.
End-to-end from the field to the operator — the same spine every estate uses.
- ParsersTCP or CMS poll per vendor. Decode to a common tracking payload — position, events, device alarms, IO and sensors.
- Message busTopic exchange for tracker data, events, and device alarms. Separate path for metric-driven notifications. Dead-letter queues with controlled replay.
- ConsumersBatch write to PostgreSQL: tracker history, events, last status per device. Device alarms persist and fan into the notification path.
- Metric engineReads tracker data in GPS time order. Distance, speed, trips, geofence dwell, vehicle state, and configurable metric events — sharded for scale.
- Alarm serviceContacts and templates by client, vehicle, and tracker. SMS, email, WhatsApp, push, and voice autocall when the estate is entitled.
- ApplicationsFleet portal for customers. Operations and ERP for administrators. Central auth issues JWTs for all three.
Fleet portal
Live picture for the customer
Map and list of last positions, movement and playback, KPIs, SOS, temperature and event reports, scoped by client and optional per-user vehicle assignments. Live position push over SSE when enabled, with poll fallback.
- Last position, live trail, and track playback
- Home KPIs and motion status from the live window
- Reports: events, violations, last update, temperature, and more
- Export and scheduled delivery where the operation needs a record
Operations & ERP
How the estate is run
Administrators configure devices, hierarchy, landmarks, IO mappings, and alarm policy. ERP carries business workflows and scheduled customer reports — including event and not-responding packs — on the same tracking read models.
- Device and fleet master data in Operations
- Tiered config: system → client → tracker, effective in GPS time
- Alarm policy and contacts at tracker, vehicle, and client levels
- Scheduled branded report email for entitled customers
Devices
GPS, cameras, and the next vendor
Tracker and camera (MDVR) paths already run in production — including live video estates and GPS-scoped reports. A new vendor is a protocol document, a parser adapted from ones we already ship, any new metrics, and the reports that estate needs. Recent dual-vendor camera onboarding completed in two to three days.
- Vendor protocol → parser on the common ingest contract
- Reuse of existing parser patterns for most of the work
- New metrics on the metric engine when the data requires them
- Reporting extended on the same read models and portal
Reliability
Built for messy field data
gps_time drives metrics; server_time drives health. Invalid samples are rejected. Consumers and the metric engine retry, then dead-letter with capped republish. Alarm channels use circuit breakers and backpressure. Observability sits on Prometheus and Grafana.
- Deduped, batched writes and hash-partitioned last status
- DLQ recovery with republish caps
- PgBouncer-backed writers and read replicas for portal load
- Parser monitoring and platform health dashboards
Stack at a glance.
- IngestParser nodes per vendor family — tracking data, events, device alarms.
- AsyncRabbitMQ topic topology, consumers, DLQ drainer, metric engine shards.
- DataPostgreSQL tracking and auth stores, views and live report models, PgBouncer.
- NotifyAlarm service plus SMS gateway — multi-channel delivery with feature flags.
- IdentityCentral auth — JWT web sessions, roles, entitlements, vehicle scope.
- SurfacesFleet portal (web and mobile), Operations, ERP, Grafana.
In the architecture
- Parsers
- RabbitMQ
- PostgreSQL
- Metric engine
- Alarms
- Fleet portal
- SSE live
- Ops / ERP
- Auth
- Grafana
Principles.
- What runs in production today?
- A full telematics and IoT stack: device parsers, message bus, consumers, PostgreSQL, metric engine, multi-channel alarms, fleet portal with live map and reports, operations and ERP surfaces, central auth, and observability. New device vendors attach as parsers on that path.
- How do new device vendors come on?
- With a vendor protocol document we add or adapt a parser — most of that work reuses patterns from parsers already in production — then wire any new metrics and reports. Camera devices from two vendors recently took two to three days end to end.
- Where does this sit against the IoT overview?
- The IoT overview is the product story for operators and buyers. This page is the system: data path, services, and how estates and device classes land on it.
Deploy on your estate.
Overview on the IoT platform. Thirty minutes on architecture and fit for your sites.