Skip to main content
PulseVault

How PulseVault works

From a sensor on a machine to an alert on a phone, in about a second.

PulseVault system architecture A sensor unit publishes readings over Wi-Fi using MQTT to a message broker. The broker feeds an ingestion service, which writes to a time-series database. The ingestion service also feeds live dashboards over a WebSocket connection, and an alert engine which dispatches notifications by WhatsApp, email and phone push. Sensor unit on the machine Wi-Fi MQTT Message broker one message per cycle Ingestion service validate & convert Database time series + rollups Live dashboards WebSocket push Alert engine limits, suppression, escalation WhatsApp Email Push
A reading leaves the machine, is stored, and reaches a dashboard or a phone in about a second.

On the machine

The sensor unit sits on the outside of the machine with its probes clipped to the points being measured. It reads its inputs on a cycle of roughly 60 seconds, counts pulses continuously between cycles, and publishes one small message per cycle.

The unit holds no customer data itself. It knows its own identity, its Wi-Fi credentials and its sampling configuration — nothing else. A unit removed from a machine carries no production history with it.

Getting the data up

Readings travel over MQTT, a lightweight messaging protocol designed for constrained devices and unreliable networks. Each reporting cycle produces one small message rather than a continuous stream, which is why a unit works acceptably on the sort of Wi-Fi that a factory floor actually has.

Ingestion and storage

Every reading is validated, converted to engineering units and stored as a time series. Alongside the full-resolution data, the system maintains hourly and daily rollups, which is what keeps a chart spanning several months fast to draw instead of pulling back hundreds of thousands of points.

Live updates

The portal holds an open connection to the server and receives readings as they land, rather than asking repeatedly whether anything has changed. This is why the dashboard moves on its own — nobody has to press refresh, and a value on screen is the value the machine reported.

The alert engine

Every reading is evaluated against that channel's limits as it arrives. If a limit is crossed, the engine applies the suppression rules first — is this machine in a maintenance window, is this sensor snoozed, is the plant on a scheduled break — and only then raises an alert.

Once raised, the escalation policy decides who is told and in what order, and dispatch goes out over WhatsApp, email and push. Acknowledgement from any channel stops the escalation everywhere.

Security and isolation

Each customer's data is isolated, and that isolation is enforced on every query rather than assumed at the edges. Access within an account is controlled by role. Sessions use JSON Web Tokens with optional two-factor authentication, API keys are stored hashed, and every configuration change is written to an audit log.

Retention

Full-resolution readings are kept for 90 days by default, with summarised history retained for longer. Any channel can be exported over any period at any time, as CSV or JSON.

Reliability

A sensor that stops reporting is itself an alert. The portal detects silence within minutes and raises an offline notification, so a dead unit is never mistaken for a quiet machine.

Firmware is updated over the air, so the fleet stays current without a site visit — and your administrator controls which version is approved to run.

See it running on your own machine.

The fastest way to understand PulseVault is to watch it read a real machine. Book a demo and we will show you the live portal, walk through what it would measure on your plant, and tell you honestly whether it is worth it.