Understanding Device Status & Intelligence

Who is this article for?
This article is written for Skykit Support Teams and IT Administrators who need to diagnose connectivity issues and interpret device health signals in Skykit Control. If you are a Facilities or Location Manager looking for a non-technical overview, see Connectivity Quick Start Guide.

Overview

When a Skykit device is struggling to maintain a connection, Skykit Control provides several diagnostic signals that allow you to pinpoint the source of a problem before escalating. The key to accurate diagnosis is understanding that every Skykit device runs two independent applications — each communicating via its own channel — and that each channel can succeed or fail independently. This article explains how those two apps work, what their communication patterns look like, and how to use that knowledge to distinguish between a content issue, a device configuration problem, and a network-level restriction.

[Architecture diagram: Two-App Communication Architecture — see diagram file included with this article]

1. The Two-App Architecture

Every Skykit device runs two core applications simultaneously. They serve different purposes and report different types of information.

Because both apps report their own independent state logs, support teams can triangulate an issue with greater precision than a single-signal system allows.

Example — isolating a content issue from a network issue: If the Control App is reporting healthy check-ins but the Player App is failing to download a specific media file, the problem is isolated to content delivery — not the network or the device hardware. Without the two-app distinction, this would appear as a generic "device problem."

📝 Note: Other Skykit applications run on devices — including the Home and Connect apps — but they do not generate heartbeat or state-type logs and are not relevant to connectivity diagnostics.

2. How Devices Communicate: MQTT vs. HTTPS Fallback

Both apps use two distinct communication paths to maintain visibility even on restrictive networks. Understanding which path is active at any given moment is the single most useful diagnostic signal available to a support team.

Reading the Diagnostic Pattern

The combination of MQTT status and HTTPS Fallback status tells a precise story about what is happening on the network:

⚠️ Warning: If both apps are silent — generating no logs whatsoever — this is a clear indicator that either the device has lost its network connection entirely or the hardware has been powered off. A single silent app points to an app-level issue; both silent apps point to infrastructure.

3. The Visibility Gap & Offline Playback Resilience

One of the most frequent questions received by support teams is: "Is the display turned off, or is the network just down?"

From Skykit's perspective, a device that has been unplugged from power looks identical to a device that has had its network cable removed. Both states appear as "Offline" in Control in real time.

How to Determine What Actually Happened

The full picture becomes available once the device reconnects and the Control App uploads its back-logged heartbeats. Reviewing these logs reveals one of two scenarios:

Scenario A — No logs recorded during the gap
The device was powered down. The apps were not running and therefore could not record any activity. This is the definitive indicator of a power interruption rather than a network outage.

Scenario B — Logs recorded but not transmitted
The apps were running and content was playing throughout the gap. The device simply could not reach the Skykit servers to upload those logs in real time. This confirms a network outage — not a power or hardware failure — and also confirms that your audience continued to see content during the outage.

💡 Pro Tip: The Skykit Player App is designed to continue playing content even when the internet connection is lost. Your audience will not see a blank screen during a network outage or temporary instability — the last successfully synced playlist continues to run.

📝 Note: Content types that require a live connection — such as WebViews and live data Feeds — will serve cached content or a customized fallback playlist when connectivity is lost. If a display is showing fallback content unexpectedly, this is a strong diagnostic signal that the device has lost connectivity and cannot retrieve its expected content. Fallback content can be configured at the device or group level in Skykit Control.

4. Troubleshooting Steps

Use the following sequence to diagnose connectivity issues efficiently before escalating to Skykit Support. Each step is designed to narrow the problem to a specific layer.

Step 1 — Check the Diagnostic Screen (if device is physically accessible)

Bring up the Diagnostic Screen on the device. This provides the most complete real-time snapshot of device state — network connection type, signal strength, IP address, app versions, and last sync timestamps — all in one place. Send a screenshot to Skykit Support when opening a ticket; it eliminates several rounds of back-and-forth.

See: Understanding the Diagnostic Screen

[Screenshot placeholder: Skykit Diagnostic Screen — full view showing network, app, and sync status fields]

Step 2 — Run Endpoint Tests (if device is Online but commands are failing)

If the device reports "Online" in Control but content changes and commands are not going through, the MQTT channel is likely being blocked. In Skykit Control, navigate to the Device Detail page → Network tab → scroll to Endpoint Tests. This tool tests each required domain individually and shows which ones are passing or failing, giving you the exact information your network team needs to update the firewall allow-list.

See: Network & Firewall Requirements

[Screenshot placeholder: Skykit Control — Device Detail → Network tab → Endpoint Tests results panel]

Step 3 — Hardware Check (if device is entirely unresponsive)

If the device is not generating any logs and is not responding to any commands, refer to the Hardware Troubleshooting Guide for physical checks covering power supply, cable connections, and device status lights.

5. Special Considerations for Cellular (LTE) Devices

Skykit devices on metered LTE plans — such as the E400 and SKP Pro Mobile — require additional awareness around data-heavy actions. The following actions trigger significant data transfers and should be managed carefully on cellular deployments.

The Carrier Throttling Diagnostic Pattern

If a mobile device appears "Online" but content is failing to sync, the cellular carrier may have throttled the connection after reaching a data limit. In this state, the Control App (low bandwidth usage) continues to check in successfully while the Player App (high bandwidth usage) times out during media downloads.

The diagnostic signature of carrier throttling: Online status in Control + content sync failures in Player App logs. This pattern is distinct from a firewall issue (which blocks both apps) and from a power issue (which silences both apps).

💡 Pro Tip: For cellular deployments, batch your content updates rather than publishing every small change individually. This minimizes the number of modem handshakes and data bursts required, extending your monthly data allowance significantly and reducing the risk of hitting carrier throttling thresholds.

6. Quick Reference: Diagnostic Signatures

Use this table as a fast-reference guide when a support ticket comes in. Match the symptom pattern to the most likely cause before beginning investigation.

Next Steps

• Understanding the Diagnostic Screen — How to read and interpret the on-device diagnostic display
• Network & Firewall Requirements — Full domain and port allow-list for IT Administrators
• Troubleshooting & Incident Response — Structured escalation path for unresponsive devices
• Connectivity Quick Start Guide — Non-technical overview for Facilities and Location Managers