Octopoda Data
Field data becomes a service.
In brief
Your machines report readings, logs, incidents. Data turns that into a service your customer consults for themselves.
Each account has its own portal: what its devices send lands in its database, appears on its site, and triggers its alerts. There is no infrastructure to set up.
Sensors are declared in a configuration file: no code to write to add a reading or a threshold.
And alerts reach the person who can act — email, SMS, notification.
What it brings : You sell the monitoring of your machines as a service, without building infrastructure for each customer.
In detail
Each account gets its own data portal: what its devices report — telemetry, logs, events — lands in its database, is displayed on its site and triggers its alerts. With no infrastructure to set up, isolated from other accounts, deployed in one click.
Data can be bought on its own. An operator of water fountains, sensors or machines who first wants to see their fleet before making it sell. Distrib is then switched on in the same portal.
Who it is for
| Audience | What they find |
|---|---|
| Operator, manager | Dashboards, alerts, fleet health, exports — with no technician. |
| The operator's own customer | Their own scope, under the operator's brand, on their domain. |
| IT and security management | One database per account, on their side if they want, and scopes enforced server-side. |
| Integrator | Declarative telemetry with no code, a direct ingestion interface, a stable data contract. |
What the suite does
Collecting, with nothing to set up
- From the devices: readings and logs travel up through the platform.
- Sensors are declared in the configuration: no code to write.
- A generic module listens to them and raises the alerts.
- The same code runs against the simulator and against real hardware.
- From a third-party system: a direct ingestion interface, documented and isolated by account key.
- Business files — including the standard exports of vending machines — through the same path.
- Sampling pipelines in self-service: keep as is, filter, aggregate by window, apply a dead band. Several pipelines per feed, and a feed with no pipeline is never ingested by accident.
Seeing, in the account's portal
- Composable dashboards — multi-series curves, gauges, indicators, tables, latest alerts — per context.
- Devices: a list with configurable columns, online or offline status, how long a device has been down, and a record per device with its series.
- Records and logs queryable by device, feed, period and level, with configurable retention.
- Fleet health projected as one more piece of business data: online and offline counters, embedded versions, infrastructure alerts.
- Anomaly detection and analysis: trends, history, periodic reports.
- A common base for every list: search, filters, sorting, export, tabbed sections, and labels translated into each user's language.
Modelling — devices, feeds, records
A device exists from its first heartbeat, with its exact identity. Three notions of type coexist: the technical type, the business nature and the type of the point of sale. Records are kept raw and read by path, logs keep their original line, and presence is derived both from data freshness and from the sign of life.
Preventing — alerts
- Rules that cross a type and a level with actions.
- Three channels: email, SMS, live notification.
- Messages composed from the event's own data.
- Dynamic recipients: the address of the consumer concerned, for instance.
- Episodes that open then clear, with their detail page. The record is systematic: an alert that no rule picked up stays visible.
- Raised by the platform: device offline or back, recording error.
- Raised by the business side: sale settled, put under review, capture failure, debt created.
- Self-service unsubscription, and ready-made rules according to the account's facets, in seven languages, never with an operator address written in.
Isolating — accounts and scopes
- One database per account, with its own secret in the vault.
- Cost follows activity: paused for a dormant account, provisioned for an active one.
- Contexts: a single portal, divided into scopes along eight combinable axes.
- A role, a visual identity and a dashboard per context.
- The user axis makes the consumer site a context like any other.
- The restriction is enforced server-side, not merely on screen.
- Users managed by the account: roles, optional open sign-up, enterprise authentication.
Branding — the customer's identity
Title, logo, theme, pages and the vocabulary of types are configurable online, with no development, and per context. The end customer can have their own domain, certificate included, and content is translated into seven languages, including Arabic.
Reporting — exports and timelines
Four reports exact to the cent — sales, VAT, receipts, subsidies — "as at" a chosen day, in the site's local day. Alongside them, a unified timeline per device, an action log, and a published interface contract.
Identifying — the octopod
Every point of sale has a business identity distinct from the box fitted to it, and the link between the two is dated: changing the device loses neither the history nor the configuration. A technician application on the machine's screen handles pairing and factory tests.
The sites
| Site | Audience | Content |
|---|---|---|
| Manager portal | The manager | Every subscribed facet: dashboards, devices, records, feeds, rules, alerts, logs, points of sale, users, configuration. |
| Portal per context | The operator's own customer | The same portal, restricted to their scope, under their brand. |
| Distrib sites | Consumers, field, counter | Instances of the Distrib facet, on the same database. |
What it shares with Distrib
The portal, the contexts, the alerts, the ingestion, the white labelling, the point-of-sale identity and one-click commissioning are the Octopoda foundation: Distrib composes onto it.