Sensors, a gateway and a dashboard that survives the internet going down

What this actually solves

The equipment usually exists already. A cold store has probes in every chamber, a fleet has trackers in the cabs, a building has meters on each floor. What does not exist is anywhere to look. Readings sit inside three separate vendor apps, or on a controller display bolted to a wall that nobody is standing in front of at two in the morning, and the loss those sensors were bought to prevent happens anyway.

So the dashboard is what gets asked for, and the alerting is what earns the money. A chamber that drifts warm overnight is found at eight the next morning as spoiled stock. A truck that has been stationary for three hours in the wrong place is found when the customer calls. Both of those are losses that were fully visible in data nobody was watching. The value of this work is the gap between the reading existing and a named person being told about it in time to act.

Which leads to the thing worth saying plainly before any of the rest. An industrial monitoring system is judged on what it does when the connection drops, not on what it does when everything is up. A demo on office WiFi proves almost nothing. On a real site the internet goes several times a day, the power goes on top of that, and the first honest test of the build is what the record looks like afterwards. If two hours are missing from the history, you stop trusting all of it, including the parts that are correct.

How the work runs

1. Scope the site and design the data path. What the devices are, what they can already publish, where the gateway sits, and the topic structure they publish into. Topic design sounds like a detail and is not — a naming scheme that reads cleanly with wildcard subscriptions is what lets six chambers become sixty without a rewrite, and it cannot be changed cheaply once devices are in the field. Ends with one device reporting end to end. One to two weeks.
2. Build ingest and storage. A broker you control — Mosquitto or HiveMQ — and a service that subscribes and writes to a time-series database, TimescaleDB or InfluxDB. Writes are batched rather than one round trip per message, reconnect logic is in from the start, and the schema carries a retention policy plus continuous aggregates so the charts later read hourly rollups instead of raw rows. Two to four weeks.
3. Build the alerting, including device health. Rules stored in the database rather than in code, so a threshold or a recipient can change without a release. Each rule has a condition, a duration it must hold for, recipients and a channel — the shape being something like a chamber staying above its limit for eight continuous minutes, notifying two named people. Flapping suppression so a sensor sitting on the boundary does not send fifty messages a night, and an acknowledge path so a known problem stops shouting. Separately, a rule for silence — no data from a device inside its expected window is itself an alert. Two to three weeks.
4. Build the dashboard and device management. Live values, history at the ranges people actually ask for, and the administrative side that gets forgotten — adding a device, retiring one, seeing which are online, pushing firmware. Grafana or ThingsBoard where a standard panel set is enough, a custom front end where the operational views are specific to how the site is run. Three to five weeks.
5. Rehearse the failures on site. Pull the network at the gateway and confirm buffering and backfill. Cut power to a device and confirm the silence alert fires. Restart the broker and confirm every client reconnects without a person. Push a value across a threshold and watch who receives what, on the phone they will actually receive it on. Nothing is signed off from a laptop. One to two weeks.

Node-RED is useful in the middle of this for wiring up and inspecting flows quickly, particularly while a stubborn device is being characterised. On the hardware side the common pairing is an ESP32 class board at the sensor and a Raspberry Pi class machine as the gateway.

What moves the price

The range is $3,000–$40,000 over 2–6 months, and three things decide where a given project lands in it.

Whether hardware is in scope. Software only — gateway configuration, ingest, storage, dashboard, alerting, device management — is one job. The moment physical devices are being sourced and shipped, the project acquires customs, lead times, installation days, spares and warranty obligations, and those change the shape of the engagement more than any amount of code does.

How cooperative the devices are. A modern sensor that publishes structured messages to a broker is quick. An older controller that only speaks to its own software, or outputs something undocumented that has to be characterised on site with a laptop plugged into it, can take longer than the entire dashboard. This is worth establishing device by device before a number is agreed, not after.

How much rule logic and history there is. Ten devices with one threshold each is not the same as several sites, tiered escalation, quiet hours, per-shift recipients and a retention window long enough that the raw table needs a real storage plan. Rules and retention are the two places where scope grows quietly after the dashboard already looks finished.

What usually goes wrong

The connection is assumed to be permanent. This is the failure the whole system gets judged on, and it is almost always designed in on day one, because the whole thing was built next to a router. The gateway needs local buffering and reconnect written at the start, not added after the first outage, and it needs testing by actually unplugging something. A system that loses data during a two-hour dropout has not lost two hours — it has lost your confidence in the record, which is much harder to get back.

Nobody builds the alert for silence. Alerting on values out of range is the obvious rule. Alerting on values not arriving is the one that gets skipped. The result is the worst possible failure mode — a dead sensor, a flat battery or a crashed gateway produces a dashboard that looks calm, holding the last reading it ever received, while the chamber it was watching does whatever it likes. Missing data has to be its own rule, with its own expected reporting interval per device.

Alerting fires so often that people mute it. Two causes, both avoidable. Rules hardcoded into the application, so nobody adjusts a threshold that is obviously too tight because it means a deployment. And no hysteresis or acknowledgement, so a reading hovering on the limit sends messages all night, and the group gets muted. An alerting system nobody reads is worse than none, because everyone believes they are covered.