Connected devices, sensors and the dashboards that turn ten thousand readings a day into one decision.
Sensors Are Easy. Answers Are Not
Putting a sensor on something is the cheap part. The hard part is getting ten thousand readings a day into a form where somebody can act on one of them.
We build the whole chain (device, connection, storage and the screen a person actually looks at) and we start from the decision you want to make.
Device Connectivity
Getting readings off hardware reliably over wifi, mobile or LoRa, including when the signal drops.
Edge Processing
Filtering and deciding on the device, so you send what matters instead of everything.
Data Pipelines
Ingest, storage and retention sized for the volume, with history you can still query in three years.
Dashboards & Alerts
The screen on the wall and the message at 3am, both built around what somebody will do next.
Predictive Maintenance
Patterns in the readings that show a part failing before it fails.
Device Security
Identity per device, signed updates, and a way to revoke one that has gone missing.
Prototypes work on a desk. These are the five things that take a fleet down, and what we build in from the start so they do not.
The signal goes
A site loses connectivity for six hours and the readings for that window are gone forever. Store-and-forward on the device means they queue locally and arrive in order when the line comes back.
WHAT WE BUILD IN
Store and forward, always
The battery dies early
Reading every thirty seconds instead of every five minutes is the difference between five years and four months. Sample rate is a commercial decision, not a technical default.
WHAT WE BUILD IN
Sample rate agreed in week one
Nobody notices a dead sensor
A device that has stopped reporting looks exactly like a device reporting that nothing is wrong. Every unit sends a heartbeat, so silence raises an alert on its own.
WHAT WE BUILD IN
Heartbeat and silence alerts
The data arrives but nobody acts
Ten thousand readings a day with no threshold is a dashboard nobody opens. We agree the decision and the trigger before anyone writes a line of ingest code.
WHAT WE BUILD IN
One decision, defined first
A device goes missing
Hardware walks off sites. Identity per device and signed updates mean one unit can be revoked without touching the other nine hundred.
WHAT WE BUILD IN
Per-device identity
Define
The decision the data must support, and what it is worth getting right.
Prototype
One device, one reading, end to end, on your actual site.
Pilot
A handful in the field for a month, to meet the real signal and the real weather.
Scale
Provisioning, updates and monitoring for the whole fleet.
Operate
Dashboards, alerting, and a sensible process for the ones that die.
What You Actually See
The point of the whole chain is the last two screens. This is what a working deployment looks like to the people who use it.
The operations view: live status across the fleet, with anything out of tolerance pulled to the top rather than buried thirty rows down a list.
The engineer’s view on a phone: the three readings that matter for the unit in front of them, plus the history that explains the callout.
Built around the callout, not the data
Every dashboard we build starts from one question: what will somebody do differently because of this screen? If there is no answer, we do not build the screen. It is the quickest way we know to keep a connected system from turning into an expensive wallpaper.
SalonTracker
Equipment that reports its own usage
SalonTracker needed usage and lamp hours from equipment across six hundred salons. We built a small controller that reports each session and flags a lamp before it drops below standard.
Read the Case Study
Common
Questions
Can’t see your question? Call us on 0113 242 4001 or email contact@redev.co.uk.
Talk to Us
