Device Online/Offline Detection

There is no single, universal signal for "this device is online" — it depends entirely on how the device talks to Virtuino Cloud. This page explains every layer, for both HTTP and MQTT devices, and what each one actually means when you see it on the Device Monitor page.

Looking for command confirmation instead? Knowing a device is online is different from knowing a specific command was applied. For that, see MQTT Confirmed.

1HTTP devices

HTTP is the simple case. Every request a device sends already names the exact device and field it belongs to — POST /api/data/write with the device in the body. There is no persistent connection and nothing to lose track of: each request is the proof that the device was alive at that moment.

Because of that, "online" for an HTTP device is purely a freshness question: how long ago did we last hear from it? There is no separate "connection state" to track — only a timestamp.

Signal	What it means
`last_seen`	Timestamp of the most recent request from this device, over any transport.
Offline threshold	Configurable per device on a Device Monitor dashboard widget — "how long of silence counts as offline". Below that, the device is shown online; above it, offline.

There is no instant "went offline" signal for HTTP.
Unlike MQTT (see below), HTTP has no persistent connection to lose, so there is nothing the platform can be notified about the moment a device disappears — only silence, detected after the threshold passes. Choose a threshold close to your device's real reporting interval for prompt detection.

2MQTT devices

For MQTT there is nothing to add to your firmware. Virtuino Cloud is told directly by the broker the moment a device connects and the moment it disconnects — including after a power cut, a crash or a network failure. You do not write any code for this.

All you need is a matching client ID. Every MQTT connection carries a client ID. Virtuino Cloud uses it to work out which of your devices just connected, so the only requirement is that the client ID matches the device.

Choosing the client ID

A device is recognised when its client ID is the device id, on its own or followed by a dash and anything you like:

Client ID	Recognised as
`esp32`	device `esp32`
`esp32-a1b2c3`	device `esp32`
`esp32-7f3c91d4`	device `esp32`
`boiler_room-01`	device `boiler_room`

The suffix matters when you flash the same sketch to several boards. Two clients that connect with the same client ID keep kicking each other off the broker, so give each one something unique — the chip ID is the easiest choice:

uint64_t chipId = ESP.getEfuseMac();

String clientId =
  deviceName + "-" +
  String((uint32_t)(chipId >> 32), HEX) +
  String((uint32_t)chipId, HEX);

mqtt.connect(clientId.c_str(), MQTT_USER, MQTT_PASS);

Device with a client ID you cannot change? Off-the-shelf hardware (Tasmota, commercial gateways) often connects with a fixed factory client ID such as tasmota_4C11AE. Open the device in Console → Devices, edit it, and type that client ID into the mqtt client id field. Virtuino Cloud will then map that exact client ID to this device.

How fast is a power cut detected?

When a device is switched off abruptly it has no chance to say goodbye, so the broker notices only when the device misses its keep alive deadline. Detection takes roughly keep alive × 1.5:

Keep alive in your sketch	Power cut detected within
`mqtt.setKeepAlive(20)`	about 30 seconds
`mqtt.setKeepAlive(60)`	about 90 seconds — less network traffic

A clean shutdown — the device disconnecting properly, or losing WiFi in a way it can detect — is reported immediately, with no waiting.

Why ordinary data does not count as "online". Several clients can share one account's MQTT credentials — a phone running the Virtuino IoT app, for example, alongside the device itself. If any traffic counted as proof, a command sent from your phone could make a powered-off device look online. Connection events come from the broker itself, so they are always about the real device.

3The Device Monitor widget

To see a device's status on a dashboard — and to be alerted when it drops off — add a device monitor widget. In the dashboard editor choose Add widget → Special → device monitor, then pick the device it should watch.

The widget shows one of three states:

Shows	Meaning
ONLINE	The device is connected right now. The line underneath is when it connected.
OFFLINE	The device disconnected. The line underneath is when that happened.
NO DATA	This device has never been seen connecting. For MQTT that almost always means the client ID does not match — see section 2.

Settings

Setting	What it does
Device	Which device this widget watches. Required — a widget with no device selected cannot report anything.
Offline after (seconds)	How much silence counts as offline. Applies to HTTP devices only. An MQTT device does not need it: the broker reports the disconnect directly, so the widget switches over without waiting for any threshold.
Custom message	The text sent in the offline alert. Leave it empty for the default, which names the dashboard, the device and when it was last seen.
Icon / Image	What the widget shows next to the status. Pick an icon, or upload your own picture of the actual device.

Where the alerts go. Email and push notifications for this widget follow the dashboard's notification settings, not the widget's — so you turn them on once per dashboard rather than per widget. You are alerted when the device goes offline; there is no repeat until it comes back and drops off again.

4What you see on the Device Monitor page

Open a device from Console → Devices to see everything the platform currently knows about its connectivity.

Field	Meaning
Status badge (Online / Offline / No data yet)	"No data yet" means the platform has never seen this device connect, so its status is simply unknown. For an MQTT device that usually means the client ID does not match the device id — see the MQTT section above. For HTTP-only devices, status comes from data freshness instead.
Last seen	MQTT device: the timestamp of its last connection or disconnection — not the last piece of data. A device that stays connected for two days and then drops shows the disconnect time, not the original connect time. HTTP device: the timestamp of the last request received from it.
Connection tracking	Whether this device has ever reported a connection event. Once yes, connection events become the source of truth for this device's status.
Uptime % (last 30 days)	Reconstructed from every recorded online/offline transition. Shows "No connection data yet" instead of a misleading 0% or 100% if the device has no history at all.
Connection history	The last 100 online/offline events for this device, with a visual timeline bar and a detailed table — including the disconnect reason where the broker reports one (clean disconnect, timeout, connection lost, auth failure, ...).

5Troubleshooting

Symptom	Cause
MQTT device stuck on "No data yet" although it's sending data fine	The client ID does not match the device. It must be the device id, on its own or followed by a dash and anything else — `esp32` or `esp32-a1b2c3` for a device called `esp32`. If you cannot change it, type the exact client ID into the mqtt client id field when editing the device.
Power cut takes too long to show up	An abrupt power loss is detected after roughly keep alive × 1.5. Lower `mqtt.setKeepAlive()` in your sketch to detect it sooner, at the cost of a little more network traffic.
Two devices keep knocking each other offline	They are connecting with the same client ID. Add a unique suffix after a dash — the chip ID is the easiest choice. See the MQTT section above.
Uptime % looks wrong on a newly added device	Uptime is calculated only from recorded transitions. A device that just started reporting has little history yet — the percentage becomes accurate as history accumulates over the 30-day window.
HTTP device shows online, but is actually unplugged	HTTP has no connection to lose, so status only updates when the silence threshold on a Device Monitor widget passes. Lower the threshold to detect it sooner.

For topic structure, broker settings and connection reference, see the MQTT Broker Setup guide. For confirming that a specific command was actually applied by the device (a different problem from connectivity), see MQTT Confirmed.