Device Status Change Trigger
The Device Status Change trigger fires an automation rule when a device transitions between the online and offline states. Use it to alert on unexpected equipment outages, trigger recovery actions, or log connectivity events to an external system.
How It Works
VWire tracks each device's connectivity state in real time via the MQTT broker heartbeat and the device's last-seen timestamp. When a device connects or disconnects, the platform emits a status change event — and any rule watching that device with this trigger type is evaluated.
Device disconnects from MQTT (or heartbeat times out)
│
▼
Status: online → offline (transition detected)
│
▼
Rules watching this device for "Offline" or "Any change" fire
│
▼
Conditions checked → Actions run
The trigger fires on the state change — not on the state itself. If a device stays offline for 6 hours, the trigger fires once (when it goes offline), not continuously. This prevents action spam during prolonged outages.
When to Use This Trigger
| Use Case | Example |
|---|---|
| Outage alert | Gateway goes offline → push alarm to on-call engineer |
| Recovery notification | Device comes back online → send "✅ Device restored" notification |
| External logging | Device status changes → POST to incident management webhook |
| Watchdog relay | Critical sensor goes offline → trigger a hardware reset relay |
| SLA tracking | Log every offline event to an external system via email/webhook |
Step-by-Step Setup
Step 1 — Basics
Name the rule clearly (e.g. "Gateway Offline Alert"). Select the Project the device belongs to.
Step 2 — Trigger
Select Device Status Change from the trigger type list.
| Field | Description |
|---|---|
| Device | The device to watch. Only devices in the selected project are shown. |
| When device goes | Offline, Online, or Any change |
Fire when options explained:
| Option | Fires when |
|---|---|
| Offline | Device disconnects or heartbeat times out |
| Online | Device connects and is recognised as active |
| Any change | Either direction (online → offline or offline → online) |
Step 3 — Conditions (optional)
Conditions for status-change rules typically check other pin values rather than the status itself, since the status is already encoded in the trigger. Examples:
- Fire the "offline" alert only if pin V5 (a "critical system" flag) =
1 - Skip alerts during maintenance windows by using the Active Time Window option instead
If you add no conditions, the rule fires on every matching status transition.
Step 4 — Actions
| Action | Typical use for status rules |
|---|---|
| Send Notification | Push notification to mobile app (e.g. "DeviceX is offline") |
| Send Alarm | Looping alarm push — ideal for critical infrastructure outages |
| Call Webhook | POST to PagerDuty, Slack, or any REST endpoint |
| Send Email | Email the team (Pro+ plan required) |
| Set Pin Value | Write to another device — e.g. trigger a watchdog or indicator LED |
Use the {{VW-XXXXX:status}} template variable to embed the new status in a message:
Alert: {{VW-KNZWRK:status}} — check your device immediately.
Renders as:
Alert: offline — check your device immediately.
Step 5 — Options
| Option | Recommendation |
|---|---|
| Cooldown | Usually set to 60–300 s. Prevents repeated alerts if a device bounces (rapidly connecting/disconnecting). |
| Active Time Window | Set to business hours if you only want alerts during working hours. Off-hours outages are silently skipped but the device remains flagged offline. |
| Active Days | Uncheck non-operational days (e.g. weekends for office equipment). |
| Timezone | Set to your local zone when using time windows. |
Template Variables
In notification, alarm, and email message bodies:
| Variable | Value |
|---|---|
{{VW-XXXXX:status}} | online or offline — the new state after the transition |
The Device ID is the VW-XXXXXX identifier shown on the device detail page under Device Credentials.
Example notification message:
⚠️ Device {{VW-KNZWRK:status}}: your server room gateway has lost connectivity.
Please investigate immediately.
Worked Examples
Example 1 — Industrial Gateway Offline Alarm
Scenario: A factory gateway goes offline outside business hours and an on-call alarm must be triggered.
| Field | Value |
|---|---|
| Name | Factory Gateway Offline |
| Project | Factory Floor |
| Trigger type | Device Status Change |
| Device | FactoryGateway01 |
| When device goes | Offline |
| Action 1 | Send Alarm — "Factory gateway is offline — investigate immediately" / Priority: Critical |
| Cooldown | 600 s (10 min — prevents alarm spam during unstable connection) |
| Active Time Window | None (alert 24/7) |
Example 2 — Device Recovery Notification
Scenario: Notify the team via webhook (Slack) when any monitored device comes back online after an outage.
| Field | Value |
|---|---|
| Name | Device Reconnected — Slack |
| Project | Production |
| Trigger type | Device Status Change |
| Device | (each critical device gets its own rule) |
| When device goes | Online |
| Action | Call Webhook — POST to Slack incoming webhook URL |
| Cooldown | 60 s |
Webhook body (customised via the rule's webhook payload) can include the device name and new status.
Troubleshooting
Rule fires immediately with "online" on server restart
This is expected if the device reconnects after a server reboot — the reconnection is a genuine online transition. Use a Cooldown and the Active Time Window to reduce noise during maintenance windows.
Rule doesn't fire when device disconnects
- Check the device's heartbeat / connection status on the device card. If it still shows as online, the broker may not have detected the drop yet. The heartbeat timeout defaults to ~60 seconds after the last MQTT PINGREQ.
- Confirm the rule is enabled (green toggle) and watches the correct device.
- Check Logs on the rule card for suppressed executions or errors.
Getting duplicate offline alerts
- A cooldown prevents rapid re-firing. Set Cooldown (Step 5) to at least
300seconds. - If the device is actively bouncing (unstable power/network), address the hardware issue — frequent disconnects will eventually exhaust the cooldown and re-fire.
Template variable {{VW-XXXXX:status}} shows raw placeholder
- Verify the Device ID matches the Device Credentials on the device detail page.
- Ensure you're using
:status(lowercase) as the pin key — it is a reserved key for status rules only.
Summary
| Property | Value |
|---|---|
| Fires when | Device transitions between online ↔ offline |
| Fires repeatedly | No — transition-based only (one fire per direction change) |
| Template variable | {{VW-XXXXX:status}} → online or offline |
| Spam prevention | Cooldown (Step 5) + Active Time Window |
| Available plans | Free, Pro, Pro Plus, Enterprise |