Device Process Explanation

This document explains how the device process works based on the implementation in devicesOperations.js.

Overview

The device process is responsible for managing devices, monitoring changes, and interacting with watchers and alarms. It ensures real-time updates and synchronization between devices and watchers, enabling efficient monitoring and alerting.

Why It Works This Way

The device process is designed to:

1. Ensure Real-Time Updates: By periodically checking for changes in devices and triggering watchers, the system maintains up-to-date monitoring.
2. Enable Scalability: The use of in-memory storage and database queries allows the system to handle a large number of devices efficiently.
3. Provide Flexibility: Modular functions for device management and watcher interaction make the process adaptable to various use cases.
4. Enhance Reliability: Robust error handling ensures stability even under unexpected conditions.

Key Functions

1. Retrieving Devices

• Function: getAllDevicesDB()
• Description: Retrieves all devices from the database.
• Variants:
• getDeviceById(id): Retrieves a specific device by its ID.
• countAllDevicesDB(): Counts the total number of devices in the database.

2. In-Memory Device Management

• Function: getDevices()
• Description: Retrieves the list of devices stored in memory.
• Function: getRandomDevice()
• Description: Returns a random device from the in-memory list.

3. Watcher Process Integration

• Function: startWatcherProcess()
• Description: Starts the watcher process to monitor changes in devices and trigger watchers.
• Function: stopWatcherProcess()
• Description: Stops the watcher process by clearing the timeout.

4. Change Detection and Watcher Triggering

• Function: checkChangesAndTriggerWatcherProcess()
• Description: Detects changes in devices and triggers the watcher process if changes are found.
• Workflow:
• Retrieves all devices from the database and compares them with the in-memory devices.
• Identifies changes using hash comparison.
• Fetches active watchers and alarms.
• Triggers alarms if conditions are met.

5. Alarm Management

• Function: deactivateAlarmsFromInactiveWatchers()
• Description: Deactivates alarms associated with inactive watchers.

6. Device Property Traversal

• Function: getDeviceProperties()
• Description: Traverses the properties of a random device and returns a list of key descriptors.

Database and Schema Requirements

The device process requires that all devices are stored in the same database and schema. The device data must be located in the devicedata column. This ensures that the service can handle any type of device seamlessly, maintaining compatibility and uniformity across the system.

Correlation with Watcher Process

The device process interacts closely with the watcher process, as described in watcher-process.md. Key points of correlation include:

1. Watcher Integration:
   • The startWatcherProcess() and checkChangesAndTriggerWatcherProcess() functions in the device process rely on watcher operations to monitor and trigger alarms.
2. Alarm Management:
   • The deactivateAlarmsFromInactiveWatchers() function deactivates alarms based on inactive watchers, linking device and watcher processes.
3. Shared Data:
   • Devices and watchers share data through functions like createAlarmsIfNeeded() in watchersOperations.js, ensuring synchronized monitoring.

Example of a Device and Its Lifecycle

Example Device

• Device Data:

     {
        "id": "device123",
        "status": {
           "temperature": 72,
           "uptime": 3600
        },
        "lastUpdateTimestamp": "2023-10-01T12:00:00Z"
     }
  

Lifecycle

1. Retrieval:
2. The device is retrieved from the database using getAllDevicesDB().

3. It is stored in memory for quick access.

4. Monitoring:

5. The watcher process monitors the device for changes using checkChangesAndTriggerWatcherProcess().

6. Triggering Alarms:

7. If a condition is met (e.g., temperature exceeds a threshold), an alarm is triggered via watcher operations.

8. Deactivation:

9. When the condition is resolved, alarms are deactivated using deactivateAlarmsFromInactiveWatchers().

10. Update or Deletion:

11. The device can be updated or removed from the database as needed.

Notes

• The device process heavily relies on database operations and in-memory storage for efficient monitoring.
• Proper validation and error handling are implemented to ensure robustness.