Overview
The rest of the documentation describes what Yggio does, feature by feature. This section describes what it is for, by walking through deployments that exist: which question is being asked, which sensor answers it, and what has to happen between a reading arriving and somebody acting on it.
They are written as patterns rather than as product sheets. The sensors named are the ones commonly used for that job, but nothing here depends on them - Yggio takes any vendor's device, and the shape of the deployment is the part worth copying.
The use cases
| Use case | The question it answers |
|---|---|
| Asset tracking | How many are in this zone, and which ones have stopped moving? |
| Internal mail collection | Is there anything in this box, or is the round collecting nothing? |
| Office utilization | Which spaces are actually used, as opposed to booked? |
| Oil and other liquids | Did the liquid that matters leak, as opposed to any liquid? |
| Real estate | What does a property portfolio run on once the data is in one place? |
| Warehouse racking | Which racks have been hit, and which are quietly deteriorating? |
| Water leak detection | Has water reached somewhere it should not be, and who now knows? |
What they have in common
Each one follows the same three steps, and the middle one is where most of the work is:
- Measure at the point where the answer is. A leak sensor at the low point of a riser cupboard, a presence sensor under the desk edge. Coverage is a design decision, not a product feature.
- Normalise. Devices from different vendors describe the same thing differently. A translator turns each payload into the same named fields, so a dashboard built for one sensor keeps working when the next one is a different make.
- Act. A reading that nobody sees is not worth collecting. The Rule Engine decides who is told, how urgently, and what happens if nobody acknowledges.
The precondition under all three
The sensor has to reach the network from the exact place the question is asked. That place is chosen by the problem, not by the radio - the low point of a riser cupboard, the bottom of a lift pit, the inside of a steel outbox, an aisle deep in a racking bay - and those are precisely the spots where coverage is worst.
It is the most common reason a well-designed deployment underperforms, and it is cheap to rule out: verify the link at each sensor position during commissioning rather than inferring it from a gateway's nominal range, and keep monitoring link quality afterwards, so a sensor that has gone quiet is raised as a fault instead of being read as good news. A leak sensor reporting nothing and a leak sensor that cannot reach the network look identical from a dashboard.
Plan the gateways around the awkward positions rather than the convenient ones. See LoRaWAN.
Every page here assumes the platform underneath is the same one described in the user guide: the same devices, access rights, dashboards, rules and reports. A use case is a way of arranging those, not a separate product.
Starting one
The pattern that works is narrow and evidenced rather than broad and planned:
- Pick the smallest deployment that would settle a real question. One building, one floor, one season.
- Take the question from something already documented - a claims history, a booking system's no-show rate - so the result can be compared against what was believed beforehand.
- Test the whole chain, including the part where somebody is woken at three in the morning, before trusting it.
- Extend on what the first season showed, not on a checklist.
The platform is the same whichever use case comes first, which is why a leak pilot and an occupancy pilot end up on the same Yggio instance rather than in two systems.