EventCore
A privacy-conscious event tracking platform for locations, device states and field operations.
Problem
Many tracking and monitoring systems assume that cloud connectivity is always available and always acceptable. That assumption does not fit every environment.
On farms, vineyards, forestry plots, remote yards, and private industrial sites, mobile coverage may be weak or inconsistent. In other cases, the issue is not connectivity but data ownership: the operator may prefer that movement data, sensor readings, or operational records stay on-site.
I wanted to explore a system that could work in both worlds: connected to a hosted backend when that makes sense, or running entirely on local infrastructure when privacy, reliability, or independence matter more.
Outcome
- A working event-based tracking prototype that can ingest GPS positions from LoRaWAN nodes and display the current state of each device.
- A backend architecture that can run either in the cloud or fully on-site, depending on privacy, connectivity, and operational requirements.
- A flexible event model that can support location updates, sensor data, device states, scan events, alerts, and small remote commands.
- A validated direction for privacy-conscious IoT deployments in agriculture, forestry, asset tracking, and private industrial sites.
- Practical validation of where LoRaWAN is a strong fit, where other transports such as 4G or Wi-Fi are more appropriate, and how EventCore can support mixed communication layers under one backend.
Stack
Rust (event-sourced backend, runs self-contained on a small server) · LoRaWAN via ChirpStack (MQTT) · LoRa P2P (direct serial) · PostgreSQL (append-only event log) · Heltec LoRa nodes (GPS tracker, stick, e-paper display)
What EventCore is
EventCore is an event-based backend for tracking things, states, and locations.
The name is intentional. The system is not only about GPS. A device can emit many kinds of events: a position changed, a tag was scanned, a temperature threshold was crossed, a gate opened, a machine changed state, or a battery became low. EventCore captures those events, stores them reliably, and projects them into the live view the operator needs.
That live view is customized per deployment. For one client it may mean asset locations on a farm map. For another it may mean machine status, NFC scan history, delivery checkpoints, or sensor alerts. The platform defines the event spine; the business case defines what those events mean.
The communication layer is also flexible. The current prototype uses LoRa and LoRaWAN because they are well suited for low-power, wide-area environments. But the same backend can accept events from 4G devices, Wi-Fi sensors, wired systems, or a mixed deployment. EventCore is the operational layer above the transport.
The system can run in the cloud, on a normal hosted server, or fully on-site with the operator’s own gateway and backend. This is especially relevant for privacy-conscious deployments in Germany and Europe, where keeping operational data local can be a feature rather than a constraint.
Why Rust is the right fit
Rust is doing real work here, not decoration. An event-based backend has to ingest reliably, never lose an event, and project state correctly under load, sometimes on a small machine sitting on-site next to a gateway with no operator looking over it.
Rust gives memory safety without a garbage collector, predictable performance under sustained ingest, and a single static binary that drops onto a small server with no runtime to babysit. The type system also matches how the system thinks: events are immutable, state is derived from them, and the invariants that matter (every event is logged before projection, no event is dropped silently, no projection is built from partial data) are exactly the kind Rust makes hard to break. The language and the architecture are telling the same story in two different vocabularies.
It is also why I am comfortable putting this backend in a real client’s environment. A long-running event-sourced system on someone’s land has to keep ingesting reliably for months without anyone watching it. Rust raises my floor on what that looks like.
Prototype Validation
The current prototype ingests GPS positions from Heltec LoRa-based nodes through ChirpStack and projects them into a live operational view. Each incoming message is treated as an event, stored in an append-only log, and then transformed into the current state of each device.
This validates the core idea behind EventCore: the system is not limited to location tracking. A position update, an NFC scan, a sensor reading, a button press, a battery warning, a door state, or a command acknowledgement can all be handled through the same event pipeline.
The prototype also supports the reverse direction: small commands can be sent back to a node, for example to update an e-paper display, change a device state, or trigger a local action in the field. This makes the system more than a passive tracker. It becomes a lightweight command-and-state layer for distributed devices.
Early range tests with prototype hardware showed that LoRa communication can remain useful beyond short-distance indoor assumptions, especially when the deployment environment is open and the gateway position is chosen carefully. That gives a credible basis for use cases on open land, farms, vineyards, forestry plots, private yards, and other sites where mobile coverage is weak, expensive, or undesirable.
The important lesson is that EventCore should not be sold as “real-time phone-style GPS tracking”. That is not the goal. It is designed for long-running, low-power, event-based monitoring where the business value comes from knowing that something happened, where it happened, and what the current state is.
For real deployments, the right communication layer depends on the site. LoRaWAN may be suitable for wide-area, low-power coverage. 4G or Wi-Fi may be better for higher update rates or richer data. Wired or local sensors may make sense inside a building or fixed installation. EventCore is designed so these choices do not change the core system architecture.
That is the main result of the prototype: the value is not only in one radio technology, but in the event-based backend that can unify different devices, networks, and business rules into one operational view.
Where this could land
There is no single customer for EventCore yet, and I am being deliberate about the direction. The use cases I keep coming back to are the ones where the geography is open, the network is thin, and privacy is structural rather than optional:
- Agriculture. Knowing where livestock, equipment or sensor stations are on a working farm.
- Viticulture and forestry. Long thin parcels, thick canopy, and the option to keep the data on-site by default.
- Asset tracking on private land. Construction yards, rental fleets, anywhere you want a quiet, on-site source of truth.
If you have a problem that lives in one of those shapes, this is the kind of system EventCore is being built to become, and I would rather grow it with a real use case than guess at one in the lab. Get in touch.