Many sensors, one warning: our part in a flood network

One layer of something much bigger

This was one of our first projects, and it's worth being clear about the shape of it up front: we did not build a flood warning network. We built one layer of one.

The client was a hydrology company holding contracts with major councils around Australia — the kind of organisation whose job is to know what the water is doing across a region and to tell the people who have to make decisions about it. The system that answers that question was large, and it was being built by a lot of hands: council teams, the hydrology company's own people, and us, working across all of them.

Our part was specific. We built the data and brokering layer — the piece that took a scatter of IoT devices across the area, speaking different protocols in different formats, and turned them into a single stream that the wider system could use to warn councils earlier and in more detail. The short version lives on the project page. This is the longer one — what that layer actually did, the field trips that came with it, and why we'd rather tell you about the part we owned than claim the parts we didn't.

The problem our layer solved

Flood monitoring across a region isn't one tidy network. It's whatever sensors exist, bought at different times for different reasons — some on LoRaWAN, some on cellular, some older gear speaking a serial format that predates everything around it.

Individually, every one of those devices worked. The problem was that they didn't agree. Different formats, different units, different ideas of what a timestamp meant. To ask what is happening across the whole area right now you had to reconcile several sources by hand — and a warning system that depends on someone reconciling feeds under pressure is slowest at the exact moment it needs to be fastest.

That reconciliation is the job we took. Not the sensors, not the council-facing warnings at the far end — the layer in the middle that let many sources become one trustworthy picture.

What we built

A data broker with one canonical event format, and adapters doing the translation at the edges.

• LoRaWAN, cellular, and legacy serial devices keep speaking exactly what they already spoke.
• Each source feeds an adapter that normalises it — units, timestamps, site identity — into one shared schema.
• The wider warning system subscribes to that one clean stream instead of wiring itself to every device individually.

The stack underneath is deliberately ordinary: MQTT as the message backbone, Node-RED for the per-source normalisation and routing, PostgreSQL as the record of what arrived and when. Ordinary is the point. Whatever we built was going to be operated and extended by people who weren't us, inside a system much larger than our piece of it — so it had to be something a competent team could reason about and hire for, not a clever thing only its author understood.

The effect of that middle layer is that adding a source, or a whole new class of device, stops being an event for everything downstream. The canonical stream doesn't care what a reading was born as. It cares that it arrives in the one shape everyone agreed on. That's what let the broader system give councils larger, more detailed warnings — because more sources could feed the picture without each one becoming a bespoke integration.

The part that wasn't in the diagram: the field

A brokering layer sounds like something you build entirely at a desk. It wasn't.

To bring a source online you have to trust what it's sending, and to trust that you have to go to where it is. So the work included trips out to the field — places like Ballina — helping install and update flood monitoring hardware on site, confirming that a device was actually reporting cleanly before we ever pretended our layer could normalise it.

That's a thing we believe about this kind of work generally: you cannot broker data you've never stood next to. The seam between a sensor in a paddock and a clean event in a database is where the real faults live, and the only way to know your layer holds is to have been at both ends of it.

Working across everyone

The other thing this project taught early was that our layer was only ever as useful as its fit with everyone else's.

We were one team among several — councils, the hydrology company, other contributors — all building toward the same warning system. Nobody involved could point at the whole thing and say that's mine. Our job was to make our part correct, legible, and easy for the next team to build on, and to do it without becoming the piece everyone had to route around.

That's an unglamorous kind of contribution, and it's most of what real infrastructure work actually is. The systems that matter are rarely built by one team in one place. They're assembled, across organisations, by people who mostly never meet — and they hold together only if each part was built to be handed on.

Why we still point to it

It was an early project and a small part of a big system, and we'd tell you both of those things before you asked. We point to it anyway, because it's the clearest early example of the thing we're actually good at: taking a mess of sources that don't agree and turning them into one stream something important can depend on — and building that piece so it belongs to the people who keep it, not to us.

A layer that only works while its authors are on call isn't infrastructure. It's a dependency wearing the shape of one. The part we built was meant to outlast our involvement in it, and it did.

If you're running an operation on data you can't quite see all at once — sources that don't agree, a picture you assemble by hand when it matters most — that middle layer is exactly what we build. Tell us about one part of it and we'll give you an honest read.