Troubleshooting

Check the device LED now

Use the LED to understand what the device is doing right now:

• LED Off: likely power issue (or device not booted).
• Blinking Green / Blinking Blue: application running or booted, but network/cloud connection is failing.
• Solid Green / Solid Blue: device is connected now; offline state in cloud may be stale or intermittent.
• Flashing Yellow: update in progress; wait until update finishes.

For full LED definitions, see Device Status Indicators.

Check last known signal quality before offline

In Cloud, open Device page → Device Action → See logs. At the top of the logs view, review the latest signal quality around the offline timestamp, then inspect:

• $SYS/device/status and $SYS/device/status_number
• $SYS/device/quality and $SYS/device/quality_number

Interpretation:

• Status = Updating (2) or Updating Firmware (3) right before offline may indicate a disconnect during update activity.
• Status = Running (4) before offline confirms application activity was healthy before connectivity dropped.
• Quality = Poor (1) before offline usually means RF/network coverage instability.
• Quality = Medium (2) suggests intermittent network conditions.
• Quality = Good (3) before offline can still drop to offline during heavy data bursts. Quality reflects end-to-end delivery health (device link + server processing time), not only raw cellular/Wi-Fi signal strength.

For field details, see System Device Fields.

If quality shows Poor, use this quick recovery checklist

1. Check placement and signal path
   • Reposition the device or antenna away from metal enclosures and electrical noise sources.
   • If on cellular, move to a location with better coverage if possible.
2. Reduce data load temporarily
   • Lower publish frequency.
   • Batch or reduce payload size.
   • Avoid sending large bursts until connection stabilizes.
3. Validate network path
   • Confirm router/AP uplink stability and internet reachability.
   • Check firewall/DNS changes that may block cloud traffic.
4. Watch logs for trend
   • Keep the logs open and confirm quality improves from Poor to Medium/Good before returning to normal traffic volume.

Use this quick diagnosis

Information to include before escalating

When opening a support ticket, include:

• Device ID
• Time window when offline happened (with timezone)
• LED state observed during incident
• Last $SYS/device/quality / $SYS/device/quality_number before disconnect
• Whether the device recovered automatically or required intervention

Check device logs for the crash message

Open Device page → Device Action → See logs and filter by ERROR. A crash is typically logged as:

Application crashed at <location> with message: <message>

The <location> indicates where the panic occurred in the Blueprint runtime, and <message> describes the cause. Use this to identify the offending node or input.

Review the Blueprint for panic-prone inputs

If the crash repeats after restart, the Blueprint logic is likely producing values that trigger a runtime panic. Common causes:

• Invalid references — a node referencing data that does not exist (missing field, unbound input).
• Type mismatches — an input arriving with a type the node was not configured to handle.

Open the Blueprint editor and review the inputs and references for nodes that handle dynamic data.

Restart the Blueprint application

In the Cloud Console, open the Device page and click Action → Restart App. This relaunches the Blueprint without rebooting the device. If the crash was caused by a transient runtime condition, the application may recover after a restart.

Reboot the device if the application still won’t run

If Restart App does not recover the device, use Action → Reboot Device to perform a full device restart. This clears any leftover runtime state before the Blueprint runs again.

Roll back to a previous Blueprint version

If the crash started right after a recent deploy and the cause is not yet clear, redeploy the previous working version of the Blueprint. This restores the device to a known-good state while you investigate the new version.

Information to include before escalating

If you have tried all the troubleshooting steps above and the issue still persists, please submit a request through the Feedback form.

When submitting the request, include:

• Device ID
• Time the App Crashed state first appeared (with timezone)
• The Blueprint version currently deployed, and the previous version if it was just changed
• The full error line from device logs (Application crashed at ...)
• Whether Restart App, Reboot Device, or a rollback was attempted, and the result

Click Settings

Navigate to the main menu and click on Settings.

Click Data & Integrations

Select the Data & Integrations tab from the top or side menu.

Copy Company ID

Locate the Company ID field and click to copy the key to your clipboard.

Force a hard refresh

A hard refresh bypasses your browser’s local cache and forces it to download the most recent version of the page.

• Windows / Linux: Press Ctrl + F5 or Ctrl + ⇧ + R.
• Mac: Press ⌘ + ⇧ + R.

Clear your browser cache and cookies

If a hard refresh doesn’t resolve the issue, clear your browsing data according to your browser:

• Google Chrome / Microsoft Edge

  • Press Ctrl + ⇧ + Del (Windows/Linux) or ⌘ + ⇧ + ⌫ (Mac) to directly open the clear data menu.
  • Select Cached images and files and Cookies and other site data.
  • Click Clear data (or Clear now in Edge).

• Mozilla Firefox

  • Press Ctrl + ⇧ + Del (Windows/Linux) or ⌘ + ⇧ + ⌫ (Mac) to open the “Clear recent history” window.
  • Ensure Cookies and Cache are selected.
  • Click Clear Now.

• Apple Safari (Mac)

  • Press ⌘ + , to open Settings, then navigate to the Privacy tab.
  • Click Manage Website Data… and click Remove All.
  • (Alternatively, to clear history and website data together, go to the top menu bar: History > Clear History…)

Once the data is cleared, close your browser entirely, reopen it, and log back into the Cloud Console.

Check for interfering browser extensions

Certain extensions—especially Ad-blockers, aggressive tracking protection, or VPNs—can block the background scripts required by the Cloud Console to maintain a live connection.

• Temporarily disable your extensions one by one, refreshing the page each time to identify the culprit.
• Once identified, whitelist the Cloud Console URL in that extension’s settings.