Device offline

The dashboard shows a grey dot next to your device, no new readings have landed in the last 2 × cadence minutes, and you got a Telegram alert that says device_offline. This page walks the diagnostic in the order that resolves it fastest.

1 · Has the device ever been online?

If the device is new, the symptom is "first reading never landed", not "device went offline". The two are different problems. Go directly to step 3 (token + URL).

If the device was online and went grey, continue.

2 · Is it the WiFi or the device?

If every device on a site is grey, the WiFi or the upstream link is down — not the sensor. Standard checks:

• Reboot the WiFi access point.
• Check the modem's WAN light.
• If you have a backup 4G modem in the closet, fail over.

In this case, OpenSense did not lose anything: the devices buffer locally on most platforms (Shelly Plus / Gen3: ~60 readings; ESP32 with our recommended firmware: up to 24 h; Efento LoRaWAN: ~7 d). When the link comes back, the devices replay the buffer and OpenSense ingests with the original timestamps. The gap in the chart fills in.

3 · Is the ingest URL still valid?

If only one device is grey, check:

• Was the device's ingest token rotated? Tokens older than 365 days are auto-flagged for rotation in the dashboard; if the operator rotated but did not update the device, the device is now POSTing with a dead token. The ingest endpoint responds 401 and the device usually does not retry beyond one cycle.
• Did the device's URL get edited in the device UI? On a Shelly, someone may have wiped the action by accident when adjusting WiFi.

Reissue the token: dashboard Device → Settings → Rotate token. Copy the new URL. Re-paste into the device's web UI.

4 · Is the battery dead?

On Shelly H&T, the last reading before the device went grey usually includes a battery value. If it dropped below 3.4 V (Gen3) or 25 % (Gen1), the device is about to die. If the last reading was at 3.1 V or < 10 %, it is dead. Replace the 18650, recalibrate (Shelly's battery gauge is approximate).

LoRaWAN devices report battery in their uplink payload; same rule.

ESP32 DIY devices may or may not — depending on your firmware. If you do not have a battery channel, add one. Battery is the first thing that fails; you want to know.

5 · Is the captive portal the problem?

Some WiFi APs in cafés and hotels run a captive portal that asks the device to accept a click-through every 24 h. Battery sensors that sleep cannot click. Symptom: device works for the first day after pairing and then dies daily at the same hour.

Two fixes:

• Best: use a dedicated WiFi VLAN for sensors, no captive portal.
• Workaround: configure the AP to whitelist the sensor's MAC.

6 · Is it the cellular path?

For LoRaWAN deployments, "device offline" can mean:

• The sensor itself is fine but the gateway is offline. Check the TTN gateway status page.
• The TTN webhook is failing. TTN retries but with cap; if the OpenSense webhook returned 5xx for too long, TTN unscheduled the delivery. Re-enable in the TTN console.
• The frequency plan is wrong — only if you just changed something.

7 · Is it our problem?

Check the status page (https://opensense.murzin.digital/status). The ingest service publishes a one-second-resolution health check. If ingest=down is showing, the diagnostic above is moot; we are working on it.

We will email you within 5 minutes of detection if there is a sustained ingest outage. The email is sent from a different infrastructure than the ingest, so it survives our own outages.

If none of the above

Open a support ticket with:

• The device id (dev_…).
• The last known good timestamp.
• The Shelly / Efento / ESP32 model.
• The most recent screenshot of the device's own web UI.

We have full request logs for the last 30 days; with the device id we can usually point at the root cause within an hour.