Support References
Where to look when something is not working, and how to reach us when looking has not been enough.
Most of what goes wrong has been seen before and is written down somewhere in these docs. This page is the map: a short checklist to work through first, then an index of every troubleshooting section across the documentation, since they live with the feature they belong to rather than in one place.
Before you contact us
Four steps, in order. Each of them resolves a good share of what would otherwise become a ticket, and the ones that do not are much faster to answer when you have already been through them.
1. Search the documentation
Use the search box at the top of any page. It covers every page, not just the section you are in, and searches the full text rather than only titles.
Search for the error message or the field name rather than a description of the symptom. The exact string from a log line or an API response is far more likely to find the page you need than "device not reporting".
2. Ask the AI assistant
The AI Assistant can answer questions about the platform from the documentation, which is often quicker than finding the right page yourself, especially when you are not sure what the thing you need is called.
It is good at "how do I", "what does this field mean" and "which page covers this". It cannot see your devices or your data, so it will not tell you why one specific sensor stopped reporting.
3. Check the logs
Logs record device updates, alarms, access rights changes, edits and downlinks, and can be filtered by resource, type, priority and category. A device that is not behaving usually has something to say here.
For a single device, the Logs tab on the device page shows only that device's history, which is normally where to start.
4. Establish which side the data stops on
This is the single most useful thing you can do before raising a ticket, because it decides whether the problem is one we can act on at all.
For anything reporting over MQTT, connect MQTT Explorer to the Yggio broker and subscribe to the topic. If the message never arrives at the broker, the data has not reached us and the fault is upstream of Yggio: the device, the network, the credentials or the topic. If it arrives at the broker but nothing appears in Yggio, the fault is ours.
The equivalent for other integrations is the same question asked differently: is the data arriving at Yggio at all, or failing before it gets here?
Contact support
If you have been through the four steps and the problem is still there, or the data reaches Yggio and then stops, raise a request:
Include as much of this as applies. It usually removes an entire round trip:
- What you expected to happen, and what happened instead.
- The device, connector or report involved, by name and by id.
- When it last worked, if it ever did.
- The exact error message or log entry, copied rather than described.
- Where the data stops, from step 4 above.
- What you have already tried.
Troubleshooting by area
Troubleshooting lives with the feature it belongs to. This is the index.
Devices and connectivity
| Topic | Where |
|---|---|
| NB-IoT devices, from SIM to first packet | NB-IoT Troubleshooting |
| Which side is losing the data, over MQTT | MQTT Explorer |
| Adding devices of any protocol | IoT Nodes and Network Protocols |
Connectors
Each connector page ends with a troubleshooting section covering the faults specific to that integration.
| Connector | Where |
|---|---|
| Actility / Netmore ThingPark | Troubleshooting |
| ChirpStack V3 | Troubleshooting |
| ChirpStack V4 | Troubleshooting |
| Hubitat, and Z-Wave, ZigBee and Matter through it | Troubleshooting |
| Netmore | Troubleshooting |
| Road Maintenance | Troubleshooting |
| RSMP traffic light controllers | Troubleshooting |
Start with the connector's own Verifying section where it has one. Confirming a connector works end to end is usually faster than reasoning about why it might not.
Sensors
| Product | Where |
|---|---|
| Strips, LoRaWAN | Troubleshooting guide and FAQ |
| Square and Puck, LoRaWAN | FAQ |
| Z-Wave sensors | Troubleshooting guide and FAQ |
| Battery life and link quality | LoRaWAN sensor battery |
Integrations and development
| Topic | Where |
|---|---|
| Grafana installation | Troubleshooting |
| Node-RED | Debugging |
| Translators, and why the data model matters | Translator development |
| Building an integration | Building an integration |
When it is not us
Some faults are genuinely outside Yggio, and knowing that early saves days. In these cases the people who can resolve it fastest are:
- The SIM provider, for activation, APN and roaming entitlements on cellular devices. Their portal also shows whether a SIM has attached and how much data it has sent.
- The mobile operator, for local coverage and which bands are in use.
- The device manufacturer, for the command set, firmware behaviour and payload format.
- The network server operator, for a LoRaWAN network you do not run yourself.
We would still rather hear from you than have you stuck. If you are not sure which side a problem sits on, ask and we will help you work it out.