Overview

When a device goes offline in CHeKT, the first step is determining why it is disconnecting. The Activity Logs can often provide valuable clues by showing events such as Network Change, Stream Disconnect, IP Change, or repeated offline/online transitions.

This guide covers the most common causes of offline devices and the recommended troubleshooting steps.

Network Change Events

If the Activity Logs show a Network Change event, this typically indicates that the Bridge has detected a change in communication with the device. This can be caused by network configuration changes, IP address issues, hardware failures, or connectivity problems.

1. Check for IP Address Conflicts

   • Verify that the device's IP address is unique on the network.

   • Duplicate IP addresses can cause intermittent communication failures and devices appearing offline.

2. Check Network Latency

   • Run a continuous ping test to the device.

   • Look for:

     • High latency

     • Packet loss

     • Intermittent responses

   • Consistent packet loss or fluctuating response times can indicate network instability.

3. Check for Bandwidth Issues

   • Ensure sufficient upload bandwidth is available.

   • Heavy network traffic can impact communication between devices and the Bridge.

4. Check for Internet Service Issues

   • Review ISP outages in the area.

   • Slow internet connections, cellular failover connections, or intermittent service interruptions can affect device status.

5. Inspect Physical Connections

   • Verify Ethernet cables are secure.

   • Check for:

     • Damaged cables

     • Faulty terminations

     • Bad switch ports

     • Defective media converters or "glass heads"

   • Physical layer issues are one of the most common causes of intermittent connectivity.

6. Review Firewall and Network Security Settings

   • Confirm that no firewall, VLAN, ACL, or security policy changes are blocking communication between the Bridge and the device.

   • Verify required local network communication remains allowed.

Additional Camera Checks

When a camera shows a Network Change event, additional troubleshooting may be required.

If the camera is connected through wireless bridges, mesh systems, network extenders, or point-to-point radios:

• Confirm all network nodes are online.

• Verify links are stable.

• Check signal strength and throughput.

In some cases, a network node or intermediary device may respond instead of the camera itself.

Confirm that:

• The Bridge learned the camera's actual IP address.

• The Bridge learned the camera's MAC address.

• The Bridge did not learn the MAC address of a wireless bridge, radio, network extender, or other intermediary network device.

If the incorrect MAC address was learned, communication problems may occur when the network changes.

Verify:

• The camera is receiving proper power.

• PoE switches are functioning correctly.

• Power supplies are stable and not intermittently dropping.

Stream Disconnect Events

If the Activity Logs show Stream Disconnect events, the issue is typically related to video delivery rather than basic network connectivity.

A Stream Disconnect means the Bridge temporarily lost access to the camera's video stream.

Recommended Test: VLC Media Player

One of the most effective troubleshooting methods is performing a VLC test using the camera's RTSP stream.

During the test, monitor for:

• Video freezing

• Pixelation

• Stream drops

• Frame loss

• Delayed video

If VLC experiences the same issues, the problem is likely occurring before the video reaches the Bridge.

This helps isolate whether the issue is:

• Camera related

• Network related

• Infrastructure related

• Bridge related

For Article on VLC Media Player Test Click Here

Check Bandwidth

Insufficient bandwidth is one of the leading causes of Stream Disconnect events.

Verify:

• Available upload bandwidth

• Network utilization

• Other devices consuming bandwidth

Even if internet speed tests appear acceptable, network congestion can still impact camera streams.

Verify Camera Stream Settings

High-resolution streams can place unnecessary load on both the network and the Bridge.

For most CHeKT deployments:

• Resolution: 1280 × 720 (720p)

• Frame Rate: 3-10 FPS

• H.264 Encoding Preferred

Higher resolutions and frame rates increase:

• Bandwidth usage

• Network load

• CPU utilization

• Storage requirements

While many cameras support much higher settings, increasing resolution and FPS beyond what is required for monitoring can contribute to stream instability.

Understanding Frame Loss

A camera may appear online but still experience stream disconnects due to frame loss.

Frame loss occurs when portions of the video stream fail to reach the Bridge.

Common causes include:

• Congested networks

• Poor wireless links

• Faulty cabling

• Failing network hardware

• Camera performance issues

The VLC test is often the fastest way to identify frame loss issues.

Understanding the CHeKT Two-Minute Buffer

The CHeKT Bridge continuously maintains approximately two minutes of video from each connected device.

This rolling buffer allows the Bridge to:

• Capture pre-alarm video

• Generate event clips

• Create snapshots for AI analysis

• Provide complete event context

Because the Bridge is continuously processing and buffering video, stream quality and stability are critical.

If frames are being lost or the stream repeatedly drops, the Bridge may eventually declare the camera offline even though the camera itself remains powered and accessible elsewhere.

Why a Camera Can Show Offline in CHeKT but Online on an NVR

This is one of the most common questions received by Technical Support.

A camera may continue showing online on:

• The camera's web interface

• An NVR

• A VMS platform

• Other viewing software

while simultaneously showing offline in CHeKT.

This occurs because:

1. The NVR is typically on the same local network as the camera and often has a direct, dedicated connection.

2. The NVR may tolerate dropped frames or brief interruptions without reporting the camera offline.

3. The CHeKT Bridge continuously processes video for buffering, event generation, AI filtering, and alarm verification. As a result, stream interruptions that go unnoticed by an NVR may still impact the Bridge.

4. A stream can remain technically available while delivering poor-quality or incomplete video, which may cause the Bridge to lose communication with the stream.

For this reason, a camera being online on an NVR does not necessarily indicate the video stream is healthy enough for CHeKT operations.

Speaker Offline Issues

Certain CHeKT speaker firmware versions released during 2024 are known to occasionally report offline status incorrectly.

Symptoms may include:

• Speaker appears offline in CHeKT

• Speaker remains functional locally

• Speaker can still be accessed directly

• Intermittent online/offline status changes

If a speaker is running a 2024 firmware version, we recommend contacting Technical Support for assistance updating to the latest firmware.

Firmware updates have resolved many reported speaker connectivity issues.

Additional Best Practices

Whenever possible, create DHCP reservations or assign static IP addresses to cameras, speakers, and Bridges to prevent unexpected IP changes.

Failing switches are a common source of intermittent offline events. Check for port errors, excessive retransmissions, and link flapping.

A switch operating near its PoE budget may cause devices to randomly reboot or disconnect.

Manufacturers regularly release updates that address:

• Stream stability

• ONVIF communication

• Network performance

• Security vulnerabilities

Whenever possible, use wired connections for cameras and speakers. Wireless links introduce additional points of failure that can impact reliability.

If devices consistently go offline at the same time each day, investigate:

• Scheduled network maintenance

• ISP disruptions

• Power-saving policies

• Automated reboots

• Backup processes consuming bandwidth

Identifying patterns often leads directly to the root cause.

In some cases, the issue may not be with the device itself, but with the information being displayed in the portal.

Web browsers store cached data to improve performance and reduce page load times. Occasionally, outdated cached information can prevent the portal from displaying the most current device status, causing devices to appear offline, show outdated settings, or fail to update properly.

If device status appears incorrect:

• Refresh the page and log back into the portal.

• Clear the browser cache and cookies.

• Open the portal in a private/incognito browser window.

• Test using an alternate browser if available.

After clearing the cache, allow the portal to fully reload and verify whether the device status updates correctly.

If the issue is resolved after clearing the cache, the device was likely reporting correctly and the browser was displaying outdated information.