Gateway management dashboard not displaying remote device status after network topology update

IoT Cumulocity IoT
, , , , , , , ,
1

After updating our network topology to support additional gateway layers, the gateway management dashboard no longer displays status for remote devices connected through field gateways. The gateways themselves appear correctly, but the child devices (sensors, actuators) connected to each gateway are missing from the visualization.

We can verify that remote devices are communicating with their respective gateways through direct gateway logs, but the dashboard hierarchy doesn’t reflect the device structure. This has eliminated our fleet visibility for approximately 800 remote devices across 50 gateways.

The network topology change involved adding a new firewall layer and updating gateway agent configuration for the new routing rules. Has anyone experienced gateway agent discovery or widget hierarchy configuration issues after network infrastructure changes?

2

Check your widget hierarchy configuration as well. The gateway management dashboard widgets need to be configured to display child devices based on the managed object parent-child relationships. If the widget is filtering by device type or using specific hierarchy queries, it might not be picking up the child devices even if they’re properly registered. Try recreating the dashboard with fresh widgets to see if that resolves the visibility issue.

3

I’ve resolved this exact scenario multiple times on c8y-1018 deployments after network infrastructure changes. The loss of remote device visibility in gateway management dashboards typically stems from a combination of gateway agent discovery issues, widget hierarchy configuration problems, and network/firewall rule gaps. Let me address each focus area systematically:

Gateway Agent Discovery:

The gateway agent is responsible for discovering child devices and reporting their relationships to the Cumulocity platform. Your network topology change has disrupted this process. Here’s what’s happening and how to fix it:

  1. Discovery Protocol Disruption: Gateway agents use various discovery protocols (MQTT, CoAP, Modbus, etc.) to identify child devices. Your new firewall layer may be interfering with these discovery protocols even though the main gateway communication works.

  2. Agent Configuration Update Required: After network topology changes, the gateway agent configuration must be updated to reflect the new network structure. Key configuration parameters to check:

    
gateway.discovery.enabled=true
gateway.discovery.interval=300
gateway.device.protocol=MQTT
gateway.network.subnet=192.168.1.0/24

    Ensure the subnet configuration matches your new network topology.

  3. Force Device Re-Discovery: The gateway agent maintains a cache of discovered devices. After network changes, this cache can become stale. Force a re-discovery by:

    • Restarting the gateway agent service on each gateway
    • Clearing the agent’s device cache (location varies by gateway type)
    • Triggering manual discovery via the agent’s management interface

  4. Child Device Registration: Verify that child devices are actively attempting to register with their gateways. Check gateway logs for registration attempts and any errors. Common issues:

    • Child devices using old gateway IP addresses
    • Authentication failures due to certificate/credential changes
    • Protocol mismatches after network infrastructure update

Widget Hierarchy Configuration:

The dashboard widgets must be properly configured to display the gateway-to-device hierarchy:

  1. Managed Object Relationships: Cumulocity uses parent-child relationships in managed objects to represent gateway hierarchies. Verify that:

    • Gateway managed objects have the c8y_IsDevice and c8y_IsGateway fragments
    • Child device managed objects have childDevices references to their parent gateway
    • The childDevices fragment on gateway objects lists all connected devices

  2. Widget Configuration: The gateway management dashboard widgets need specific configuration:

    Access your dashboard in edit mode and verify each widget’s data source:

    • Device list widgets: Should query for devices with parent-child relationships
    • Hierarchy tree widgets: Must be configured to display nested device structures
    • Status widgets: Should aggregate status from both gateways and child devices

  3. Hierarchy Query Fix: If the childDevices fragment is empty (as you observed), the widget queries won’t return child devices. Rebuild the hierarchy relationships:

    For each gateway:

    a. Query the gateway’s managed object ID

    b. Query all child devices that should be associated with this gateway

    c. Update the gateway managed object to include childDevices references

    d. Verify the hierarchy appears correctly in the device registry

  4. Dashboard Refresh: Sometimes widgets cache hierarchy data. After fixing the managed object relationships:

    • Clear browser cache
    • Refresh the dashboard
    • If issues persist, recreate affected widgets from scratch

Network/Firewall Rules:

Your new firewall layer requires specific rules for complete gateway functionality:

  1. Required Ports and Protocols:

    • MQTT: TCP 1883 (unencrypted) or 8883 (TLS)
    • HTTPS: TCP 443 (API communication)
    • CoAP: UDP 5683 (if using CoAP devices)
    • Modbus: TCP 502 (if using Modbus devices)
    • Custom protocols: Verify any proprietary device protocols

  2. Bidirectional Communication: Ensure firewall rules allow BOTH:

    • Gateway → Platform (outbound): Device data, telemetry, status updates
    • Platform → Gateway (inbound): Commands, configuration updates, discovery triggers

  3. Discovery Traffic: Some gateway discovery mechanisms use broadcast or multicast protocols. Verify your firewall allows:

    • mDNS (UDP 5353) for device discovery
    • DHCP (UDP 67/68) if gateways assign IPs to child devices
    • Broadcast traffic within gateway subnets

  4. Network Segmentation: If your topology update introduced new network segments:

    • Ensure routing between gateway subnet and device subnets
    • Verify NAT configuration doesn’t break device-to-gateway communication
    • Check that gateways can reach the Cumulocity platform endpoints

Complete Solution Steps:

  1. Verify Network Connectivity (Immediate):

    • Test connectivity from each gateway to Cumulocity platform
    • Test connectivity from sample child devices to their gateways
    • Verify all required ports are open through the new firewall
    • Check for any NAT or routing issues

  2. Update Gateway Agent Configuration (1-2 hours per gateway type):

    • Update network configuration to reflect new topology
    • Update discovery settings for new subnet ranges
    • Restart gateway agents to load new configuration
    • Monitor logs for successful startup and discovery initiation

  3. Force Device Re-Discovery (2-4 hours for 50 gateways):

    • Clear gateway agent device caches
    • Trigger manual discovery on each gateway
    • Monitor discovery logs for child device registration attempts
    • Verify child devices appear in gateway logs

  4. Rebuild Managed Object Hierarchy (3-5 hours):

    • Query all gateway managed objects
    • For each gateway, identify its child devices from logs
    • Update gateway managed objects with correct childDevices references
    • Verify hierarchy in device registry UI

  5. Fix Dashboard Widgets (1-2 hours):

    • Verify widget data source configurations
    • Update hierarchy queries if needed
    • Recreate widgets that don’t respond to configuration changes
    • Test dashboard with sample gateways to confirm visibility

  6. Validate Complete Solution (1-2 hours):

    • Verify all 800 remote devices appear in dashboard
    • Test status updates propagate correctly
    • Confirm commands can be sent to child devices through gateways
    • Monitor for 24 hours to ensure stability

Prevention for Future Network Changes:

  1. Document gateway agent configuration and network dependencies
  2. Create a checklist for network topology changes that includes gateway reconfiguration
  3. Implement monitoring alerts for missing child device relationships
  4. Maintain a test environment to validate network changes before production rollout
  5. Schedule gateway agent updates during maintenance windows with proper rollback plans

The combination of gateway agent reconfiguration, managed object hierarchy rebuild, and firewall rule verification will restore your fleet visibility. The root cause is that network topology changes broke the device discovery and registration flow, leaving the gateway-to-device relationships undefined in the platform even though the devices are communicating.

4

The empty childDevices fragment is the key symptom. This suggests the gateway agent isn’t properly reporting its child device relationships to the platform. After your network topology change, did you update the gateway agent configuration to reflect the new network structure? The agent needs to know how to discover and report child devices, and network changes sometimes require reconfiguring the discovery mechanism.

5

The gateway agent discovery process relies on specific network protocols and ports. If your new firewall layer is blocking the device registration protocol, the platform won’t see the child devices even though they’re communicating with the gateway. Check that your firewall rules allow the necessary Cumulocity communication ports (typically 1883 for MQTT, 443 for HTTPS).

6

I’ve seen this when the gateway-to-platform relationship gets broken during network changes. The child devices are registered under the gateway’s managed object hierarchy. If the gateway re-registered with a new managed object ID after your network update, the child devices would still be associated with the old gateway ID, making them invisible in the dashboard. Check if your gateways have new IDs in the device registry.