IoT and telemetry systems that turn field data into operational decisions

Where telemetry projects usually break

Signal without ownership, thresholds nobody trusts, dashboards that are pretty but inert, and time-series data that is stored but not explainable in a handover.

What Barberry designs and improves

Device to cloud: MQTT and HTTP patterns, buffering, back-pressure, cost-aware retention, and operator-friendly views. Time-series is described as time-series data on AWS (or your chosen store) without binding you to a single vendor name in sales copy until you lock the exact service.

Protocols, platforms and data layers

MQTT, LPWAN where relevant, ThingsBoard-class thinking, or lighter stacks when that is the right size.

Multi-tenant IoT platforms, rules and “who acts next”

Industrial-scale telemetry is rarely a single static dashboard. Work often includes per-tenant or per-site assets, rule chains and alarm paths people trust, and notification design (in-app, messaging channels, or hand-off) so night shift and day shift see the same truth. The goal is operability: a signal should map to a role, a threshold, and an action — not a wall of ambiguous red.

Field service, support systems and the IoT platform edge

Telemetry meets operations when the IoT platform lines up with field service and ITSM / ticketing (JSM- or HESK-class tools): ticket context, work-order-friendly identifiers, and runbooks that bridge “what the device said” and “what the crew or vendor did”. Barberry is comfortable across that seam — integration glue, automation where APIs are thin, and deployment discipline (environments, repeatable scripts, smoke checks against real stacks) so change does not outpace trust.

Product proof from PoolSense

See PoolSense and the product journey case for a concrete sensor-to-app story.

Engagement options

Review, pilot, or build alongside your team. Read models.