- LoRaWAN, cellular, and legacy serial IoT devices normalised to a single event stream
- More data sources feeding the wider system — larger, more detailed council warnings
- On-site field work installing and updating flood monitoring hardware
- Our layer built to be legible and extensible by the other teams on the project
The problem
A hydrology company contracted to major Australian councils was monitoring flood risk across a region using a scatter of IoT devices — different sensor types, communication protocols, and data formats, bought at different times. Individually they worked. As flood intelligence they didn't agree with each other, which made the whole picture something you had to assemble by hand at the exact moment speed mattered most.
Our part
This was one of our first projects, and we built one layer of a much larger system. Councils, the hydrology company, and other contributors were all building the wider flood warning network. Our scope was the data and brokering layer in the middle.
A data broker normalises inputs from LoRaWAN gateways, cellular modems, and legacy serial devices into a single canonical event stream. The wider system subscribes to that one stream instead of wiring itself to every device individually — which is what let more sources feed the picture, and councils be warned earlier and in more detail.
The stack is deliberately ordinary — MQTT, Node-RED, PostgreSQL — because our layer had to be operated and extended by the other teams on the project, not just by us.
In the field
The work wasn't only at a desk. Bringing a source online meant trusting what it sent, and that meant going to where it was — field trips to help install and update flood monitoring hardware on site, and confirming devices were reporting cleanly before our layer ever tried to normalise them.
What it added up to
A single layer, built to be legible and extensible by everyone else on the project — so the teams who kept the system running could build on our part without depending on us to do it.
