CONTROL Users Guide Documentation for CONTROL Users Guide Overview Architecture Overview The CONTROL platform is built on Zequenze's core framework architecture, designed for scalability and performance. The system is organized into three main layers that work together to provide comprehensive device and service management capabilities. Architecture Layers Machine Interfaces The interface layer handles all communication protocols and external connections: TR069 MQTT Web Server Additional protocol adapters Application Layer The application layer provides core management functionality: Device Management Service Management Firmware Manager Additional management applications Databases The data layer stores and manages: Device records Metrics and telemetry data Configuration data Additional operational data Architecture Diagram Scalability Each architectural layer can be scaled horizontally independently, allowing you to optimize resources based on specific requirements: Traffic volume – Scale interface layers to handle increased connection loads Activity levels – Scale application layers to process more operations Data size – Scale database layers to accommodate growing data storage needs Related Documentation What is CONTROL? Specifications Specifications Overview CONTROL is a carrier-grade device management platform designed for service providers requiring comprehensive multi-vendor and multi-protocol device management capabilities. Platform Characteristics Carrier-Grade Architecture Multi-protocol and multi-vendor support : Enables management of diverse device ecosystems through multiple southbound protocols including TR-069, MQTT, SNMP, API, and CLI Standards compliance : Full adherence to Broadband Forum Device Management Specifications CPE WAN Management Protocol ( TR-069 Amendment 6 ) Cloud-native design : Horizontally scalable cloud-based architecture for enterprise-grade performance OSS/BSS integration : Seamless integration with Service Provider operational and business support systems through flexible APIs Core Functionalities Device Lifecycle Management Automated device onboarding Comprehensive firmware management Bulk provisioning capabilities Configuration Management Device general information and configuration WAN technologies: LTE, GPON, Cable, DSL LAN and WiFi configuration CWMP protocol configuration Services configuration Configuration scripting and automation Diagnostics and Troubleshooting TR-143 based device diagnostics Advanced CLI for technical troubleshooting Real-time device monitoring Scalable Database Architecture Integrated database for high-scale deployments supporting millions of device records Native database integration with optional support for external database systems Multiple device provisioning methods: Web-based GUI Bulk provisioning Auto-onboarding External API integration Flexible Management Interface Dual Access Methods Intuitive web-based GUI for manual operations Comprehensive API for automation and integration Role-Based Access Control Customizable privileges based on user and organization profiles Support for multiple user types: call center users, NOC operators, engineering staff Reports and Analytics Comprehensive Reporting Device-based reports Location and group-based analytics Interactive heatmaps Data Analysis and Export Historical metrics tracking for any device parameter Multiple export formats: CSV, API, and more Custom reporting capabilities Further Reading What is CONTROL? Architecture What is CONTROL? Overview CONTROL is a multivendor and multiprotocol Device Management Platform, also known as an ACS (Automated Configuration Server). It enables service providers to efficiently manage and support customer premises equipment (CPE) regardless of manufacturer or device model. Key Capabilities CONTROL provides comprehensive device management functionalities designed for service provider operations: Automated Device Onboarding – Streamlined provisioning of new devices Device Configuration Management – Centralized configuration control and version management Services Configuration – Service-level parameter configuration and deployment Configuration Scripting/Automation – Script-based workflows for bulk operations Device Diagnostics – Real-time monitoring and diagnostic tools CLI Access – Command-line interface for advanced troubleshooting Firmware Management – Centralized firmware updates and version control Protocol Support CONTROL communicates with managed devices through standard and secure southbound protocols, including: TR-069 (CWMP) MQTT SNMP CLI Additional vendor-specific protocols This multi-protocol approach ensures unified device management across different brands and models through a single platform. User Interface Web-Based GUI CONTROL features a comprehensive web-based graphical user interface for configuration, settings management, and troubleshooting. The interface supports role-based access control with differentiated privilege levels: Read-only – View configuration and status information Read-write – Modify device settings and configurations Admin – Full platform administration capabilities RESTful API All configuration settings and management actions are accessible through a flexible RESTful API, enabling seamless integration with existing OSS/BSS platforms and custom automation workflows. Additional Resources Architecture Specifications Basic Configuration Knowledge Basic Logging into the Platform The first step to access CONTROL is to receive an invitation email. This email contains a link that allows you to set your password for future access to the platform. After receiving the invitation, click the link to set up your password. You will see a page similar to this example: Once the process is complete, you will be redirected to the CONTROL platform: Understanding the CONTROL Interface Now that you're logged into the CONTROL platform, let's explore the available options: Main Dashboard In the center of the screen, you'll find a series of customizable reports in the Main Dashboard . These reports include: Devices UP - Shows currently active devices Devices Per Status - Displays device status distribution Devices Logs - Provides access to device log information All of these reports are customizable if needed to suit your monitoring requirements. Navigation Menu The left-side menu provides access to key platform sections: Inventory - View devices, create configurations, and add parameters for each profile. In this section you can view the devices, create configurations, and add the parameters you need for each profile. Firmware - Upload different firmware versions for upgrades or downgrades, and customize firmware update workflows. You can upload different versions of firmware for upgrade or downgrade, and customize the workflow for firmware upgrades as needed. Locations - Create and manage physical locations using: Geo-localization with coordinates Custom labels to identify device groups Organization by OLT or DOCSIS CMTS connections This section is very useful when you need to create different physical locations, geo-localization with coordinates, or custom labels to identify groups of devices connected to the same OLT or DOCSIS CMTS. User Log - View all transactions and changes made within the platform. This section allows you to view all transactions or changes that have been made in the platform. Enabling Expert Mode To access advanced features, you need to activate Expert Mode : Check the Expert mode checkbox Refresh the webpage by pressing F5 or using your browser's refresh button This activates additional options and advanced functionality within the CONTROL platform. This completes the basic overview of the CONTROL platform. The next step is to create a Profile. Profile Creating a New Profile Before creating a profile, it's important to understand its purpose. Profiles are where you configure key device settings such as: WAN interface configurations Custom WiFi network names (e.g., "ISP-Provider-2.4GHz" for 2.4GHz networks) 5.0GHz network configurations Other device-specific parameters This is where the magic happens when you want to create new interfaces or set up custom configurations for your devices. Steps to Create a Profile Navigate to Inventory in the CONTROL portal Click on Profile Click the Add button Configuring Profile Settings You will see the profile creation page with the following fields: Required Fields Name Enter a descriptive identifier for this profile. Best practice is to use the format: "Vendor Model [Base]" Example: "Nokia G-1425G-B [Base]" Short-name / code Provide an abbreviated version of the profile name. Example: "Nokia-G-1425G" Device class Select the appropriate device type from the following options: eMTA ONT DSL CPE Fixed Wireless Access CPE LTE CPE LTE MiFI STB WiFi eXtender WiFi Mesh AP WiFi Mesh (master) WiFi Mesh (slave) WiFi AP VoIP phone VoIP ATA LAN Switch Router Network appliance SONDA probe Transport gateway Other Organization If applicable, select which organization this profile belongs to. Automatic Device Onboarding Settings Automatic device onboarding Enable this option to allow the CONTROL platform to automatically assign new credentials to devices. This ensures each device receives unique username and password combinations for enhanced security. User Enter the default username that matches the factory credentials on the device. This username must match what is configured on devices connecting to the CONTROL platform. Password Enter the default password that matches the factory credentials on the device. Both username and password must match for automatic profile assignment to work correctly. Overwrite existing devices Enable this option to allow devices that have been reset to factory credentials to reconnect to the CONTROL platform. This prevents connection rejection when a device already exists in the system and ensures that devices returning to factory settings can still connect without issues. Example Configuration Below is an example of a completed profile configuration: Once all fields are configured, click "Save and close" to create the profile. Profile Created After successfully creating the profile, you can: Filter by Name - Use the search filter to locate your profile by its name View the Profile - The newly created profile will appear in the profile list Next Steps The next step is to configure a device with the credentials and URL settings. Add Device to CONTROL Overview This guide walks you through configuring a device to connect to the CONTROL platform. In this example, we'll configure an ONT from an oriental vendor with TR069 credentials created in a previous step. Prerequisites Before beginning, ensure you have: Valid TR069 credentials created in CONTROL (see the Profile chapter ) Network access from the device to the CONTROL platform URL Administrative access to your device Step 1: Access Device Configuration Log in to your device's web interface. Step 2: Review Existing WAN Interfaces After logging in, verify the existing WAN interfaces. This device has a pre-configured interface, but we'll examine the configuration and create a new one for demonstration purposes. To navigate to the WAN interface configuration: Click "Internet" Click "WAN" Click "WAN" again In the displayed list, you'll see existing WAN interfaces (in this example, an interface named "Management" ) Step 3: Create a New WAN Interface Create a new WAN interface for TR069 connectivity: Change the connection type from "PPP" to "IP" : Step 4: Configure Service List Options Next, configure the "Service List" type. Change it from Internet to one that includes TR069 . Understanding Service List Combinations You may encounter several service list options in this device and possibly others. Here's what each means: TR069 — This option is alone, it is because there would be a separate WAN interface solely to manage the device through the CONTROL platform, which would be ideal but is often not possible due to network design issues that already exist. INTERNET_TR069 — With this option we will be sharing the Internet service for the user or client along with the administration of the device. Not recommended since when the service is suspended, access to the CONTROL platform is sometimes lost and communication would be limited until the service is reactivated. VOIP_TR069 — Sharing the TR069 service with VoIP may possibly be a good option since it would not affect the existing Internet services you already have. INTERNET_VoIP_TR069 — This last option would be to manage all the services in a single VLAN or WAN interface, which is rare for clients with this configuration, but it works. Step 5: Configure WAN Interface Parameters Configure your WAN interface with the following settings: Connection name — Enter a descriptive name to identify this connection Service List — Select TR069 IP Version — Select the appropriate IP version (IPv4 or IPv6) VLAN ID — Enter the VLAN ID for this service Important: Please make the necessary changes in your network configuration to ensure the device can reach the CONTROL platform URL through this WAN interface with the TR069 service enabled. After clicking Apply , verify your configuration: Step 6: Verify Network Connectivity Confirm that the WAN interface has a valid IP address and can reach the CONTROL platform: Optional: Test CONTROL Platform Connectivity This step is optional, but you can confirm with a ping that the CONTROL URL can be reached using the device's built-in ping utility: Navigate to "Management & Diagnosis" Click "Diagnosis" Under "Egress" , select your TR069 interface (e.g., "Management" ) Enter the CONTROL platform domain Start the ping test Confirm that all packets successfully reach CONTROL Step 7: Configure TR069 Settings Navigate to the TR069 Management section: Click "Management & Diagnosis" Click "TR069 Management" Step 8: Connect Device to CONTROL Configure the TR069 parameters to establish connection with CONTROL: Configure the following parameters: WAN Connection — Select the interface created for TR069 (e.g., Management ) ACS URL — Enter: https://control.zequenze.com/cwmp/ Note: Please confirm the correct URL with Zequenze staff before proceeding. Username — Enter the username created in the Profile chapter Password — Enter the password created in the Profile chapter Periodic Inform — Enable this option to allow the device to report periodically to CONTROL Periodic Inform Interval — For initial setup, set this to 180 seconds Step 9: Apply Configuration Review your final configuration: Click the Apply button to save your changes. Next Steps Device configuration is now complete. The device should appear in the CONTROL platform within the configured periodic inform interval. You can now proceed to manage and monitor your device through CONTROL. Discovering the parameters Confirm Device Connection At this point, you should have a device successfully connected to the CONTROL platform, similar to the example shown below: Note: If the device list is empty, perform the following troubleshooting steps locally on the device: Try HTTP instead of HTTPS: Change the CONTROL URL from https://control.zequenze.com/cwmp/ to http://control.zequenze.com/cwmp/ . If this works, the device does not support HTTPS or encrypted communication. Use IP address instead of domain: Replace the domain control.zequenze.com with the CONTROL platform's IP address (e.g., https://35.171.123.57/cwmp/ or http://35.171.123.57/cwmp/ ). If this works, verify the device's DNS configuration. Verify TR069 service: Validate that the WAN interface has the TR069 service enabled to achieve connectivity to the CONTROL platform. Understanding the Interface The screenshot above displays the following elements: Inventory — Located on the left sidebar, this section contains devices, profiles, and other resources. Devices — Displays the list of connected devices, showing their status as online or offline (with reasons for offline status). General — The default section view when accessing a device. Name — Automatically assigned by CONTROL as a unique identifier using the ONT's OUI-FSAN or serial number. Status — Shows whether the device is UP or DOWN. Devices have a configured "Periodic Inform Interval" (e.g., 180 seconds). If the device fails to report within this interval, its status changes to DOWN. Profile — Indicates which profile the device is assigned to. Serial — Displays the serial number or FSAN reported by the device. SW Version — Shows the current software version running on the device. Enable Parameter Discovery To discover all available parameters from a device on the CONTROL platform, follow these steps: Step 1: Navigate to Profiles Click Inventory in the left sidebar. Select Profiles from the menu. (Optional) Use the filter to search for a specific profile name and press Enter. Check the checkbox next to the desired profile to reveal additional options. Once you check the checkbox: The checkbox is marked and selected. A new "Action" button appears. Step 2: Toggle Discovery Click the "Action" button. Select "Toggle Discovery" from the dropdown menu. A green gear icon will appear, confirming that the discovery process has started. The CONTROL platform will now wait for the device to connect and retrieve all available parameters. Step 3: Monitor Discovery Progress The green gear icon indicates that the platform is waiting to obtain all parameters from the device. Refresh the webpage to check when the gear icon disappears, signaling that discovery is complete. View Discovered Parameters Once discovery is complete, you can view all discovered parameters. Access the Profile Click on the profile name to open its details: Locate System Groups Inside the profile, scroll down to the bottom of the page to find the System groups section: This section contains: System groups — Where discovered parameters are stored. Group — The name of the parameter group. For discovered parameters, this is typically the profile name followed by "Discovered". Move — A button that displays the parameters and their count. View Parameter Details Click the "Move" button to open the parameter viewer: This window displays: Variable name — The name of each discovered parameter. Type — The parameter data type (e.g., string, integer, date, etc.). Read-only — Indicates whether the parameter is read-only or writable. Discovered value — The value discovered from the example device. Values — A table containing all parameter information. Pages — Navigation controls for browsing multiple pages of parameters. Quantity — The total number of parameters available for this device with its current firmware or software version. Reference: For detailed information about parameters, consult the standard documentation for TR-098 or TR-181 . Next Steps You can now export all discovered parameters to Excel or other formats for local analysis. This process will be covered in the next section. Export the parameters Overview This guide explains how to locate, filter, and export parameter groups from the CONTROL portal. You'll learn to navigate to the Parameters section, apply filters to find specific groups, and export the data in your preferred format. Navigate to the Parameters Section Begin by accessing the Parameters area within the Inventory module. Click on Inventory Click on Parameters Click on Parameters again Activate the filter by clicking the green funnel icon Filter Parameters by Group Once the filter panel is open, you can search for specific parameter groups. The filter panel displays available filter options Locate the Group field Search for Your Group In the Group field, enter a search term (e.g., type "Disco" to find all groups containing the word "Discovered" ) Select your desired group from the results (e.g., "Vendor Model [Base] - Discovered" ) Click the Proceed button to apply the filter Verify Filtered Results After applying the filter, confirm that the correct parameters are displayed. Review the applied Group filter Verify that the parameter count matches the expected number from your Profile (you can confirm the quantity by comparing it with the number of parameters Discovered in the Profile) Proceed to export the parameters Export the Parameters Initiate the Export Click the Export button to open the export dialog. Select Export Format Choose your preferred file format from the available options. Select your desired format (e.g., CSV ) Click the Export button to start the export process Download the Exported File Monitor Export Progress After initiating the export, a progress indicator appears at the top of your browser showing that the report is being generated. Download Complete When the export is ready, a download notification will appear. Open the File You can now open the exported CSV file to view your parameters. Formatting the Parameters This guide demonstrates how to format and organize parameters exported from CONTROL using a spreadsheet application. This example uses LibreOffice Calc, but you can apply the same process in Microsoft Excel or similar tools. Opening the Exported File When you open the exported parameters file in LibreOffice, a Text Import dialog will appear: For most cases, you can simply click OK to accept the default import settings. If you're using Excel, you may need to use the "Import Data" function to load the file properly. Understanding the Parameter Sheet After importing, you'll see a spreadsheet with many columns and parameters: Don't be intimidated by the number of parameters—once you understand the structure, working with them becomes straightforward. Extracting Key Columns For this workflow, you'll need to create a new sheet and copy only four specific columns from the original data. Step 1: Create a New Sheet Create a second sheet (Sheet2) in your workbook to organize the filtered data: Sheet2 - Your new working sheet Sheet1 - The original sheet with all parameters Step 2: Identify the Required Columns From the original sheet, locate and copy the following four columns: Column C Column H Column R Column AY Step 3: Paste into Sheet2 Copy these four columns and paste them into Sheet2: Understanding the Column Structure Your new sheet now contains four essential columns: variable_name - Lists all parameters available for devices using this software version type - Indicates the data type of each parameter (string, integer, boolean, etc.) and tells us what kind of parameter it is read_only - Shows whether the parameter is read-only or can be modified. Some parameters are only read-only and you can't write to them discovered_value - Displays the current value of each parameter (for example, the name of one SSID for a WiFi 2.4GHz network) Sorting the Parameters To make the parameters easier to work with, sort them alphabetically by the first column (variable_name): Note: Make sure to include the header row when sorting so the column titles remain in place. Result After sorting, your parameters will be organized alphabetically: Next Steps With your parameters now organized and easy to navigate, you can begin creating configuration profiles by selecting the specific parameters that meet your requirements. First Parameters Group Parameters Before adding parameters to CONTROL, we recommend organizing them into logical groups. This section demonstrates how to group device information parameters as an example. Step 1: Identify Parameters in Your Spreadsheet Begin by locating the parameters you want to group. For this example, we'll group four device information parameters: Locate the Manufacturer parameter Locate the ModelName parameter Step 2: Copy Parameters to a New Sheet When you mark or find the parameters you need, copy them to a separate sheet for easier organization: Step 3: Add Friendly Names Add a new "name" column to create user-friendly labels for each parameter: You can assign a short, descriptive name for each "variable_name" to establish a clear relationship between the technical parameter name and its display name. Add Parameters to a Profile Now that you've organized your parameters, it's time to add them to your device profile in CONTROL. Step 1: Navigate to Parameter Groups Section Return to the profile you created previously and scroll down to the bottom of the page: Locate the "Parameter groups" section: Parameter groups - This section allows you to create and organize parameter groups Add - Click this button to create a new parameter group Step 2: Create a New Parameter Group After clicking Add , you'll see the following interface: Click the + icon to open the parameter group configuration window Step 3: Configure the Parameter Group A new window will open where you can configure your parameter group: Name - Enter a descriptive name for this group (e.g., "Model | Device Info" ) + Add - Click this button once for each parameter you want to add (in this example, we need 4 parameters) Step 4: Add Parameter Details After entering the group name and adding 4 parameter slots, you're ready to fill in the parameter details Now transfer the parameter information from your Excel or LibreOffice Calc spreadsheet into CONTROL: As you can see, there's now a clear correspondence between your spreadsheet and the CONTROL interface. When you've finished entering all parameters, click "Save and close" . Step 5: Save the Parameter Group You'll now see your newly created parameter group: Click the Save button to save your changes to the profile After saving, you'll see the organization name displayed in the parameter groups section: You can repeat this process to add additional parameter groups or parameters as needed. View Parameters on a Device Now that you've configured your parameter groups, let's verify that they appear correctly on the device page. Step 1: Navigate to the Device Click on Inventory Select Devices You'll see your previously connected devices. In this screenshot, the device shows as Down because it was powered off for this demonstration Click on the device name to view its details: On the device page, you can now see: The parameter group name you created The first parameter: "Model::Manufacturer" The second parameter: "Model::Name" The third parameter: "Model::SWVersion" The fourth parameter: "Model::UpTime" The Last connection timestamp for this device in CONTROL Step 2: Wait for Parameter Values It's normal for the parameter values to be empty at this stage. CONTROL will request and populate these values once the device connects to the platform. After connecting the device: The parameter values are automatically retrieved and displayed once the device establishes a connection to CONTROL. You can now create additional parameter groups or add more parameters to existing groups as needed for your deployment. User Groups and Permissions Guide Overview The CONTROL platform implements a role-based access control (RBAC) system to manage user permissions and data access. Access control is organized through Groups — collections of permissions that define which modules, actions, and data a user can access within the platform. Users can be assigned to multiple groups simultaneously , and their effective permissions represent the union of all permissions from their assigned groups. This flexible approach allows organizations to create precise permission sets that match their operational roles and security requirements. Key Concepts Concept Description Group A named collection of permissions. Users automatically inherit all permissions from their assigned groups. Permission A specific action allowed on a specific resource (e.g., "Can view device", "Can change parameter"). Organization Users can only access data belonging to their organization and its sub-organizations. This organizational boundary is enforced independently of group permissions. Expert Mode An optional toggle that reveals advanced features and configuration options for experienced users. Requires assignment to the "Users: Expert mode" group. Available Groups The CONTROL platform provides standard groups organized by platform module and access level. These groups cover all core functionality areas: Group Name Module Access Level CONTROL account admins CONTROL Administration CONTROL API Logs read-only CONTROL Read-only CONTROL inventory admins CONTROL Administration CONTROL inventory basic users CONTROL Basic CONTROL inventory read-only basic users CONTROL Read-only (basic) CONTROL inventory read-only users CONTROL Read-only CONTROL inventory scripting CONTROL Specialized CONTROL inventory users CONTROL Standard CONTROL portal admins CONTROL Administration Link admin users Link Administration Link read-only users Link Read-only SecureDNS admins SecureDNS Administration SecureDNS reports SecureDNS Read-only SONDA admins SONDA Administration SONDA reports SONDA Read-only Users General Basic Users: Expert mode General Specialized Detailed Group Descriptions CONTROL Account Administration CONTROL account admins Description: CONTROL account administration access. Purpose: Grants administrative control over account-level configuration of the CONTROL platform, including device profile management, parameter configuration, and service settings. Key Capabilities: Area Permissions Device Profiles (Types) View, edit, and delete device profiles — the templates that define how the platform communicates with specific CPE device models. Parameters & Groups View, edit, and delete parameters and parameter groups — the configuration variables used by services (WiFi Analytics, throughput tests, etc.). Lists & Options View, edit, and delete list groups — dropdown/selection options used in service configuration. WiFi Remediation View remediation policies and manage remediation logs — automatic WiFi optimization actions. Task Scheduler View failed tasks and manage successful tasks in the background task queue. SecureDNS Add and edit DNS categories; view DNS transaction logs. Service Settings View extended service settings. Revision History Edit revision entries (audit log management). Recommended For: Platform administrators responsible for configuring device profiles and service parameters. CONTROL API Access CONTROL API Logs read-only Description: CONTROL read-only API Logs. Purpose: Provides read-only access to API activity logs, enabling monitoring and auditing of all API transactions made to and from the platform. Key Capabilities: Area Permissions API Methods View available API methods and their configurations. API Transaction Logs View API transaction logs — records of all API calls made to/from the platform including request/response details. API Transaction Details View detailed information for individual API transactions. Recommended For: Operations staff, auditors, and support teams who need to monitor API activity for troubleshooting or compliance purposes. CONTROL Inventory Management CONTROL inventory admins Description: CONTROL — inventory administration access. Purpose: Full administrative access to the device inventory system, including device management, service configuration, reporting, and system tools. Key Capabilities: Area Permissions Devices Add, edit, and view devices in the inventory. Manage device settings. Service Configuration Full CRUD on parameters, parameter groups, lists, list groups, and service classes — the building blocks of all services. Schedules & Scripts Create and manage inventory schedules and view script logs. Reports & Dashboards View dashboards. Manage report cache data. Locations Add locations and manage location groups. Portal View and manage portal profiles and templates. Performance Profiler Access the SQL query profiler for performance analysis. User Management Manage content types, permissions, user profiles, and sessions. Data Replication Full control over database replication processes. WiFi Analytics Manage WiFi remediation logs; view remediation policies. SecureDNS Manage categories, view rules and transaction logs. Validators Manage validation rules used by parameters. Recommended For: Senior administrators and engineering staff who need full control over the inventory and service configuration. CONTROL inventory users Description: CONTROL — inventory regular user access. Purpose: Standard operational access to the device inventory, including device management, parameter editing, and report creation. This is the primary group for day-to-day operations. Key Capabilities: Area Permissions Custom Reports Create custom reports for personal use. Dashboards Create new dashboards and manage elements. Service Configuration Full CRUD on parameters, lists, and validators — configure service behavior for devices. Device Settings Delete device settings (data cleanup). Group Variables Add group variables for device group configurations. Combined Logs Access combined device log views. Portal Templates Delete portal templates. Recommended For: NOC operators, field engineers, and support staff who actively manage devices and service configurations. CONTROL inventory basic users Description: CONTROL — inventory basic user access. Purpose: Limited access for users who need to perform basic inventory operations such as creating custom reports and managing specific settings. Key Capabilities: Area Permissions Custom Reports Create and delete custom reports — personal report configurations with saved filters. Dashboard Elements Remove dashboard widgets from personal views. Device Settings Delete device settings (cleanup operations). Parameters Delete parameters; view and change validators. Combined Logs Access to combined device logs view. Recommended For: Support staff who need basic report customization and limited inventory access. CONTROL inventory read-only users Description: CONTROL — inventory read-only access. Purpose: Read-oriented access with the ability to create custom reports and dashboards for data visualization. Key Capabilities: Area Permissions Custom Reports Create and delete custom reports. Dashboards Create dashboards and manage dashboard elements. Combined Logs Access combined device log views. Device Settings Delete device settings (for data cleanup). Validators Edit validator configurations. Recommended For: Monitoring staff and analysts who need to view inventory data and create custom visualizations. CONTROL inventory read-only basic users Description: CONTROL — inventory read-only basic access. Purpose: Minimal access for users who primarily need to view data and create personal reports. Key Capabilities: Area Permissions Custom Reports Create and delete custom reports for personal use. Dashboard Elements Add widgets to personal dashboard views. Validators Edit validator configurations. Recommended For: Users who need read-only access with the ability to create custom report views. CONTROL inventory scripting Description: CONTROL — inventory scripting management and execution. Purpose: Access to script management and execution capabilities for automating device operations. Key Capabilities: Area Permissions Scripts Execute and manage inventory scripts — automated procedures that run against devices (firmware upgrades, bulk configuration, diagnostics). Script Logs View execution logs and results from script runs. Recommended For: Operations engineers who need to run automated scripts against the device inventory. CONTROL Portal Management CONTROL portal admins Description: CONTROL — portal administration access. Purpose: Administration of the CONTROL end-user portal — the customer-facing interface where end users can view their service status and device information. Key Capabilities: Area Permissions Portal Pages Create, edit, and manage portal pages — the content displayed to end users. Portal Templates Design and manage page templates that control the portal's appearance. Portal Profiles Configure portal user profiles and access levels. Portal Services Manage which services are exposed through the portal. Recommended For: Staff responsible for managing and customizing the customer-facing portal. Link Management Link admin users Description: Link management application administration access. Purpose: Full administrative access to the Link Management module — used for managing network link associations and interconnections between devices. Key Capabilities: Area Permissions Links Create, edit, and delete network links and associations. Link Services Manage services associated with links. Recommended For: Network engineers managing device interconnections and link topology. Link read-only users Description: Link management application read-only access. Purpose: View-only access to the Link Management module. Key Capabilities: Area Permissions Links View network links and associations without the ability to modify them. Recommended For: Support staff who need visibility into network link topology without modification rights. SecureDNS SecureDNS admins Description: SecureDNS — administration access. Purpose: Administrative access to the SecureDNS module — the DNS-based security filtering system that protects devices from malicious domains. Key Capabilities: Area Permissions DNS Rules Create, edit, and delete DNS filtering rules — define which domains are blocked, allowed, or redirected. Categories Manage DNS categories (malware, phishing, adult content, etc.). Transaction Logs View DNS query logs and filtering statistics. Service Settings Manage SecureDNS service configuration. Recommended For: Security operations staff managing DNS-based protection policies. SecureDNS reports Description: SecureDNS — reports and transactions access. Purpose: Read-only access to SecureDNS reporting and transaction data. Key Capabilities: Area Permissions Reports View DNS filtering statistics, top blocked domains, category breakdowns, and response time metrics. Transaction Logs View DNS query logs to analyze filtering activity. Recommended For: Analysts and managers who need visibility into DNS security metrics without the ability to modify rules. SONDA (User Experience Monitoring) SONDA admins Description: SONDA / User experience — administration access. Purpose: Administrative access to the SONDA module — the user experience monitoring system that runs automated tests (latency, jitter, throughput, WiFi quality) from probes and CPE devices. Key Capabilities: Area Permissions Events View and delete events — automated alerts triggered by test results exceeding thresholds. Event Patterns Create event patterns — define which conditions trigger automated alerts. Event Origins Manage event origins — configure the sources (probes, devices) that generate events. Event Logs Add detailed event log entries. Test Profiles Configure test profiles that define which tests run on which schedules. Test Services Manage test service definitions (ping, throughput, WiFi analytics, etc.). Recommended For: Engineers configuring automated quality of experience (QoE) monitoring and alert thresholds. SONDA reports Description: SONDA / User experience — reports and transactions access. Purpose: Read-only access to SONDA test results, metrics, and event data. Key Capabilities: Area Permissions Event Logs View and edit event log entries. Event Origins View and edit event origin configurations. Test Results View test results — latency, jitter, throughput, WiFi scores, and other QoE metrics collected from probes and devices. Reports Access SONDA dashboards and metric reports. Recommended For: Operators and analysts monitoring service quality metrics. General User Access Users Description: Regular users — access to user's profile, change password operations, etc. Purpose: Minimal access for basic user self-service operations. Key Capabilities: Area Permissions User Profile View own user profile and personal information. Password Change own password. Site Settings View basic site configuration. Recommended For: Users who only need to manage their own account, such as portal-only users or external collaborators with limited access. Users: Expert mode Description: Expert mode users — users that can activate the "Expert Mode" option in admin interfaces. Purpose: Enables the "Expert Mode" toggle in the admin interface. When activated, Expert Mode reveals advanced fields, options, and actions that are hidden by default to prevent accidental changes. Key Capabilities: Area Permissions Expert Mode Toggle Access to the Expert Mode switch in the admin interface. When activated, shows advanced fields in device profiles, parameters, services, and other admin forms. Configuration Profiles Create new configuration profiles — advanced device provisioning templates. Advanced Actions In Expert Mode, additional actions become available on models that normally restrict certain operations (e.g., audit records, firmware logs). Recommended For: Senior engineers and administrators who need access to advanced configuration options. This group should be assigned selectively to users who understand the implications of advanced configuration changes. Recommended Group Combinations by Role Users are typically assigned combinations of groups that together define their operational role. The following combinations provide templates for common organizational roles: Monitoring and Read-Only Roles Role Recommended Groups Description Basic Monitoring • CONTROL API Logs read-only • CONTROL portal admins View the admin interface and manage the customer portal. Suitable for NOC operators focused on monitoring. Monitoring + Inventory • CONTROL API Logs read-only • CONTROL inventory users • CONTROL portal admins Monitoring with additional inventory management capabilities. Operations Roles Role Recommended Groups Description Standard Operations • CONTROL account admins • CONTROL API Logs read-only • CONTROL inventory users Account and inventory management for daily operational tasks. Operations + Security • CONTROL account admins • CONTROL API Logs read-only • CONTROL inventory users • SecureDNS admins Full operational access including DNS-based security management. Operations + Scripting • CONTROL account admins • CONTROL API Logs read-only • CONTROL inventory scripting • CONTROL inventory users Operational access with script execution capabilities for bulk device operations. Engineering Roles Role Recommended Groups Description Engineering • CONTROL account admins • CONTROL API Logs read-only • CONTROL inventory users • Users: Expert mode Full configuration access with advanced/expert features enabled. Engineering + Links • CONTROL account admins • CONTROL API Logs read-only • CONTROL inventory users • Link read-only users • Users: Expert mode Engineering access with network link visibility. Administrative Roles Role Recommended Groups Description Full Administrator • CONTROL account admins • CONTROL API Logs read-only • CONTROL inventory admins • CONTROL portal admins • Users: Expert mode Full access to all CONTROL modules with expert capabilities. SONDA Administrator • SONDA admins • SONDA reports Full access to user experience monitoring and reporting. SecureDNS Administrator • SecureDNS admins • SecureDNS reports Full access to DNS security management and reporting. Minimal Access Roles Role Recommended Groups Description Portal-only User • Users Basic self-service access only (profile, password). API Auditor • CONTROL API Logs read-only Read-only access to API transaction logs for auditing purposes. Note: These are recommended starting points. Adjust group assignments based on your organization's specific needs and security policies. Organization-Based Access Control In addition to group-based permissions, the CONTROL platform enforces organization-based data isolation : Organization Membership: Each user belongs to a specific Organization . Data Visibility: Users can only see and manage data (devices, services, reports, etc.) that belongs to their own organization and its sub-organizations. Public Groups: Groups marked as "public" are shared across sub-organizations, allowing parent organizations to define standard roles for all child organizations. Isolation Enforcement: This organizational boundary is enforced independently of group permissions. This means two users with identical group assignments but different organizations will see different sets of devices and data, ensuring proper data isolation in multi-tenant environments. Best Practices Security and Access Management Principle of Least Privilege Assign only the groups necessary for each user's role Start with minimum required groups and add more as needed Regularly review and remove unnecessary permissions Expert Mode Caution Only assign "Users: Expert mode" group to users who understand the implications of advanced configuration changes Document which users have Expert Mode access and why Regular Audits Periodically review user-to-group assignments to ensure they match current job responsibilities Audit organization assignments and data access patterns Review and clean up unused or inactive user accounts Role Management Use Standard Combinations Follow the recommended role patterns documented above to maintain consistency across your organization Create standardized role definitions that can be applied consistently Document User Roles Use the user "klass" (class/role) field to document each user's organizational role Maintain documentation of group combinations used for different job functions Keep records of why specific permission combinations were granted Multi-Organization Deployments Leverage Public Groups Use public groups for standard roles shared across sub-organizations Define parent-level role templates that can be inherited by child organizations Maintain consistent role definitions across organizational boundaries Platform Modules Reference Module Description Administrative Groups Reporting Groups CONTROL Inventory Device management, profiles, parameters, settings, and monitoring • CONTROL account admins • CONTROL inventory admins • CONTROL inventory users • CONTROL inventory read-only users • CONTROL inventory read-only basic users CONTROL Portal Customer-facing portal for end-user access • CONTROL portal admins — CONTROL Scripting Automated script execution against devices • CONTROL inventory scripting — CONTROL API API transaction monitoring and auditing — • CONTROL API Logs read-only Link Management Network link and device interconnection management • Link admin users • Link read-only users SecureDNS DNS-based security filtering • SecureDNS admins • SecureDNS reports SONDA User experience monitoring (QoE tests, probes) • SONDA admins • SONDA reports General User profile and expert mode access — • Users • Users: Expert mode Configuration Automatic Onboarding Overview Many agent-based standard protocols used to manage networking devices recommend using unique credentials (username/password, keys, etc.) for each managed device. This recommendation enhances security and enables individual device identification during message exchanges. However, it introduces additional complexity, as each managed device must be pre-provisioned with unique credentials before deployment. The Automatic Onboarding feature in CONTROL simplifies this pre-configuration process. It allows devices to initially connect using a common set of credentials, which are then automatically replaced with individual credentials after the first successful connection. Accessing Automatic Onboarding Settings Automatic Onboarding options are configured per Device Profile / Type and can be accessed through: Inventory > Profile / type For detailed information about accessing Device Profile / Type configuration screens, refer to the Device Profile / Type configuration section. Configuration Enabling Automatic Onboarding To configure and activate Automatic Onboarding for a specific Device Profile / Type : Navigate to the Device Profile / Type configuration screen Locate the Automatic onboarding section Enable the Automatic device onboarding checkbox Populate the following required fields: Username : The pre-defined username that devices will use during initial authentication Password : The pre-defined password that devices will use during initial authentication Once configured, any device connecting to the platform with these credentials will be automatically onboarded and assigned to the corresponding Device Profile / Type . Device Identification Fields The following optional fields provide additional validation and identification criteria for connecting devices: Manufacturer : Filters devices by manufacturer name Unique ID : Specifies a unique identifier for device matching Product class : Filters devices by product class designation Serial number prefix : Matches against the beginning characters of the device serial number Identification Rules Case sensitivity : All identification field matching is case-sensitive Prefix matching : For Serial number prefix , the system matches the specified text against the left-most characters of the received serial number Protocol dependency : Identification fields are management protocol-dependent and must be provided in the first message from the managed device (e.g., the Inform message for devices managed through TR-069 ) Example If the Manufacturer field is set to Zequenze , the Automatic Onboarding process for this Device Profile / Type will only apply to devices that identify themselves with Zequenze in their manufacturer field. Advanced Configuration Additional Automatic Onboarding configurations can be customized through: Connection Profile objects for each Device Profile / Type Connection service objects for each Device Profile / Type TBC CONTROL Configuration basics Overview Enabling devices to be managed by the CONTROL platform can be accomplished through a few simple steps. This guide covers the basic configuration requirements to onboard devices into CONTROL. Configuration Steps Step 1: Create a Device Profile Before adding devices, you must first create a Device Profile (also called Device Type) that defines the characteristics of the devices you want to manage. Required fields: CPE Profile/Type name CPE class Protocol Optional fields: Auto-onboarding Step 2: Create the Device If auto-onboarding is not enabled, you need to manually create each device that will be managed by CONTROL. Required fields: CPE name CPE Profile/Type Username Password Note: This step can be skipped if auto-onboarding is enabled in the Device Profile. Next Steps Once you have completed these configuration tasks, proceed to configure the CPE to become managed by the CONTROL platform . Understanding Device Profiles First-Time Device Onboarding When onboarding a device type for the first time, you must create and customize a Device Profile (Profile/Type) that will serve as a template for all devices of the same type. Profile Reusability Once a Device Profile is created, it can be reused for all new devices of the same type. Devices can be added to CONTROL through: Manual creation in the platform Batch creation Auto-onboarding (if enabled) All devices will automatically use the appropriate Device Profile based on their type. Profile Updates Any changes made to a Device Profile—such as improvements or fixes—will be automatically applied to all devices that use that Profile/Type. This ensures consistent configuration across all devices of the same type without requiring individual device updates. Device Profile configuration Overview In the CONTROL platform, every device defined in the Inventory is assigned to a specific Device Profile/Type . These profiles function as shared templates that define the characteristics and behavior of devices. Device Profiles streamline device management by establishing consistent configurations across multiple devices. Key Components A Device Profile/Type defines the following core features related to device configuration and behavior: Connection Profile Specifies the management protocol and associated settings used to communicate with and manage devices assigned to this profile. Default Firmware Defines the predetermined firmware version that can be used to update managed devices to a specific software version. This ensures consistent firmware deployment across devices sharing the same profile. Automatic Onboarding Configures automatic onboarding rules specific to this Device Profile/Type. These rules streamline the process of adding new devices to the system by applying predefined settings automatically. Parameter Groups Contains the collection of Parameters defined in this profile template, including their individual settings and configurations. Parameter Groups organize device-specific settings into logical categories for easier management. Purpose Device Profiles serve as reusable templates that standardize device configuration, simplify management workflows, and ensure consistency across your device inventory. Firmware Management Overview CONTROL ACS provides comprehensive Firmware Management functionality to automate firmware updates across your device fleet. The system is configured through two main areas: Device Profile / Types ( Inventory > Profile / types ) Firmware Library ( Firmware > Images ) This page explains how to configure and use these features to manage firmware versions automatically. Device Profiles / Types Navigate to Inventory > Profiles / types to configure firmware management settings for each device type. Enabling Automatic Firmware Upgrades Within any Device Profile / Type definition, you can activate automatic firmware upgrades by enabling the Automatic Firmware Upgrades checkbox: How It Works Once the Automatic Firmware Upgrades checkbox is enabled, CONTROL ACS will automatically manage firmware updates based on your configuration: With Default Firmware Image specified: CONTROL ACS checks if a device matches the criteria and selection parameters of the configured Default firmware image If matched, the system initiates a firmware upgrade (or downgrade) automatically Without Default Firmware Image: CONTROL ACS searches the Firmware Library ( Firmware > Images ) for applicable firmware images Advanced rules and policies configured in the library determine which firmware to apply Firmware Library The Firmware Library ( Firmware > Images ) allows you to manage firmware images with granular control over distribution and applicability. Firmware Image Configuration Each firmware image in the library can be configured with the following settings: Image mnemonic — Friendly name and description for the image Image location — Storage location options: ACS platform (suitable for smaller deployments) Local HTTP/FTP server (recommended for large-scale distributions) Firmware applicability rules — Control when firmware applies based on: Device hardware version Current device firmware version Release date Additional criteria Adding a Firmware Image Click the Add Image button at the top right of the interface: Configure the image settings on the Add Image page: Firmware Image Parameters Parameter Description Name Mnemonic identifier for the firmware image Version Version number of the firmware image Device Profile Select the Device Profile this image applies to from the dropdown menu Upgrade Profile To be confirmed File or URL Upload the firmware file through the GUI or specify an HTTP/FTP URL where the image is located Note: Using a local Service Provider HTTP/FTP server is STRONGLY recommended for massive firmware updates Release Date Optional. If specified, automatic updates will only be applied after this date Apply to Selector Comparison method used when matching the device's software version against the 'Apply to' version Default: 'Equal to' Apply to (version) Target device software version for this firmware Leave blank to apply to devices with any version Hardware Version Target device hardware version for this firmware Leave blank to apply to devices with any hardware version Version Comparison Algorithm CONTROL ACS uses a direct character-by-character comparison algorithm to determine version precedence. Comparison Examples The algorithm evaluates versions as follows: v1.0.1 is a lower version than v1.0.10 v1.0.1a is a lower version than v1.0.1b v1.0.1a is a greater version than v1.0.1 Important Consideration The algorithm treats v1.0.1a as a higher version than v1.0.1 , which may not be the desired behavior in all scenarios. Workaround: Add an underscore character to ensure correct version ordering: v1.0.1_ is a lower version than v1.0.1a This allows you to maintain the expected version hierarchy when alphabetic suffixes are used. Firmware Selection Logic To be confirmed Upgrade Profiles Navigate to Firmware > Profiles to manage upgrade profiles. To be confirmed Parameter configuration Overview The Parameter configuration screen allows you to define and manage all parameters associated with a specific Device Profile/Type or template in CONTROL. Accessing the Parameter Configuration Screen There are two ways to access the Parameter configuration screen: Method 1: Via the Inventory Menu Navigate to Inventory > Parameters from the main menu. Note: Click on the parameter name in the first column to access the Parameter configuration screen. Method 2: Via Device Profile/Type Navigate to Inventory > Profile/Type Select the desired Profile/Type object Locate the corresponding Group Click the edit button ( ) for the group you want to configure A popup window will display the Parameter list for the selected group Click the edit link on the left side of the Parameter table to access the configuration screen Configuration Screen Structure The Parameter configuration screen is organized into two main sections: General Settings Contains the basic configuration options required to define the fundamental characteristics of the Parameter that will be managed by the platform. Advanced Settings Provides optional configuration options for advanced Parameter management features. Required and Important Settings To be completed. Connection Retries & Time-Out Descripción General Esta documentación describe cómo configurar los parámetros de tiempo de espera (timeout) y reintentos (retries) para Connection Request en la plataforma ACS CONTROL de Zequenze. Contexto del Cambio En versiones anteriores, estos parámetros estaban definidos de forma implícita en el código con los siguientes valores: Timeout: 3 segundos Reintentos: 2 intentos Con la implementación actual, estos parámetros pueden configurarse por perfil de conexión, permitiendo ajustarlos según las necesidades específicas de cada cliente. Configuración de Parámetros Paso 1: Acceder a Device Profiles En el menú lateral izquierdo, haga clic en "Profiles" Verifique que se encuentra en la pestaña "Device profiles" (parte superior de la pantalla) Localice el perfil que desea modificar en la columna "Configuration profile" Pase el cursor sobre el nombre del perfil Haga clic en el ícono de menú que aparece para abrir las opciones disponibles Paso 2: Abrir el Configuration Profile En el menú contextual, seleccione "Open Configuration profile" Se abrirá la pantalla de configuración del perfil seleccionado. Paso 3: Editar el Connection Service Localice la línea "Connection service" Haga clic en el ícono de lápiz (editar) ubicado al final de la línea Se abrirá una ventana con las opciones de configuración del servicio de conexión Paso 4: Configurar los Parámetros de Connection Request Busque el grupo "Connection parameters > CWMP protocol connection parameters and settings" Expanda este grupo para visualizar las opciones disponibles Configure los parámetros según sus necesidades (ver descripciones a continuación) Haga clic en "Save" para guardar los cambios Continúe haciendo clic en "Save" en cada ventana anterior para asegurar que todos los cambios queden aplicados Descripción de Parámetros Timeout Define el tiempo máximo de espera (en segundos) que el sistema aguardará por una respuesta del dispositivo CPE antes de considerar que la solicitud de conexión ha fallado. Este valor permite ajustar la tolerancia del sistema según las condiciones de red y características de los dispositivos gestionados. Valor recomendado: Entre 5 y 30 segundos, dependiendo de la latencia de la red. Retries Especifica el número de intentos que el sistema realizará para establecer la conexión con el dispositivo CPE cuando el intento inicial falle. Este parámetro mejora la confiabilidad de la comunicación en escenarios con conectividad intermitente o inestable. Valor recomendado: Entre 2 y 5 reintentos. Consideraciones Importantes Configuración de valores: Configure los valores de Timeout y Retries considerando las características específicas de su red y dispositivos Valores muy altos de timeout pueden generar demoras innecesarias en la detección de fallas Valores muy altos de retries pueden sobrecargar el sistema cuando hay dispositivos con problemas persistentes de conectividad Validación: Se recomienda realizar pruebas después de modificar estos parámetros para validar el comportamiento esperado Advanced topics CONTROL High Availability Architecture Overview To achieve a robust high-availability (HA) architecture for CONTROL Device Management, Service Providers must comprehensively address both application implementation and operational requirements within their network infrastructure. This includes identifying critical points of failure and implementing appropriate HA strategies to mitigate them. High-Availability Architecture Overview The primary objective of an HA architecture is to guarantee uninterrupted application service in the event of component failure within the solution. The standard CONTROL Device Management application architecture is illustrated below: Figure 1. Device Management application architecture Architecture Prerequisites The CONTROL HA architecture is designed with the following key requirements: Active-Active Configuration : Ensures predictable HA operation and optimal resource utilization Cluster Capacity : Each individual cluster must be capable of handling 100% of the average load Deployment Flexibility : HA clusters can be deployed either co-located or geographically distributed (typically requires site-to-site latency below 250 ms) Principles of Operation The HA architecture operates based on the following mechanisms: DNS Resolution : Customer Premises Equipment (CPE) points to a Fully Qualified Domain Name (FQDN) that resolves to the load balancer array DNS Health Checks : DNS periodically verifies load balancer array availability using HTTP health checks Load Balancer Health Checks : Load balancers periodically verify Auto Configuration Server (ACS) service availability through HTTP/API methods Failure Scenarios The following failure scenarios describe system behavior in a geographically-distributed HA deployment: Complete Site or Load Balancer Failure When DNS detects a failure, it automatically removes the failing load balancer from the DNS group, redirecting traffic to healthy sites. Application Server Failure When the load balancer detects an application server failure, it automatically removes the failing application server from the load balancer group, distributing traffic among remaining healthy servers. Database Failure In the event of a database failure, both application servers automatically fail over to the surviving database instance, ensuring continuous operation. Conversion and units for parameters Overview Units of measurement and value conversions can be configured for any parameter in CONTROL. This allows you to standardize how data is displayed and automatically convert values between compatible units (e.g., Bytes to Megabytes). Configuring Parameter Units You can assign a unit of measurement to any parameter (such as Bits, Bytes, Megabytes, etc.) through the Parameter configuration screen. How to Set a Unit Navigate to the Parameter configuration screen Select the desired unit from the Unit dropdown field Display Location Once a unit is configured, it will be displayed on the device's main screen at the beginning of the corresponding parameter value. Value Conversions In addition to displaying units, CONTROL can automatically convert values from one unit to another. This is useful when the device reports data in one unit but you need to display it in another. How to Configure Conversions To enable automatic conversion between compatible units: Set the source unit in the Unit field Set the target unit in the Value conversion field Example: Converting Bytes to Megabytes The following configuration will convert values received from the device in Bytes to Megabytes: Important Notes Compatible units required : The Unit and Value conversion fields must contain compatible unit types for automatic conversion to work (e.g., both must be data size units like Bytes, Kilobytes, Megabytes). Custom conversions : For custom conversion logic or conversions between incompatible unit types, use the processing script option instead. Dynamic value substitution Overview Dynamic value substitution allows you to use variables as placeholders in CONTROL configuration settings. Variables are enclosed in double curly braces (e.g., {{ variable_name }} ) and are automatically replaced with their actual values when applied to devices. You can use dynamic value substitution in the following contexts: Default values for Parameters in Device Profile/Type configurations Device Settings values in Device Profile/Type configurations Integration service configurations for event handlers and other integrations How Variables Work Variables and their values are defined under the Groups menu. They can be: Custom variables : Manually defined within Groups System variables : Dynamically generated from Device object information and settings For detailed information about configuring Groups and their variables, see the Inventory Groups section . Using Variables in Configuration When a Device belongs to a Group that includes a defined variable, CONTROL automatically substitutes any matching variable placeholder with its actual value. Example: If a Device belongs to a Group with a variable named network_name set to Zequenze , then: Any setting configured as {{ network_name }} will be replaced with Zequenze If a Parameter's default value in a Device Profile/Type is set to {{ network_name }} , the platform will use Zequenze when generating the device's default configuration Variable Precedence and Weight When multiple Groups define the same variable name, CONTROL uses the Weight value to determine precedence: Variables configured with higher weights take precedence over those with lower weights If a Device belongs to multiple Groups that define the same variable, the value from the variable with the highest weight will be used System-Generated Device Variables The following variables are automatically generated from Device object properties and are available for use in dynamic value substitution: Variable Name Description device.name Name of the device device.description 1st description of the device device.description2 2nd description of the device device.description3 3rd description of the device device.description4 4th description of the device device.serial_number Serial number of the device device.serial_number_alt Alternate serial number of the device device.organization Name of the Device's assigned Organization device.organization_id ID of the Device's assigned Organization device.type_id ID of the Device's Type/Profile device.type.name Name of the Device's Type/Profile device.type.short_name Short name configured on the Type/Profile device.type.klass Class of device configured on the Type/Profile device.manufacturer Manufacturer of the device device.unique_identifier Manufacturer Unique ID device.product_class Product class device.software_version Software version of the device device.hardware_version Hardware version of the device device.location_name Location name configured for the device (not normalized) device.location_id ID of the Location assigned to the device (normalized) device.location.name Name of the Location assigned to the device (normalized) device.location.short_name Short-name of the Location assigned to the device (normalized) device.longitude Longitude of the device device.latitude Latitude of the device device.username Device's management agent username device.password Device's management agent password device.update_frequency Update frequency interval configured on the device device.mac MAC address of the device device.address Management address of the device device.gateway_address Management gateway address or hostname Examples Example 1: Device Settings Substitution If a device is configured with the following settings: The following variable substitutions will be performed: {{ device.username }} → agent-username {{ device.password }} → agent-password {{ device.update_frequency }} → 600 {{ device.address }} → 10.0.0.1 Example 2: Parameter Default Value The following example shows dynamic value substitution configured as the default value of a Parameter: Grouped management Overview Grouped management is a feature that controls how CONTROL retrieves and sets parameter values from managed devices. By default, CONTROL optimizes communication by retrieving and setting parameter values using the smallest number of operations possible. This approach minimizes communication overhead and reduces processing utilization between the platform and managed devices. However, certain management flows and conditions require operations to be grouped into logical blocks rather than executed as a single batch. CONTROL uses Parameter groups as these logical blocks, which are configured in the Device Profile / Type configuration screens. When Grouped management is enabled, the system performs get operations separated into blocks of Parameters as defined by each Parameter group . How Grouped Management Works Behavior for Get Operations When Grouped management is active, CONTROL executes get operations in the following sequence: First phase : The system retrieves Parameter values from managed devices for all Parameter groups that do NOT have the Grouped management setting enabled Second phase : The platform retrieves Parameter values using one separate get operation for each Parameter group that HAS the Grouped management setting enabled This two-phase approach ensures that parameters requiring grouped retrieval are processed separately while maintaining efficiency for standard parameter groups. Configuration Configuration instructions to be completed. Interconnection Gateway architecture Architecture Overview Connectivity between the Service Provider's network and Zequenze's cloud-based platforms is established through a fully redundant VPN connection architecture. Figure 1. Zequenze Application-VPN architecture - interconnection with the Service Provider network Distributed Gateway Architecture Zequenze's cloud architecture implements a distributed application model that integrates both VPN and edge-application functionalities within the same gateway infrastructure. This design eliminates the need to propagate Service Provider IP prefixes throughout Zequenze's cloud infrastructure. Device Configuration Service Providers need to configure their customer premises equipment (CPE) to communicate with the edge-application gateways. Supported device types include: WiFi Access Points DSL modems FTTH ONT (Optical Network Terminals) eMTA (embedded Multimedia Terminal Adapters) LTE/5G routers Once devices are pointed to the edge-application gateways, all internal communications within Zequenze's cloud architecture are handled automatically. Simplified Routing Configuration To maximize simplicity and resiliency, Service Provider devices only need to be configured with a single loopback FQDN/IP address. This loopback address remains active across all edge-application gateways in the array. Example: control-gw-loop01.zequenze.com (as shown in Figure 1) Service Provider Requirements From a routing perspective, the Service Provider must ensure: IP reachability to the loopback FQDN/IP address from their border/IXP peering router Proper route advertisement as detailed in Figure 1 Resiliency and High Availability Active-Active Gateway Operation All edge-application gateways operate in always-active mode (1:1 or 1:N configurations). This allows traffic to be routed to any edge-application gateway in the array at any time without service interruption. Traffic Flow Management All responses from Zequenze to the Service Provider are sent through the same edge-application gateway that received the initial request. This approach ensures: Compatibility with active-standby scenarios within the Service Provider's network Prevention of asymmetric traffic routing issues Failure Handling Service Providers must implement proper failure detection mechanisms to prevent traffic black-holes in their VPN gateways when connectivity issues occur with Zequenze edge-application gateways. Figure 2. Zequenze Application-VPN architecture - High Availability considerations Failure Scenario Example In the failure scenario illustrated in Figure 2: The SP IXP router must be notified that the Zequenze edge-application gateway ( control-gw-loop01.zequenze.com ) is no longer reachable via local-gw-01 Traffic must be automatically redirected to local-gw-02 to maintain service continuity This requires proper routing protocol configuration or health-check mechanisms on the Service Provider's infrastructure to detect and respond to gateway failures. Inventory scripts Overview Inventory scripts are Python-based automation tools that execute operations on managed Devices in CONTROL. These scripts can target devices through user-configured filters or process data from CSV files. Use inventory scripts to gather device information or perform batch operations across multiple devices. Scripts can be executed: Manually by users through the CONTROL interface Automatically via triggers configured in Device Profiles Accessing Inventory Scripts Navigate to the Inventory scripts configuration screen from the main menu: Inventory → Scripts Configuration Methods There are two ways to configure inventory scripts: Method 1: Script with Device Filter This method executes a script across multiple devices based on filter criteria. Step 1: Create a New Script Click Add New in the Inventory scripts configuration screen: Step 2: Configure Required Fields Complete the following required fields: Name : Unique identifier for the script Data model : Select "Device" Organization : Select the organization (devices will be filtered by this organization) Click Save to continue. Step 3: Define Script Logic and Filters The script editor will appear: Script field : Define your Python code. See Special Objects for Scripts for examples and available objects. Filter field : Apply device filters using advanced search syntax. See Advanced Search Syntax Help for filter configuration details. Method 2: Script with CSV File This method processes devices using data from a CSV file. Step 1: Upload or Select CSV File In the script configuration screen, locate the Scripting file field. Click the blue icon to upload a new CSV file or select an existing one: Step 2: Configure CSV Settings Scripting file delimiter : Specify the delimiter used in your CSV file (comma, semicolon, tab, etc.): Ignore first row : Enable this option if your CSV file contains column headers in the first row: Step 3: Write CSV Processing Code For information on coding scripts with CSV files, refer to the csv_row objects section in Special Objects for Scripts . Selecting Devices to Process TBC Script Execution Step 1: Access Execution Screen Open or create a script, then navigate to the Execution screen : Step 2: Execute or Manage Script At the bottom of the execution screen, use the available buttons: Run : Execute the script Stop : Halt script execution Save : Save changes to the script code Back : Return to the previous screen Step 3: Save Output (Optional) Enable the Save output option to download execution results as a .txt file after the script completes: Python Modules Included The script execution environment includes the following Python modules by default: math Mathematical functions for advanced calculations. result = math.log10(value) # Calculate base-10 logarithm of 'value' result = math.sqrt(value) # Calculate the square root of 'value' result = math.acos(value) # Calculate the arc cosine of 'value', in radians result = value * math.pi # Multiply 'value' by the mathematical pi constant More information: https://docs.python.org/3/library/math.html random Pseudo-random number generation. result = value + random.randint(1, 10) # Add a random number between 1 and 10 to 'value' More information: https://docs.python.org/3/library/random.html json JSON encoder and decoder for working with JSON data structures. result = json.loads(value)['bytes'] # Convert a JSON string to a dictionary and extract the 'bytes' element More information: https://docs.python.org/3/library/json.html version_parser Software version comparison and validation utilities. old_version = version_parser('v10.0.0p2') new_version = version_parser('v10.0.1p1') if new_version > old_version: print('Firmware upgrade is necessary') Special Objects and Actions The script execution context includes special objects that allow you to: Modify Device attributes and Settings Perform device-related operations and actions For detailed information about available special objects, usage examples, and script processing capabilities, see Special Objects for Scripts . Visual Workflow Designer In some environments, a visual workflow designer is available to build scripts using a graphical interface. Disabling Visual Workflow Designer Transformation To prevent the visual workflow designer from transforming a script, add the following comment on the first line: # _NO_VWD_ Available Functions and Methods The following table lists special functions and methods available within inventory scripts: Name Parameters Description Example detect_network_entity_info extend (bool) device_headers (dict) current_val (dict) old_val (dict) recreate (bool) assistant_id (int) Retrieves network entity information for a device and extends or returns the current parameter value. In device_headers , specify keys: "mac_address", "dhcp_vendor_class", and "hostname". Defaults to 'MACAddress', 'HostName', and 'VendorClass' if not specified. python
previous_table_value, found = device.get(variable_name='beauty_hosts_table')
headers = {"mac_address": "MACAddress", "hostname": "HostName", "dhcp_vendor_class": "VendorClassID"}
beautify_table = detect_network_entity_info(extend=False, device_headers=headers, current_val=value, old_val=previous_table_value)
device.set(variable_name='beauty_hosts_table', value=beautify_table)
device.activate_logs None Enables logging for the device. device.activate_logs() create_log title (string) message (string) Creates a script log entry with the specified title and message. create_log("Title", "Long description") set_result value (any) Sets the context parameter value. Equivalent to result = value . set_result("testvalue") set_output_message value (string) Sets the output message of the script. set_output_message("testvalue") extend_output_message value (string) Appends the given string to the end of the current output message. extend_output_message("testvalue") Metric collection for Parameters Overview Metric collection allows you to store historical information for Parameter values received from managed devices. When enabled, CONTROL automatically captures and stores data points over time, enabling trend analysis and historical reporting. Enabling Metric Collection To activate metric collection for a Parameter: Navigate to the Parameter configuration screen Enable the metric option Note: Metric collection is primarily designed for Parameters that return numeric values. For non-numeric Parameters, see the Non-numeric Parameter Metrics section below. Metric Types CONTROL supports three types of metrics for Parameters: Absolute (default), Counter , and Delta . Each type determines how received values are processed and stored. Absolute Metrics This metric type stores the exact value received from the device after applying: Unit conversions (when configured) Processing scripts (when configured) Use this type when you need to track the actual reported values over time (e.g., temperature, voltage, signal strength). Counter Metrics This metric type stores the rate of change between consecutive values. The calculation is: stored_value = (current_value - previous_value) / time_elapsed The calculation is performed after applying: Unit conversions (when configured) Processing scripts (when configured) Use this type for continuously incrementing counters where you want to track the rate (e.g., bytes per second, requests per minute). Delta Metrics This metric type stores the difference between consecutive values. The calculation is: stored_value = current_value - previous_value The calculation is performed after applying: Unit conversions (when configured) Processing scripts (when configured) Use this type when you need to track the absolute change between readings (e.g., change in disk usage, change in user count). Visualization of Parameter Metrics TBC Non-numeric Parameter Metrics TBC Processing scripts for Parameters Overview Processing scripts enable advanced logic integration within communication flows between managed devices and the CONTROL platform. These Python-based scripts implement business logic to transform parameter values before they are processed and stored by the platform. Processing scripts execute primarily when the CONTROL platform receives a value from the configured parameter. However, they may also run during other operations and actions as detailed below. Available Variables When a processing script executes, the CONTROL platform automatically populates several variables with contextual information: Variable Description value The value of the parameter being received or processed parameter_name The name of the parameter being received or processed parameter_id The unique ID of the parameter being received or processed variable_name The variable name of the parameter being received or processed operation The name of the current operation: add_object , del_object , or get_value index The instance number or index of the object being added The platform expects the transformed value to be assigned to a variable named result . Basic Example This example applies a mathematical formula to transform the received value: result = (value - 10) / 10000 This script subtracts 10 from the received parameter value, then divides the result by 10,000. The CONTROL platform will use the value stored in result instead of the original received value. Execution Context Processing scripts execute in multiple scenarios: When the CONTROL platform receives a parameter value from a managed device After creating or deleting objects on managed devices During operations that modify other parameters and settings In these contexts, scripts can modify additional parameters, adjust device settings, and trigger management operations as described in the Special Objects for Scripts section. Python Operators Processing scripts support standard Python arithmetic operators: Operator Name Description Example + Addition Adds values on either side of the operator a + b = 30 - Subtraction Subtracts right-hand operand from left-hand operand a - b = -10 * Multiplication Multiplies values on either side of the operator a * b = 200 / Division Divides left-hand operand by right-hand operand b / a = 2 % Modulus Divides left-hand operand by right-hand operand and returns remainder b % a = 0 ** Exponent Performs exponential (power) calculation a**2 = 100 // Floor Division Division where the result is the quotient with digits after the decimal point removed. If one operand is negative, the result is floored (rounded toward negative infinity) 9//2 = 4 , 9.0//2.0 = 4.0 , -11//3 = -4 , -11.0//3 = -4.0 Example variable assignments: a = 10 b = 20 Configuration Processing scripts are configured within the Parameter configuration screen. Access this screen by following these simple steps . Script Configuration Location On the Parameter configuration screen, locate the script configuration section under Advanced settings : Included Python Modules The script processing environment includes the following Python modules by default: math Module Provides mathematical functions for advanced calculations. Examples: result = math.log10(value) # Calculate base-10 logarithm of 'value' result = math.sqrt(value) # Calculate the square root of 'value' result = math.acos(value) # Calculate the arc cosine of 'value' in radians result = value * math.pi # Multiply 'value' by the mathematical pi constant Reference: https://docs.python.org/3/library/math.html random Module Generates pseudo-random numbers. Example: result = value + random.randint(1, 10) # Add a random number between 1 and 10 to 'value' Reference: https://docs.python.org/3/library/random.html json Module Provides JSON encoding and decoding capabilities. Example: result = json.loads(value)['bytes'] # Parse JSON string and extract the 'bytes' element Reference: https://docs.python.org/3/library/json.html Advanced Capabilities Special Objects and Operations The script execution context includes special objects that allow you to: Modify attributes of managed devices Update device settings Perform related management actions and operations For detailed information about special objects and usage examples, see the Special Objects for Scripts section. Special Functions Function Description Parameters detect_network_entity_info Retrieves network entity information for a device and optionally extends the current parameter value context: dict, extend: bool = False, device_headers: dict or None = None, current_val: str = None, old_val: str = None Visual Workflow Designer In certain environments, a visual workflow designer is available to build scripts using a graphical interface. Disabling Visual Designer Transformation To prevent the visual workflow designer from transforming a script, add this comment as the first line: # _NO_VWD_ Special objects for scripts Overview Special objects are available within processing scripts to provide enhanced management capabilities for Devices and their Settings . These objects can be referenced directly in your scripts to perform various operations and modify device attributes. The device Object The script execution context includes a special device object that allows you to modify attributes of the managed Device and perform related actions and operations. Attributes The device object provides the following attributes: Name Type/Access Description obj_id integer (read-only) Numeric unique identifier of the current device name string (read-write) Device name field customer_id string (read-write) Customer ID field of the current device type_id integer (read-only) Numeric identifier of the device's profile organization_id integer (read-only) Numeric identifier of the device's organization serial_number string (read-write) Serial number field of the current device serial_number_alt string (read-write) Alternate serial number field of the current device status boolean (read-only) Operational status of the device status_change datetime (read-only) Date/time of the last status change last_connection datetime (read-only) Date/time of the last connection from the device to the platform update_frequency integer (read-write) Device's update frequency or periodic report interval (in seconds). Changes to this attribute will trigger a connection request software_version string (read-only) Software version information as reported by the device hardware_version string (read-only) Hardware version information as reported by the device address string (read-only) Management address used by the device to connect to the platform description string (read-write) Description field of the current device description2 string (read-write) Second description field of the current device description3 string (read-write) Third description field of the current device description4 string (read-write) Fourth description field of the current device reboot boolean (read-write) Activate the 'Reboot' action on the device or detect if a 'Reboot' action is pending factory boolean (read-write) Activate the 'Factory reset' action on the device or detect if a 'Factory reset' action is pending device_factory boolean (read-write) Activate the 'Remote (device only) factory reset' action or detect if the action is pending factory_remote boolean (read-write) Alias for device_factory . Activate the 'Remote (device only) factory reset' action or detect if the action is pending sync boolean (read-write) Activate the configuration 'Synchronization' action with the device or detect if the action is pending reconf boolean (read-write) Activate the device 'Reconfiguration' action or detect if the action is pending location_id integer (read-write) Normalized location ID assigned to the device location_name string (read-write) Non-normalized location name assigned to the device latitude float (read-write) Latitude geographical coordinate of the device longitude float (read-write) Longitude geographical coordinate of the device firmware_image_id integer (read-write) Numeric identifier of the firmware image that can be applied to the device firmware_image_is_pending boolean (read-write) Indicates whether the configured firmware image will be applied to the managed device Methods The device object provides the following methods: save() Save changes made to the device's read-write attributes. Returns: status (boolean) message (string) Example: status, message = device.save() set() Change the value of a specified Parameter by its parameter_name , variable_name , or parameter_id . Parameters: parameter_name (string) – Parameter name identifier variable_name (string) – Variable name identifier parameter_id (integer) – Numeric parameter identifier value (string) – New value to set Returns: status (boolean) – Operation status message (string) – Operation message created (boolean) – Whether a new parameter was created changed (boolean) – Whether the value was changed old_value (string) – Previous value Examples: status, message, created, changed, old_value = device.set(parameter_id=100, value='test') device.set(parameter_name='Device Name', value='test') device.set(variable_name='Device.SystemID', value='test') get() Retrieve the value of a specified Parameter by its parameter_name , variable_name , or parameter_id . Parameters: parameter_name (string) – Parameter name identifier variable_name (string) – Variable name identifier parameter_id (integer) – Numeric parameter identifier Returns: value (string) – Parameter value found (boolean) – Whether the parameter was found Examples: value, found = device.get(parameter_id=100) value, _ = device.get(parameter_name="Uptime") value, _ = device.get(variable_name='Device.SystemID') delete() Delete a setting from the device database specified by its parameter's parameter_name , variable_name , or parameter_id . Parameters: parameter_name (string) – Parameter name identifier variable_name (string) – Variable name identifier parameter_id (integer) – Numeric parameter identifier Returns: deleted (boolean) – Whether the parameter was deleted message (string) – Operation message Examples: deleted, message = device.delete(parameter_id=100) device.delete(parameter_name='Uptime') device.delete(variable_name='Device.SystemID') cwmp_set() Perform a CWMP SetParameterValues operation on devices managed by CWMP/TR-069. Parameters: variable_name (string, required) – Variable name to set value (string, required) – Value to assign variable_type (string, optional) – Type of parameter (default: 'string' ). Options: 'string' , 'boolean' , 'integer' , 'positive' log (boolean, optional) – Enable operation logging (default: False ) disable_connreq (boolean, optional) – Disable CWMP connection request after the operation (default: False ) Examples: device.cwmp_set(variable_name='Device.SystemID', value='test') device.cwmp_set(variable_name='Device.SystemID', value='test', variable_type='string', log=True, disable_connreq=True) connection_request() Perform a connection request to the managed device. Parameters: wait (boolean, optional) – Wait for connection request response or timeout (default: False ) sleep_time (float, optional) – Wait time between operations in seconds (default: 0.05 ) type (string, optional) – Connection request type: 'regular' or 'light' (default: 'regular' ) Example: device.connection_request(wait=False, type='light') alert_clear() Clear any active alert on the managed device. Example: device.alert_clear() ping() Perform an ICMP ping from the platform to the device's management address. Parameters: count (integer, optional) – Number of packets to send (default: 2 , maximum: 10 ) timeout (integer, optional) – Timeout in seconds (default: 1 , maximum: 10 ) Returns: status (boolean) – Ping operation status message (string) – Operation message packet_loss (integer) – Packet loss percentage Example: status, message, packet_loss = device.ping() get_or_create() Get or create a device with the specified parameters. Commonly used with the csv_row variable. Parameters: name (string, optional) – Device name serial_number (string, optional) – Serial number serial_number_alt (string, optional) – Alternate serial number username (string, optional) – Username location_id (integer, optional) – Location ID Returns: device_obj (device object) – Device object on which you can perform operations Examples: device_obj = device.get_or_create(name=csv_row[0]) device_obj = device.get_or_create(name="device_name", username="username") get_obj() Retrieve a device with the specified parameters. Commonly used with the csv_row variable. Parameters: name (string, optional) – Device name serial_number (string, optional) – Serial number serial_number_alt (string, optional) – Alternate serial number username (string, optional) – Username location_id (integer, optional) – Location ID organization_id (integer, optional) – Organization ID Returns: found (boolean) – Whether the device was found Note: When a device is found, the device variable is converted to the corresponding device object. Examples: found = device.get_obj(name=csv_row[0]) found = device.get_obj(name="device_name", username="username") delete_obj() Delete the current device object. Returns: deleted (boolean) – Whether the device was deleted Example: deleted = device.delete_obj() update_location() Update or clear the device location. Parameters: id (integer, optional) – Location ID name (string, optional) – Location name short_name (string, optional) – Location short name Returns: updated (boolean) – Whether the location was updated message (string) – Operation message Examples: updated, message = device.update_location(name="Location name") updated, message = device.update_location(short_name="loc-short-name") # Clear the current location updated, message = device.update_location() group_list() List the groups the device belongs to. Parameters: short_name (boolean, optional) – Return short names instead of IDs (default: False ) Returns: group_list (list) – List of group IDs or short names Examples: group_list = device.group_list() group_list = device.group_list(short_name=True) group_add() Add the device to a specified group. Parameters: id (integer, optional) – Group ID short_name (string, optional) – Group short name Returns: updated (boolean) – Whether the device was added to the group message (string) – Operation message Examples: updated, message = device.group_add(id=45) updated, message = device.group_add(short_name="group-short-name") group_remove() Remove the device from a specified group. Parameters: id (integer, optional) – Group ID short_name (string, optional) – Group short name Returns: updated (boolean) – Whether the device was removed from the group message (string) – Operation message Examples: updated, message = device.group_remove(id=45) updated, message = device.group_remove(short_name="group-short-name") Script Examples Example 1: Update device description and set parameter result = value device.description = value device.save() status, message, created, changed, old_value = device.set(variable_name='Device.SystemID', value=value) if changed: device.connection_request() Example 2: Update alternate serial number based on variable name result = value if variable_name == 'Device.X_LTE_INFO.imei': device.serial_alt = value device.save() Example 3: Build description from multiple parameters result = value if variable_name == 'Device.SystemInfo.Manufacturer': imsi = device.get(variable_name='Device.X_LTE_INFO.imsi') if imsi: device.description2 = '%s - imsi: %s' % (value, imsi) else: device.description2 = value device.save() Example 4: Conditional connection request based on ping results if device.status is False: ping_status, ping_message, ping_packet_loss = device.ping() if ping_status is True and ping_packet_loss < 50: # Send connection request if the device is reachable and packet loss is less than 50% device.connection_request() The csv_row Object When a script is executed over a CSV file, the code defined in the script field is applied to every row of the CSV file. The csv_row object (array) is available within the script context, containing the values from the current row. CSV Processing Example The following example demonstrates updating device coordinates from a CSV file with the format: [device_name, latitude, longitude] # Updating device coordinates with info from CSV file # CSV format: [device_name, latitude, longitude] # Look up the device using the serial number (or "name") found = device.get_obj(serial_number=csv_row[0]) latitude = csv_row[1] longitude = csv_row[2] if found: # Set latitude and longitude device.latitude = latitude device.longitude = longitude # Save changes device.save() # Show success message out = "Updated the coordinates on Device: %s" % csv_row[0] else: # Device not found out = "Not found serial_number: %s" % csv_row[0] Alfred Assitants Introduction An Assistant is an advanced AI-based entity capable of performing specific tasks autonomously based on the rules and instructions provided during its configuration. Assistants in CONTROL allow you to define and customize behavior, capabilities, and data interpretation logic, including unique identity, functionalities, and structured response formats. OpenAI Integration: Alfred assistants that use an OpenAI model are synchronized with OpenAI Assistants, automatically creating and updating each instance when required. Assistant Configuration Fields 1. Name The display name of the assistant, representing its purpose or functionality. Example: Device Detection 2. Short Name / Code A concise identifier or code for the assistant, used for easy reference in systems and API calls. Example: device-detection 3. Model Configuration Service Defines the AI model or engine the assistant utilizes for processing tasks. These are configured as Alfred services. Example: OpenAI GPT-4 4. Organization Specifies the organization or team responsible for the assistant. Example: Root 5. External Identification A unique identifier assigned to the assistant for external integration or tracking purposes. Example: asst_altBr2RoWO77jxT5h0kihDB1 (OpenAI Assistant ID) 6. Prompt Instructions provided to the assistant that define its core behavior and task scope. This ensures the assistant interprets and processes data accurately according to your requirements. Example: You are an intelligent assistant that provides answers about Sports in JSON format 7. Response Schema Defines the structure and format of the assistant's output to ensure responses conform to valid JSON or other required formats. Example: { "type": "object", "title": "DeviceInformationList", "properties": { "hostname": { "type": "string" }, "mac_address": { "type": "string" }, "dhcp_vendor_class": { "type": "string" }, "is_random_macaddr": { "type": "boolean" } } } Integration Guide: ask_to_assistant Function The ask_to_assistant function enables communication with AI-powered assistants, allowing developers to query assistants and receive intelligent responses programmatically. Function Signature def ask_to_assistant( question: str, id: int = None, short_name: str = None, organization_id: int = None, related_object = None, related_object_name = None, related_object_id = None, check_answers = False ) Parameters Required Parameter question ( str ) The query or prompt to send to the assistant. Optional Parameters id ( int ) The unique ID of the assistant to query. short_name ( str ) The short name/code of the assistant to query. organization_id ( int ) The ID of the organization to which the assistant belongs. related_object ( Any ) An optional object associated with the query (e.g., related to a specific feature or module). related_object_name ( str ) The name of the related object. related_object_id ( int ) The ID of the related object. check_answers ( bool ) If True , checks for previously stored answers to avoid duplicate queries and improve performance. Return Value str or None Returns the assistant's response based on the given query. Returns None if no assistant is found. How It Works Retrieve the Assistant The function uses Assistant.objects.get_default_assistant to fetch the desired assistant based on the provided id , short_name , or organization_id . Check for Previous Answers (Optional) If check_answers is set to True , the function checks if there is a previously saved answer for the same question. If found, it returns that cached answer. Log the Request A log entry is created using upsert_log to track the request details and status. Call the Appropriate Model Service Based on the assistant's configuration: OpenAI models ( openai-model-config ): Calls ask_to_openai_assistant with the assistant's external_id and API key. Groq models ( groq-model-config ): Calls ask_to_groq_assistant with the assistant's model settings and API key. Update the Log The log is updated with the assistant's response, tokens used, and execution delay. Return the Response The final answer is returned to the caller. Example Usage Querying an Assistant by Short Name response = ask_to_assistant( question="What is the weather forecast today?", short_name="forecast-assistant" ) Querying with Related Object Context response = ask_to_assistant( question="Analyze this device configuration", short_name="device-detection", related_object_name="NetworkDevice", related_object_id=12345, check_answers=True ) Alfred Assistant Logs Each question performed to a specific assistant generates detailed execution logs. These logs allow you to monitor assistant performance, track token usage, and troubleshoot issues. Log Information Assistant logs provide visibility into: Request details : Question asked, assistant used, and timestamp Response data : Answer provided by the assistant Performance metrics : Token usage and execution time Related objects : Associated entities or context for the query Status : Success or error information Service Status Cards Service Status Cards Overview The Service Status Cards feature in CONTROL enables real-time monitoring of device services and WAN interface status through customizable dashboard cards. These cards display operational data retrieved from TR-181 or TR-098 parameters, providing instant visibility into your network infrastructure. Figure: Services in healthy state Figure: Services in disabled state Figure: Services showing disruption or failure Available Service Cards The platform provides four types of service status cards: Device Management — Displays device operational status and WAN interface connectivity. Shows IPv6 addressing for ACS communication and provides direct web access to the device interface. Internet Service — Monitors internet connectivity status with detailed IPv6 addressing (IA_NA and IA_PD) and DS-Lite tunnel configuration for IPv4 connectivity. Voice Service — Tracks VoIP service status including IMS server configuration (primary and secondary), telephony line registration, and SIP parameters. Video Service — Monitors video streaming service status with dedicated DS-Lite tunnel and IPv6 configuration separate from internet service. Configuration Guide Step 1: Navigate to Device Profiles Access the profiles section where you'll configure the monitoring script: From the left navigation menu, click Inventory Select Profiles from the submenu Locate and select your target profile from the list (e.g., "F689V9-Zequenze") Figure 1: Device profile selection interface Step 2: Access Profile Scripts Locate the script configuration area within the profile: Scroll to the bottom of the profile configuration page Find the Profile scripts section Click the +Add button to create a new script entry Figure 2: Profile scripts configuration section Step 3: Create New Script Entry Initialize a new script for service monitoring: In the new script line that appears, click the + icon The script creation dialog will open Figure 3: Creating a new script entry Step 4: Configure Script Properties Define the basic script parameters: Name : Enter a descriptive name (e.g., "Script_Global") Script type : Select Profile from the dropdown Organization : Verify the organization matches your profile Click Save and close Figure 4: Script properties configuration dialog Step 5: Save Profile Configuration Apply the script association to the profile: Return to the main profile configuration page Click Save to apply the changes Figure 5: Saving profile configuration Step 6: Access Script Editor Open the script editor to implement the monitoring logic: Click the Edit button (pencil icon) next to your script The script editor interface will open Figure 6: Accessing the script editor Step 7: Implement Service Monitoring Script Add the monitoring logic to the script editor: In the script editor text area, paste or write your service monitoring code The script should query TR-181/TR-098 parameters for service status Format output as JSON to display service cards with appropriate status indicators Figure 7: Script editor interface Script Implementation Core Helper Functions The script uses utility functions to process device parameters safely and efficiently. Parameter Processing Function import json def process_device_get(value, as_json=False): """ Process device parameter values from TR-181 queries. Args: value: Tuple containing (value, success) from device.get() as_json: Boolean flag to parse value as JSON array Returns: Processed value as string, JSON object, or default value """ if not isinstance(value, tuple) or len(value) != 2: return [] if as_json else "0" val, success = value if not success or val is None or val == "": return [] if as_json else "0" if as_json: try: return json.loads(val) except json.JSONDecodeError: return [] return str(val) TR-181 Parameter Query Methods The platform supports two types of parameter queries with different return formats: Single Value Parameters (ending with parameter name): # Returns direct value as string hsi_enable = process_device_get( device.get(variable_name='Device.IP.Interface.4.Enable') ) dslite1_status = process_device_get( device.get(variable_name='Device.DSLite.InterfaceSetting.1.Status') ) Array Parameters (ending with dot): # Returns JSON array with multiple parameter objects hsi_iana = process_device_get( device.get(variable_name='Device.IP.Interface.4.IPv6Address.'), as_json=True ) voice_ipv4 = process_device_get( device.get(variable_name='Device.IP.Interface.5.IPv4Address.'), as_json=True ) Service-Specific Implementation 1. Device Management Service Monitors the management interface for ACS connectivity and device access. Input Parameters # Management interface IPv6 addressing mgmt_iana = process_device_get( device.get(variable_name='Device.IP.Interface.3.IPv6Address.'), as_json=True ) Analysis Function def analyze_management_interface(): """ Analyze device management service status. Evaluates IPv6 connectivity for ACS communication. """ iana = safe_json_loads(iana) has_iana = False iana_address = None iana_expired = False # Parse IPv6 address information if iana and isinstance(iana, list): for item in iana: if item.get('Origin') == 'DHCPv6' and item.get('IPAddress'): has_iana = True iana_address = item.get('IPAddress') valid_lifetime = item.get('ValidLifetime') if valid_lifetime: iana_expired = is_lifetime_expired(valid_lifetime) break # Determine service status if not has_iana: service_status = "disabled" wan_status = "disabled" elif iana_expired: service_status = "warning" wan_status = "warning" else: service_status = "healthy" wan_status = "healthy" # Build metrics array metrics = [{ "id": "wan_status", "label": "Interface WAN", "type": "status", "value": wan_status, "tooltip": "Interface WAN: Connected (you have device access)" if has_iana else "Interface WAN: Disconnected" }] # Add web access link if IPv6 available if iana_address: metrics.append({ "id": "ipv6_link", "label": "Web Access", "type": "link", "value": { "text": f"http://[{iana_address}]", "href": f"http://[{iana_address}]" }, "linkTarget": "_blank", "tooltip": "Access device web interface" }) return { "id": "management-service", "name": "Device Management", "type": "management", "status": service_status, "category": "management", "metrics": metrics, "iconSize": "tw-w-7 tw-h-7" } Example Output { "id": "management-service", "name": "Device Management", "type": "management", "status": "healthy", "category": "management", "metrics": [ { "id": "wan_status", "label": "Interface WAN", "type": "status", "value": "healthy", "tooltip": "Interface WAN: Connected (you have device access)" }, { "id": "ipv6_link", "label": "Web Access", "type": "link", "value": { "text": "http://[2806:230:fffb::16e2:6357]", "href": "http://[2806:230:fffb::16e2:6357]" }, "linkTarget": "_blank", "tooltip": "Access device web interface" } ], "iconSize": "tw-w-7 tw-h-7" } 2. Internet Service Monitors internet connectivity including IPv6 addressing and DS-Lite tunneling for IPv4 support. Input Parameters # High-Speed Internet (HSI) interface parameters hsi_enable = process_device_get( device.get(variable_name='Device.IP.Interface.4.Enable') ) hsi_iana = process_device_get( device.get(variable_name='Device.IP.Interface.4.IPv6Address.'), as_json=True ) hsi_iapd = process_device_get( device.get(variable_name='Device.IP.Interface.4.IPv6Prefix.'), as_json=True ) # DS-Lite tunnel parameters for IPv4 connectivity dslite1_enable = process_device_get( device.get(variable_name='Device.DSLite.InterfaceSetting.1.Enable') ) dslite1_address = process_device_get( device.get(variable_name='Device.DSLite.InterfaceSetting.1.EndpointAddress') ) dslite1_status = process_device_get( device.get(variable_name='Device.DSLite.InterfaceSetting.1.Status') ) Analysis Function def analyze_data_interface(): """ Analyze internet service status including IPv6 and DS-Lite configuration. Evaluates WAN connectivity, IPv6 addressing, and IPv4 tunneling. """ # Parse IPv6 addressing information iana = safe_json_loads(iana) # IPv6 addresses iapd = safe_json_loads(iapd) # IPv6 prefixes has_iana = False has_iapd = False iana_address = None iapd_prefix = None # Check for valid IPv6 address (IA_NA) if iana and isinstance(iana, list): for item in iana: if item.get('Origin') == 'DHCPv6' and item.get('IPAddress'): has_iana = True iana_address = item.get('IPAddress') break # Check for valid IPv6 prefix delegation (IA_PD) if iapd and isinstance(iapd, list): for item in iapd: if item.get('Origin') == 'PrefixDelegation' and item.get('Prefix'): has_iapd = True iapd_prefix = item.get('Prefix') break # Analyze DS-Lite tunnel configuration default_dslite_addresses = {'INTERNET': 'fc00::1', 'VIDEO': 'fc00::2'} is_default_dslite = dslite_address == default_dslite_addresses.get(service) has_invalid_dslite = dslite_address and ("@" in dslite_address) # Determine service status based on all parameters service_status = "disabled" if not enable: service_status = "disabled" elif not (has_iana and has_iapd): service_status = "error" elif not dslite_enable: service_status = "error" elif is_default_dslite: service_status = "warning" elif has_invalid_dslite: service_status = "error" elif dslite_ Device management through TR-069 Configuring a CPE to become managed through CWMP/TR-069 Overview To configure a Customer Premises Equipment (CPE) device for management through the CWMP/TR-069 protocol, you must enable TR-069 management on your CPE device and configure it to communicate with the CONTROL platform. Required CPE Configuration Fields The following configuration fields are required for initial setup and should be available in your CPE device settings: CWMP/TR-069 Server URL : The URL endpoint of the CWMP/TR-069 Server Platform Periodic Inform Interval : The reporting frequency (in seconds) for status updates between the CPE and CWMP/TR-069 Server Platform Username : The username credential used to authenticate the CPE to the CWMP/TR-069 Server Platform Password : The password credential used to authenticate the CPE to the CWMP/TR-069 Server Platform Optional CPE Configuration Fields Some CPE devices may offer additional TR-069 configuration parameters: Connection Request URL : The CPE's URL endpoint for receiving connection requests Connection Request Username : The username for authenticating connection requests to the CPE Connection Request Password : The password for authenticating connection requests to the CPE Note: These optional parameters are not required for initial CPE setup and can be configured later through the CONTROL platform itself. Example Configuration A typical initial TR-069 CPE configuration would look like: URL : https://control-dev.zequenze.com/cwmp/ Periodic Inform Interval : 120 (seconds) Username : test-device Password : c0mpl3xpazz Important Authentication Requirements The Username and Password fields configured on the CPE must match the credentials defined in the CONTROL platform. These credentials can be configured either: For a specific individual device, or For a device TYPE (when using auto-onboarding functionality) Configuration on CONTROL Platform TBC TR-069 Connection Request Overview TR-069 is a CPE-originated communication protocol, meaning that the CPE (Customer Premises Equipment) initiates connectivity toward the ACS (Auto Configuration Server) using a pre-agreed ACS URL, username, and password. In a standard TR-069 communication flow, the CPE connects to the ACS at regular intervals defined by the Periodic Inform Interval . However, there are scenarios where the ACS needs to update or modify CPE parameters within a shorter timeframe than the configured interval. For example, a customer support agent may need to change a WiFi password immediately rather than waiting for the next periodic connection. To address this requirement, the TR-069 standard defines a Connection Request functionality. What is Connection Request? Connection Request is a mechanism that allows the ACS to proactively request (or "poke") a CPE to initiate a TR-069 session at any time, independent of the Periodic Inform Interval. How It Works The ACS sends an HTTP request to the CPE using the CPE Connection Request URL with pre-agreed Connection-Request Username and Connection-Request Password The CPE responds with either: Success : HTTP 200 OK or HTTP 204 No Content Failure : HTTP 401 Unauthorized Upon successful acknowledgment, the CPE initiates a standard TR-069 session toward the ACS (beginning with the initial Inform message) Benefits of Connection Request By enabling Connection Request between ACS and CPE, service providers can: Reduce network overhead : Use longer Periodic Inform Intervals to minimize network management traffic and CPE load Maintain flexibility : Retain the ability to make configuration changes or perform tests on-demand whenever required Improve operational efficiency : Enable immediate responses to customer support requests without waiting for the next periodic inform Implementation Challenges Implementing Connection Request presents challenges primarily related to enabling inbound HTTP connectivity from the ACS to the CPE. These challenges involve: IP Reachability : CPE devices are often behind NAT or use private IP addressing, making them unreachable from the ACS Security Concerns : Opening inbound connections to CPE devices requires careful security considerations Connection Request Methods Several approaches exist to overcome these implementation challenges. The following are the most widely deployed methods: VPN-Based Connection Request A VPN tunnel can be established to provide direct reachability from the ACS to CPE devices located within the service provider's private IP address space. XMPP-Based Connection Request This method uses an intermediate XMPP Broker that: Can reach CPE devices Is reachable by the ACS Can be located inside or outside the service provider's network (e.g., in a DMZ) Reference : TR-069 Issue 1 Amendment 6 Annex K provides detailed specifications for this architecture. STUN/UDP-Based Connection Request This approach uses an intermediate STUN server to enable inbound UDP-based connection requests: The CPE creates a UDP connection (bind) to the STUN server The ACS can reach the CPE through the STUN server using the UDP Bind address The STUN server can be located inside or outside the service provider's network (e.g., in a DMZ) Reference : TR-069 Issue 1 Amendment 6 Annex G provides detailed specifications for this architecture. Note : CONTROL ACS supports all of the connection request schemes described above. CPE Configuration for XMPP Connection Request Overview The Connection Request feature enables the ACS (Auto Configuration Server) platform to initiate communication with CPE devices to retrieve or modify parameter values and perform OAM (Operations, Administration, and Maintenance) operations. Prerequisites Before configuring XMPP Connection Request, ensure that an XMPP Connection instance has been created on the device at the following data model path: InternetGatewayDevice.XMPP.Connection.1 Configuration Parameters The following sections detail the required TR-069 parameters for XMPP Connection Request configuration in different environments. Development/Testing Environment Use these configuration values when connecting to the CONTROL development environment: TR-069 Parameter Value/Description Type Access InternetGatewayDevice.XMPP.Connection.1.Enable 1 boolean RW InternetGatewayDevice.XMPP.Connection.1.Domain control-xmpp-dev.zequenze.com string RW InternetGatewayDevice.XMPP.Connection.1.Username sample_username string RW InternetGatewayDevice.XMPP.Connection.1.Password sample_password string RW InternetGatewayDevice.XMPP.Connection.1.Resource ConnReq string RW InternetGatewayDevice.XMPP.Connection.1.UseTLS 1 boolean RW InternetGatewayDevice.XMPP.Connection.1.TLSEstablished 1 boolean RO Device.ManagementServer.ConnReqJabberID sample_username@control-xmpp-dev.zequenze.com/ConnReq string RO Device.XMPP.Connection.1.ServerConnectAlgorithm DNS-SRV string RW Device.XMPP.Connection.1.KeepAliveInterval 300 integer RW Note: Replace sample_username and sample_password with your actual credentials. Production Environment Use these configuration values when connecting to the CONTROL production environment: TR-069 Parameter Value/Description Type Access InternetGatewayDevice.XMPP.Connection.1.Enable 1 boolean RW InternetGatewayDevice.XMPP.Connection.1.Domain control-xmpp.zequenze.com string RW InternetGatewayDevice.XMPP.Connection.1.Username sample_username string RW InternetGatewayDevice.XMPP.Connection.1.Password sample_password string RW InternetGatewayDevice.XMPP.Connection.1.Resource ConnReq string RW InternetGatewayDevice.XMPP.Connection.1.UseTLS 1 boolean RW InternetGatewayDevice.XMPP.Connection.1.TLSEstablished 1 boolean RO Device.ManagementServer.ConnReqJabberID sample_username@control-xmpp.zequenze.com/ConnReq string RO Device.XMPP.Connection.1.ServerConnectAlgorithm DNS-SRV string RW Device.XMPP.Connection.1.KeepAliveInterval 300 integer RW Note: Replace sample_username and sample_password with your actual credentials. Parameter Descriptions Enable : Activates the XMPP connection (set to 1 for enabled) Domain : The XMPP server domain for the respective environment Username : Authentication username for the XMPP connection Password : Authentication password for the XMPP connection Resource : XMPP resource identifier (typically ConnReq for Connection Request) UseTLS : Enables TLS encryption for the connection (set to 1 for enabled) TLSEstablished : Read-only status indicator showing whether TLS is successfully established ConnReqJabberID : Read-only Jabber ID used for connection requests ServerConnectAlgorithm : Connection method (DNS-SRV uses DNS service records) KeepAliveInterval : Time in seconds between keep-alive messages (default: 300) Interoperability CONTROL ACS - Interoperability List Overview This document lists all customer premises equipment (CPE) devices that have been validated for interoperability with CONTROL ACS as of September 2020. Device Categories The following device types are included in this compatibility list: eMTA - Embedded Multimedia Terminal Adapter LTE CPE - Long-Term Evolution Customer Premises Equipment LTE MiFi - Mobile WiFi Hotspot Device GPON ONT - Gigabit Passive Optical Network Optical Network Terminal DSL Modem - Digital Subscriber Line Modem WiFi Mesh/Extender - Wireless Network Range Extender Router - Network Routing Device Validated Devices The table below provides a complete list of validated devices, organized by vendor, model, and device type. Vendor Model Device Type Adtran AdTran 301 eMTA Adtran AdTran TA324 eMTA Adtran AdTran TA414 eMTA Adtran AdTran TA434 eMTA Alcatel Alcatel HH41 LTE CPE Alcatel Alcatel HH42 LTE CPE Alcatel Alcatel MW41 LTE CPE Alcatel Alcatel MW45 LTE CPE Arris Arris VAP4402 WiFi Mesh/Extender Arris Arris VAP4641 WiFi Mesh/Extender Arris Arris TG1652A eMTA Blu-Castle Blu-Castle 502 LTE CPE Calix Calix 844G GPON ONT Compal Compal CBN CH7369 eMTA Hitron Hitron HT-EMN3 WiFi Mesh/Extender Hitron Hitron HT-EN3 WiFi Mesh/Extender Hitron Hitron CHITA HC1S3 eMTA Hitron Hitron CGNV5 eMTA Huawei Huawei B2368 LTE CPE Huawei Huawei B310 LTE CPE Huawei Huawei B311 LTE CPE Huawei Huawei B312 LTE CPE Huawei Huawei B612 LTE CPE Huawei Huawei B612s LTE CPE Huawei Huawei HG8245Q2 GPON ONT Huawei Huawei HG8245W5-20 GPON ONT Huawei Huawei HN8255WS GPON ONT Huawei Huawei HQ8247H GPON ONT Huawei Huawei ZXHN F680 GPON ONT Iphotonix Iphotonix 7279G GPON ONT Iphotonix Iphotonix 7259G GPON ONT Kaon Kaon CG2200 eMTA Kaon Kaon GP2110-EB3 eMTA Kaon Kaon GP2110-EB4 eMTA M4 M4 C1 LTE CPE M4 M4 C2 LTE CPE M4 M4 Connect 1L LTE CPE M4 M4 Spot Movil 1 LTE MiFi M4 M4 WiLink1 LTE CPE M4 M4 WiLink5 LTE CPE Mikrotik MikrotikOS Router MindTech MindTech ON3402A eMTA MindTech MindTech ON6404H eMTA Nokia G-240W-C GPON ONT Nokia G-240W-B GPON ONT Nokia G-240W-G GPON ONT Pincom Pincom A7500-A1 DSL modem Quamtum Access Q1 LTE CPE Quamtum Access Q3 LTE CPE Quamtum Access Q6 LTE CPE Sagemcom Sagemcom F5657 eMTA Sagemcom Sagemcom F5688 eMTA Sagemcom Sagemcom FAST 3686 eMTA Sagemcom Sagemcom FAST 4630 eMTA Seowon Seowon SLC-150S07GQ LTE CPE Skyworth Skyworth GN541V eMTA Technicolor Technicolor 585 E7 DSL modem Technicolor Technicolor TG582N DSL modem Technicolor Technicolor CGA2121 eMTA Technicolor Technicolor FGA2130 eMTA Thomson Thomson 585v7 DSL modem TP-Link TP-Link-Deco-M4 WiFi Mesh/Extender TP-Link TP-Link-Deco-M5 WiFi Mesh/Extender TP-Link TP-Link-HC221-G1W WiFi Mesh/Extender Ubee Ubee UBC1310 eMTA ZTE ZTE ZXHN H108N DSL modem ZTE ZTE MF253V LTE CPE ZTE ZTE F680 GPON ONT ZTE ZXHN F2866S LTE CPE ZTE ZTE H196A WiFi Mesh/Extender Notes This list is updated periodically as new devices are validated for use with CONTROL ACS Interoperability validation ensures that devices can be properly managed, configured, and monitored through the CONTROL platform For questions about specific device compatibility or to request validation of additional models, please contact technical support Document Version: September 2020 RouterOS + tr069 staging process Install RouterOS in a virtual machine and connect it to CONTROL Overview This guide walks you through installing RouterOS in a VirtualBox virtual machine and connecting it to CONTROL using the TR-069 protocol. Prerequisites VirtualBox installed on your system Internet connection to download RouterOS files Basic familiarity with virtual machine management Step 1: Download RouterOS Visit the MikroTik download page and download the following files: RouterOS 6.48.6 Long-term x86 ISO image Extra packages (contains the TR-069 package) Step 2: Create the Virtual Machine Configure VM Settings Open VirtualBox and create a new virtual machine Enter the required information as shown below Allocate RAM memory (64 MB is sufficient for RouterOS) Create a virtual hard disk with the following settings: Configure Network Adapters After the VM is created, add an additional network adapter in the VM settings The network configuration should look like this: Step 3: Install RouterOS Boot and Installation Start the virtual machine Select the RouterOS ISO image and boot the VM When the package selection screen appears, press A to select all packages Press I to start the installation and confirm when prompted After installation completes, unmount the ISO image to prevent the installation wizard from restarting Step 4: Initial Configuration Login to RouterOS Once the login screen appears, use the default credentials: Username: admin Password: (leave blank) Assign IP Address Add an IP address to enable remote access. For this example, we'll use 192.168.1.50 : ip address add address=192.168.1.50/24 interface=ether1 Verify the IP address was added correctly: ip address print Access Web Interface Open a web browser and navigate to the RouterOS web interface using the IP address you configured: http://192.168.1.50/webfig/ Click on WebFig to access the full configuration interface Step 5: Install TR-069 Package Navigate to Files in the WebFig interface and upload the TR-069 package Extract the downloaded Extra packages archive and locate the TR-069 package file Reboot the router to complete the package installation After reboot, verify that TR-069 is enabled in the system Step 6: Obtain RouterOS License RouterOS displays a warning message indicating you have 24 hours to use the software without a license. You must register to obtain a free demo license. Save Software ID Note the Software ID displayed in the license warning message Generate License Key Register for a MikroTik account at the registration page After logging in, navigate to MAKE A DEMO KEY , enter your Software ID, and generate the license Activate License Connect to RouterOS via SSH Paste the license key in the terminal and reboot to complete activation After reboot, a confirmation message indicates the license was successfully activated [![License activated](https://docs.zequenze.com/uploads/images/gallery/2022-02/scaled-1680-/kxs0BYgcbsxaeEkM-image-1645825 IPsec Configuration Overview This guide explains how to configure an IPsec VPN tunnel between RouterOS and CONTROL. The configuration process involves setting up both endpoints to establish a secure site-to-site connection. Part 1: RouterOS Configuration Initial Access Log in to RouterOS using your default credentials Navigate to IP → IPsec in the left-side menu Step 1: Configure Profiles (Phase 1) The profile defines Phase 1 parameters for the IPsec connection. Click the Profiles tab in the center panel Click Add New to create a new profile Configure the following Phase 1 parameters: Name : Enter a descriptive name to identify the profile (e.g., "profile-to-ctl01.dev") Hash Algorithms : Select a hash algorithm that matches the configuration on the remote endpoint Encryption Algorithm : Choose an encryption algorithm that matches the remote endpoint configuration Lifetime : Leave the default value (measured in seconds) NAT Traversal : Enable this option if the router is behind NAT DPD Interval : Leave the default value for Dead Peer Detection and note this number DPD Maximum Failures : Leave the default value Click Apply , then click OK Step 2: Configure Peers The peer configuration defines the remote VPN endpoint. Click the Peers tab Click Add New Configure the following fields: Name : Enter a name to identify the remote peer Address : Enter the remote public IP address (e.g., 35.35.35.22/32) Profile : Select the profile created in Step 1 Exchange Mode : Select the exchange mode (IKE2 is recommended) Click Apply , then click OK Step 3: Configure Identities The identities configuration defines authentication credentials. Click the Identities tab Click Add New Configure the following fields: Peer : Select the peer configured in Step 2 Auth. Method : Select "pre shared key" Secret : Enter the pre-shared key that will be configured on both endpoints Click Apply , then click OK Step 4: Configure Proposals (Phase 2) The proposal defines Phase 2 parameters for the IPsec connection. Click the Proposals tab Click Add New Configure the following Phase 2 parameters: Name : Enter a name to identify this proposal Auth. Algorithms : Select the authentication algorithm to be used on both endpoints Encr. Algorithms : Select the encryption algorithm to be used on both endpoints Lifetime : Set the lifetime for Phase 2 PFS Group : Select the Diffie-Hellman group for Perfect Forward Secrecy (PFS). This determines the session key generation during key exchange Click Apply , then click OK Step 5: Configure Policies The policy defines which traffic should pass through the VPN tunnel. Click the Policies tab Click Add New Configure the following fields: Peer : Select the peer configured in Step 2 Tunnel : Enable this option to establish the tunnel between both sites Src. Address : Enter the local IP address or network that will pass through the tunnel Dst. Address : Enter the remote IP address or network that will be received from the other end Level : Select "unique" Proposal : Select the proposal created in Step 4 Click Apply , then click OK Part 2: CONTROL Configuration Initial Navigation Navigate to the Links section in the left-side menu Select the Services tab at the top Click the +Add button Step 1: Create IPsec Security Service (Phase 1) Configure the basic information: Name : Enter a name to identify Phase 1 Short-name/code : Enter a short identifier for quick reference Organization : Select the organization that will use this connection Type : Select "IPsec Security" Click Save at the bottom Configure the Phase 1 parameters to match your RouterOS configuration: Authentication method : Select "PSK" IKE version : Select "Version 2" Encryption algorithm : Enter "aes256" Integrity algorithm : Enter "sha256" or "sha2_256" Diffie Hellman group (PFS) : Enter "modp1024" Lifetime : Enter 1200 (equivalent to 20 minutes) Key negotiation retries : Enter "0" Aggressive Mode : Enable this option Click Save and close at the bottom Step 2: Create IPsec Configuration Service (Phase 2) In the Services tab, click +Add again to create another service Configure the basic information: Name : Enter a name to identify Phase 2 Short-name/code : Enter a short identifier for quick reference Organization : Select the organization that will use this connection Type : Select "IPsec Configuration" Configure the Phase 2 parameters to match your RouterOS configuration: Tunnel type : Select "Tunnel (ESP)" Encryption algorithm : Enter "aes256" Integrity algorithm : Enter "sha256" or "sha2_256" Diffie Hellman group (PFS) : Enter "modp1024" Lifetime : Enter 1200 (equivalent to 20 minutes) Step 3: Create Association In the Links section, select the Association tab Click the +Add button Configure the following fields: Name : Enter a name to identify this association Short-name / code : Enter a short identifier for quick reference Type : Leave "IPSec VPN" selected Local gateway type : Leave "Private IP" selected Remote gateway address : Enter the remote public IP address you are connecting to Remote gateway id : Enter the WAN interface IP of the RouterOS device Secret : Enter the pre-shared key (must match the secret configured in RouterOS) Security service : Select the IPsec Security service created in Step 1 Configuration service : Select the IPsec Configuration service created in Step 2 Server : Select the internal server to use Organization : Select the organization that will use this connection Step 4: Create Link In the Links section, ensure you are on the Links tab Click the +Add button Configure the following fields: Name : Enter a name to identify this link Short-name / code : Enter a short identifier Active : Enable this option to activate the link Association : Select the association created in Step 3 Local network : Enter the local Zequenze IP address For CONTROL: typically 172.31.255.254/32 For GATE: typically 172.31.255.253/32 (Verify the correct IP internally before configuring) Remote network : Enter the remote network or IP address that will pass through the tunnel to Zequenze Check services : Select "PING Connectivity test" to validate tunnel communication Check address/hostname : Enter a remote IP address that is always active for connectivity testing (typically the remote gateway, e.g., 192.168.106.154) Organization : Select the organization that will use this VPN connectivity Verification and Summary RouterOS Connection Status Once the configuration is complete, you should see the connection established in RouterOS as shown below: CONTROL Connection Status The Link within CONTROL should appear as follows when successfully established: This completes the IPsec VPN tunnel configuration between RouterOS and CONTROL. The tunnel should now be active and passing traffic between the configured networks. Setting up TR-069 client on mikrotik hAP ac2 Prerequisites Before configuring the TR-069 client, ensure your MikroTik hAP ac2 device has an active internet connection. Required Configuration Parameters You will need the following credentials and settings to configure the TR-069 client in CONTROL: ACS URL: The endpoint URL where your device will report its status and receive management commands Username: Authentication username for the ACS URL Password: Authentication password for the ACS URL Note: These credentials should be provided by your CONTROL administrator or obtained from your CONTROL portal settings. Configuration Steps Follow the video tutorial below for step-by-step instructions on configuring the TR-069 client on your MikroTik hAP ac2: Additional Information The TR-069 protocol enables remote management and monitoring of your MikroTik device through the CONTROL platform. Once configured, your device will automatically establish communication with the ACS server and appear in your CONTROL dashboard. Stun and Ejabberd monitoring Ejabberd API Overview The Ejabberd API provides RESTful endpoints for managing and monitoring XMPP server operations within CONTROL. All requests require HTTP basic authentication and use JSON for request/response payloads. Authentication All API endpoints require basic authentication using admin credentials: Username : root@control-xmpp-dev.zequenze.com Password : Your admin API token Base URL : https://127.0.0.1:5443/api/ API Endpoints Get Registered Stats Hosts Retrieves statistics for registered hosts, including online user counts. Endpoint : /stats_host Request Parameters : name - The statistic name (e.g., "onlineusers") host - The XMPP host domain Example : curl -k --basic --user root@control-xmpp-dev.zequenze.com:6N3Zne3ByoSCnZ3d46Gerf452nxLBcNp \ -H 'Content-Type: application/json' \ -d '{ "name": "onlineusers", "host": "control-xmpp-dev.zequenze.com" }' \ 'https://127.0.0.1:5443/api/stats_host' Get Connected Users Returns a list of all currently connected users. Endpoint : /connected_users Example : curl -k --basic --user root@control-xmpp-dev.zequenze.com:6N3Zne3ByoSCnZ3d46Gerf452nxLBcNp \ 'https://127.0.0.1:5443/api/connected_users' Get Registered Users Retrieves all registered users for a specific host. Endpoint : /registered_users Request Parameters : host - The XMPP host domain Example : curl -k --basic --user root@control-xmpp-dev.zequenze.com:6N3Zne3ByoSCnZ3d46Gerf452nxLBcNp \ -H 'Content-Type: application/json' \ -d '{ "host": "control-xmpp-dev.zequenze.com" }' \ 'https://127.0.0.1:5443/api/registered_users' Get Connected Users Info Returns detailed information about all connected users. Endpoint : /connected_users_info Example : curl -k --basic --user root@control-xmpp-dev.zequenze.com:6N3Zne3ByoSCnZ3d46Gerf452nxLBcNp \ 'https://127.0.0.1:5443/api/connected_users_info' Get User Presence Retrieves the presence status for a specific user. Endpoint : /get_presence Request Parameters : user - The username host - The XMPP host domain Example : curl -k --basic --user root@control-xmpp-dev.zequenze.com:6N3Zne3ByoSCnZ3d46Gerf452nxLBcNp \ -H 'Content-Type: application/json' \ -d '{ "user": "hy400219100000286", "host": "control-xmpp-dev.zequenze.com" }' \ 'https://127.0.0.1:5443/api/get_presence' Get User Session Info Returns detailed session information for a specific user. Endpoint : /user_sessions_info Request Parameters : user - The username host - The XMPP host domain Example : curl -k --basic --user root@control-xmpp-dev.zequenze.com:6N3Zne3ByoSCnZ3d46Gerf452nxLBcNp \ -H 'Content-Type: application/json' \ -d '{ "user": "hy400219100000286", "host": "control-xmpp-dev.zequenze.com" }' \ 'https://127.0.0.1:5443/api/user_sessions_info' Get User Resources Retrieves all active resources (connections) for a specific user. Endpoint : /user_resources Request Parameters : user - The username host - The XMPP host domain Example : curl -k --basic --user root@control-xmpp-dev.zequenze.com:6N3Zne3ByoSCnZ3d46Gerf452nxLBcNp \ -H 'Content-Type: application/json' \ -d '{ "user": "hy400219100000286", "host": "control-xmpp-dev.zequenze.com" }' \ 'https://127.0.0.1:5443/api/user_resources' Customer Engineering ACS Operational Launch Checklist Overview This checklist ensures a successful ACS operational launch for CONTROL. Complete each step in sequence before deploying devices to end-customers. Prerequisites Checklist 1. Device Testing and Integration All devices must be tested and integrated in the development platform before proceeding to production. Development Platform: control-dev.zequenze.com Ensure all device profiles are validated and functioning correctly in this environment. 2. DNS Configuration Configure your own FQDN pointing to Zequenze's production environment. This allows your devices to use a domain under your management. Typical DNS Configuration: acs.myMVNO.com CNAME control.zequenze.com. Replace myMVNO.com with your actual domain name. 3. TR-069 Credentials Configuration All devices (modems) must have TR-069 credentials properly configured with the following parameters: URL: https://acs.myMVNO.com/cwmp Username: To be agreed (typically the same as used in the development platform) Password: To be agreed (typically the same as used in the development platform) Important: These TR-069 settings must be configured by default in the device's firmware/software. This ensures that devices continue reporting to the ACS platform even after a factory reset. Production Validation Testing Before deploying to end-customers, perform the following validation tests on the production environment. This step requires completion of steps 1-3 above. Required Validation Tests Configure test modem — Ensure the modem has Internet access and can reach the ACS Validate onboarding — Verify proper device onboarding and visualization through both WebGUI and REST API Validate operations — Test configuration changes and operational commands (Reboot, Factory Reset) Validate use cases — Test any additional validations or specific use cases required for your deployment All tests must complete successfully before proceeding to deployment. Deployment Authorization Once all validation tests are successful, you are authorized to begin deploying devices to end-customers. Final Verification: ✓ All devices validated in development platform ✓ FQDN created and DNS configured ✓ Modems configured with correct TR-069 credentials ✓ Production validation tests completed successfully Configuring STUN (UDP-based connection request) Overview STUN (Session Traversal Utilities for NAT) is a TR-069 connection-request helper protocol that enables the ACS (Auto Configuration Server) to reach CPE (Customer Premises Equipment) devices that cannot be accessed via direct HTTP requests. STUN is typically required when the CPE is located behind a firewall or a NAT (Network Address Translation) process. Configuration Requirements To enable STUN functionality, both the CONTROL ACS platform and the CPE must be properly configured. CPE Configuration Configuring STUN on the CPE is straightforward and requires only two parameters: STUN Server FQDN : The Fully Qualified Domain Name of the STUN server Port : The UDP port number for STUN communication Development Environment Settings For testing and development purposes, use the following configuration: STUN Server: control-stun-dev.zequenze.com Port: 3478 CONTROL ACS Configuration On the CONTROL ACS platform, STUN-related variables must be added to the Device Profile. A typical configuration example: How STUN Connection Requests Work Once STUN is configured on both the ACS and CPE: The CPE establishes a UDP binding with the STUN server The CPE reports this UDP binding address to the ACS using the TR-181 parameter: Device.ManagementServer.UDPConnectionRequestAddress The ACS uses this reported address for all subsequent connection-request procedures This mechanism allows the ACS to communicate with CPE devices even when they are not directly accessible via traditional HTTP connection requests. FAQ ACS | MVNO ALTAN Plataforma ACS Zequenze para MVNO ALTAN Preguntas Frecuentes ¿Qué es y para qué sirve la plataforma ACS Zequenze? La plataforma ACS Zequenze permite al MVNO gestionar y operar los dispositivos de cliente (por ejemplo, módems) de forma remota, segura y automatizada. Principales funcionalidades Las principales tareas que se pueden realizar y automatizar a través de la plataforma ACS Zequenze son: Aprovisionamiento y onboarding de dispositivos en la plataforma Visualización de la configuración y valores operacionales del módem (por ejemplo, red LTE, red WiFi) Cambios en la configuración de los dispositivos (por ejemplo, nombre/contraseña WiFi, canal de red WiFi) Operaciones de Reboot y Factory Reset en el dispositivo Gestión de actualizaciones de firmware/software de los dispositivos Gestión de pruebas de desempeño (Download, Upload, Delay/Jitter) en los dispositivos Reportes y analíticos Adicionalmente, la plataforma provee extensos reportes y analíticos sobre los dispositivos, incluyendo: Estatus en tiempo real de los dispositivos (con conectividad a Internet) Analíticos sobre marca y modelo de dispositivos en la red Analíticos sobre versión de software en los dispositivos Analíticos en tiempo real sobre parámetros LTE de los dispositivos (RSSI, SINR, otros) Interfaces de gestión Como se indica en el diagrama anterior, la gestión de los dispositivos está disponible mediante: WebGUI : Para operadores NOC o Ingeniería REST API : Para integración con plataformas CRM o similares (por ejemplo, operadores de Call Center) ¿Qué necesito para gestionar mis dispositivos con la plataforma ACS Zequenze? El único requisito es que los dispositivos de usuario (módems) soporten el protocolo estándar TR-069 y que estén apropiadamente configurados para reportar hacia la plataforma ACS Zequenze. Configuración para pruebas Para fines de pruebas , los dispositivos pueden ser fácilmente configurados para reportar a la plataforma con solo estos tres parámetros: URL : https://prueba-altan.zequenze.com/ Usuario : a ser acordado Contraseña : a ser acordado Configuración para producción Una vez validada la integración de cada tipo de dispositivo, se podrá acordar el mecanismo con el cual se configurarán en forma masiva los dispositivos de usuarios. Los métodos más típicos son: Para nuevos dispositivos: Pre-configuración TR-069 vía firmware/software en el dispositivo (URL, Usuario, Contraseña) Para dispositivos existentes: Actualización del firmware/software (FOTA) que integre la apropiada configuración TR-069 del dispositivo (URL, Usuario, Contraseña) ¿Puedo migrar mis dispositivos de un ACS existente a la plataforma ACS Zequenze? Absolutamente. Una de las ventajas del protocolo utilizado por las plataformas ACS (TR-069) es que es estándar y no permite hacer lock-in de los clientes en una plataforma ACS en particular. Una vez que se valide la integración de tus dispositivos con la plataforma ACS Zequenze, podremos establecer un plan para esta migración, lo cual es tan sencillo como: Cambiar el URL del ACS en tus dispositivos (vía la plataforma ACS actual), o bien Reconfigurar el FQDN del URL al que apuntan tus dispositivos actualmente ¿Cómo gestiono mis dispositivos vía la plataforma ACS Zequenze? Según lo mencionado anteriormente, la plataforma provee interfaces WebGUI y REST API para la gestión de los dispositivos. Ejemplo WebGUI plataforma ACS Zequenze ¿Qué diferencia la solución ACS Zequenze de otras soluciones del mercado? Podemos resumir las principales diferencias en dos áreas: Relacionadas a la plataforma ACS Plataforma de última generación hospedada en la nube pública que permite escalar desde pocos miles a millones de dispositivos gestionados Plataforma ya integrada con la red ALTAN y con la mayoría de los dispositivos (módems) HBB existentes en la red Plataforma multi-organizacional, que permite la existencia de diferentes organizaciones administrativas (jerárquicas) para los dispositivos y usuarios de la misma Diferentes tipos de privilegios para usuarios de la plataforma (solo lectura, gestión básica, gestión avanzada) Flexibilidad en la definición de los perfiles de dispositivos, pudiendo adaptarnos a cualquier modelo de datos del fabricante (TR-098, TR-181, TR-135, etc.) Herramientas de automatización y scripting , permitiendo realizar cambios de configuración o generación de reportes específicos sobre una población del parque de dispositivos Relacionadas a Zequenze como empresa Amplia experiencia de trabajo con operadores de telecomunicaciones en México y Latinoamérica Soporte técnico experto local, con profundo entendimiento y experiencia en gestión de dispositivos (TR-069, USP, MQTT, etc.) Estamos comprometidos con el mejor servicio a nuestros clientes y nunca anteponemos la burocracia a la eficiencia Somos 10x más ágiles que cualquier suministrador clásico de soluciones de software para telecomunicaciones Si deseas conocer más de Zequenze, te invitamos a visitar nuestro website https://zequenze.com Checklist y próximos pasos Si deseas evaluar o implementar la plataforma ACS Zequenze, puedes contactarnos directamente escribiéndonos a team@zequenze.com Por favor incluye la siguiente información: Nombre del MVNO e información de contacto Estimación de número de dispositivos activos al mes Tipos/Marcas de dispositivos (módems) Importante: No olvides confirmar que cuentan con el soporte de TR-069 con el fabricante/suministrador del módem How to onboard devices into zequenze CONTROL ACS Overview Onboarding devices into Zequenze CONTROL is a straightforward process. This guide provides the key considerations and steps to successfully connect your devices to the CONTROL Access Control Server (ACS). Key Concepts Before beginning the onboarding process, understand these fundamental aspects: Cloud-Based Architecture : Zequenze ACS is hosted in the Public Cloud (AWS/GCP), so all devices must have Internet connectivity to communicate with the platform. TR-069 Protocol : The protocol follows a client-to-server model where devices (CPEs) periodically report to the ACS at intervals defined by the Report Interval parameter. For a comprehensive understanding of TR-069, refer to this tutorial . Remote Management : Once successfully onboarded, the ACS enables remote configuration and management of CPEs using TR-069 variables supported by each device. These variables are defined in TR-098/TR-181 Data Models and can be managed through the ACS platform GUI or REST API. Requirements Mandatory Parameters For a CPE to communicate with the ACS platform via TR-069, configure the following four (4) parameters: ACS URL : The FQDN where devices will initiate TR-069 sessions. Username & Password : Onboarding credentials used by the CPE to authenticate with the ACS platform. Report Interval : Time interval (in seconds) for periodic Inform messages from the CPE to the ACS platform. Internet Connectivity : Required for cloud-based ACS access. Note : Some CPEs, such as FTTH ONTs, may require specific WAN VLAN configuration to permit TR-069 traffic. DNS Configuration Internet Service Providers (ISPs) must define their own FQDN as a CNAME record pointing to the Zequenze ACS platform. For example: acs.myISP.com CNAME A control.zequenze.com. Configuration Default TR-069 Parameters Once DNS is configured, set up your devices with the following default TR-069 configuration: URL : https://acs.myISP.com/cwmp Username : Provided by Zequenze (unique per device model) Password : Provided by Zequenze (unique per device model) Report Interval : Provided by Zequenze (typically 7200 seconds) Configuration Methods There are two (2) primary methods for mass-configuring default TR-069 settings on devices: Vendor Integration : Request your CPE vendor to embed this information into the device's software default values. DHCP Option 43 : Use DHCP Option 43 to provision TR-069 parameters automatically. For more details on ACS Discovery methods, consult this tutorial . Important Considerations CRITICAL : Verify that the default TR-069 configuration persists after a factory reset. This ensures devices remain under ACS management even after being reset to factory defaults. Validation Verifying Successful Onboarding Once properly configured with Internet access, devices will automatically onboard to the platform. Successfully onboarded devices appear in the Inventory view of the CONTROL GUI: Inventory View Fields The following table explains the information displayed in the Inventory view: Field Description Name Unique device name in the platform. Automatically generated as the concatenation of Device OUI + Serial Number. Upon initial onboarding with model-specific credentials, the ACS assigns unique Username/Password credentials to each device. ID Device's unique identifier within the ACS platform. Status Indicates whether the device is currently reporting periodically to the platform. Profile CWMP (TR-069) profile assigned to this device. Each device model uses a specific profile based on its data model, which can be customized per customer requirements. Serial Device serial number. Groups Logical groups to which the device belongs. Location Physical location assigned to the device. Description Notes and metadata about the device. By default, the initial onboarding timestamp is recorded here. Troubleshooting Common Issues If a configured device does not automatically onboard, verify the following: ACS URL Configuration : Confirm the ACS URL is correctly set on the device (check in the device's GUI or management interface). Credentials : Verify that Username and Password are properly configured on the device (check in the device's GUI or management interface). Internet Connectivity : Ensure the device has active Internet access. Note : Some CPEs, particularly FTTH ONTs, require specific WAN VLAN configuration to allow TR-069 traffic through the network. Additional Support If you continue experiencing onboarding issues after performing these checks, our team is available to assist with detailed troubleshooting. Please contact us for specialized support. How to setup a webserver for TR-143 Performance Tests TR-143 defines the standard framework for running performance tests from a CPE (Customer Premises Equipment) through the TR-069 protocol. Specifically for the Download and Upload tests, the CPE requires a functional HTTP server to either download or upload files to compute current throughput and measure network performance. This guide explains how to configure a web server that supports both download and upload functionality for TR-143 performance testing when using CONTROL. Requirements Linux server (this guide uses Ubuntu 24.04 LTS) Root or sudo access Network connectivity between the CPE and the server Installation Steps Install Nginx Update the package list and install Nginx: sudo apt update sudo apt install nginx Create Directory Structure Create the necessary directories for downloads, uploads, and temporary files: sudo mkdir -p /var/www/files sudo mkdir -p /var/www/files/download sudo mkdir -p /var/www/files/upload sudo mkdir -p /var/www/files/tmp Set the correct ownership for the web server: sudo chown -R www-data:www-data /var/www/files Configure Nginx Edit the Nginx configuration file located at `/etc/nginx/sites-available/default` with the following content: server { listen 80; server_name noname; root /var/www/files/download; location / { autoindex off; } client_max_body_size 100M; location /upload { client_body_temp_path /tmp; alias /var/www/files/upload; dav_methods PUT; dav_access user:rw group:rw all:r; } } Configuration notes: listen 80 — Server listens on HTTP port 80 root /var/www/files/download — Root directory for download files client_max_body_size 100M — Maximum upload file size set to 100MB dav_methods PUT — Enables HTTP PUT method for file uploads location /upload — Dedicated endpoint for upload operations Apply Configuration Verify the configuration syntax: sudo nginx -t If the configuration is valid, restart Nginx to apply changes: sudo systemctl restart nginx Testing the Setup Download Test To test download functionality, first create a test file in the download directory (e.g., `100MB.bin`), then download it from a client machine: wget http:///100MB.bin Upload Test To test upload functionality, upload a file from your local machine to the server (uploading a file named **`test-upload.bin`** from your local host to the server): curl -X PUT --data-binary @test-upload.bin http:///upload/test-upload.bin Replace `` with your server's actual IP address and ensure the test file exists locally before running the upload command. Troubleshooting Verify Nginx is running: `sudo systemctl status nginx` Check Nginx error logs: `sudo tail -f /var/log/nginx/error.log` Ensure firewall allows HTTP traffic on port 80 Verify file permissions in `/var/www/files` directories WiFi Evaluation and Optimization Overview of Evaluation Introduction This evaluation assesses the quality and performance of WiFi connections for clients connected to a CPE (Customer Premises Equipment) using TR-181 data. The assessment provides a comprehensive analysis based on six key factors that determine network performance and connectivity quality. Evaluation Factors The WiFi evaluation system analyzes the following six factors: 1. Signal Strength Measures the strength of the WiFi signal received by client devices. A stronger signal generally indicates better connectivity and more reliable network performance. 2. Noise Evaluates the level of background noise in the WiFi environment. Lower noise levels contribute to clearer signal transmission and improved overall performance. 3. Interference Assesses the impact of other WiFi networks or devices operating on the same or adjacent channels. Lower interference levels lead to better performance and more stable connections. 4. SNR (Signal-to-Noise Ratio) Represents the ratio between the desired signal level and background noise level. A higher SNR typically results in better WiFi performance and more reliable data transmission. 5. Standard Considers the WiFi standard being used (e.g., 802.11n, 802.11ac, 802.11ax) and how it aligns with the capabilities of both the CPE and client devices. More advanced standards generally offer better performance and enhanced features. 6. Speed Evaluates the actual data transfer rates achieved by client devices compared to the theoretical maximum rates for the given WiFi standard and configuration. Frequency Band Analysis These factors are analyzed for both 2.4GHz and 5GHz frequency bands, providing a comprehensive assessment of the WiFi network's performance and quality across different spectrum ranges. Multi-AP Support Requirements For optimal evaluation accuracy, devices should support Multi-AP with the "Data Elements" parameter as defined in the TR-181 standard. For more information, refer to the TR-181 Device.WiFi.DataElements specification . Signal Strength Factor Analysis in WiFi Evaluation Overview Signal Strength Factor is a critical metric for evaluating your WiFi network's performance. It is based on the Received Signal Strength Indicator (RSSI) of data frames, which measures the power level of the WiFi signal your device receives during actual data transmission. Unlike measurements based solely on beacon frames, Signal Strength Factor provides a more accurate representation of real-world connection quality during active use. Measurement Methodology Technical Foundation The Signal Strength Factor is derived from the DataFrameRSSI parameter, which is part of the ESS Link Parameter Set as defined in IEEE industry standards: DataFrameRSSI is the received signal strength in dBm of received Data frames from the network. This may be time-averaged over recent history by a vendor-specific smoothing function. Valid Range: -100 to 40 dBm Implementation Details In practical implementation, CONTROL obtains this data using the TR-181 parameter: Device.WiFi.AccessPoint.AssociatedDevice.SignalStrength This parameter is defined as: An indicator of radio signal strength of the uplink from the associated device to the access point, measured in dBm, as an average of the last 100 packets received from the device. If the instance of this AssociatedDevice is the same as Device.WiFi.DataElements.Network.Device.{i}.Radio.{i}.BSS.{i}.STA.{i}., then this parameter is the same as Device.WiFi.DataElements.Network.Device.{i}.Radio.{i}.BSS.{i}.STA.{i}.SignalStrength. Signal Strength Rating Scale CONTROL translates raw dBm measurements into a user-friendly scale ranging from 4 to 10: 10 (Excellent) — Your device is receiving a very strong signal strength, typically when very close to the router or in ideal conditions. 9 (Very Good) — The signal is strong and should provide excellent performance for most applications. 8 (Good) — A solid signal strength that is suitable for most online activities. 7 (Fair) — The signal is moderate. You may experience some slowdowns with demanding applications. 6 (Poor) — The signal is weak. You might encounter issues with stability and speed. 4 (Very Poor) — The signal is very weak. Connectivity problems are likely, and performance will be significantly impacted. Why Signal Strength Factor Matters Real-World Performance DataFrameRSSI reflects the signal strength of actual data transmission rather than just beacon frames, providing a more accurate picture of your connection quality during active use. User Experience Impact A higher Signal Strength Factor typically results in: Smoother online activities with fewer interruptions More consistent performance across applications Reduced latency and buffering Device Efficiency Better signal strength helps conserve device battery life, as less power is required to maintain a strong, stable connection. Improving Your Signal Strength Factor To optimize your Signal Strength Factor, consider the following recommendations: Reduce physical distance — Move closer to your WiFi router Clear line of sight — Remove obstacles between your device and the router Minimize interference — Reduce interference from other electronic devices Extend coverage — Consider using a WiFi extender or mesh system for larger spaces Optimize placement — Ensure your router is centrally located in your home or office Standards Compliance CONTROL's evaluation system is designed to align with industry standards while providing easy-to-understand insights into your WiFi performance. References IEEE Std 802.11™‐2020 Device:2 Root Data Model definition [CWMP] TR-181 Issue 2 Amendment 15 Noise Factor in WiFi Evaluation What is Noise Factor? Noise Factor is a crucial component in evaluating your WiFi network's performance. It's based on the Average Noise Power Indicator (ANPI), which measures the level of unwanted electromagnetic energy or interference in your WiFi environment. By understanding your Noise Factor, you can identify potential issues affecting your network quality and take steps to optimize your wireless performance. Technical Foundation The Noise Factor in CONTROL is derived from industry-standard measurements and specifications: 1. ANPI (Average Noise Power Indicator) As defined in IEEE 802.11 standards, ANPI is "a medium access control (MAC) indication of the average noise plus interference power measured when the channel is idle." This measurement is taken under specific conditions to ensure accuracy and provides a reliable baseline for noise assessment. 2. Noise Histogram The WiFi system continuously collects detailed noise data over time, creating a histogram that shows the distribution of noise levels across your network environment. This historical data enables more accurate noise pattern analysis. 3. TR-181 Standard This standard defines the Noise parameter as "an indicator of radio noise on the uplink from the associated device to the access point, measured in dBm, as an average of the last 100 packets received from the device." This provides a practical, real-world measurement of noise affecting active connections. How is Noise Factor Measured? Based on these technical standards, CONTROL translates the raw noise measurements into a user-friendly scale from 4 to 10: 10 (Excellent) : Very low noise, typically below -92 dBm 8 (Good) : Low noise, between -92 dBm and -86 dBm 6 (Fair) : Moderate noise, between -86 dBm and -75 dBm 4 (Poor) : High noise, above -75 dBm This scale is derived from the IPI (Idle Power Indicator) definitions for Noise Histogram reports in the IEEE 802.11 standard, ensuring consistency with industry best practices. Why is Noise Factor Important? Understanding your Noise Factor helps you assess several critical aspects of your WiFi performance: Signal Clarity Lower noise levels allow for clearer WiFi signals, improving overall connection quality. Clean signals mean more reliable data transmission and fewer dropped packets. Performance Impact High noise levels can significantly reduce your effective WiFi speed and reliability, even when your signal strength appears good. Noise directly affects the signal-to-noise ratio, which determines your maximum achievable throughput. Range Effect In low-noise environments, your WiFi signals can effectively reach farther distances. Less interference means devices at the edge of your coverage area maintain better connectivity. Technical Insight: Noise Histogram and ANPI The WiFi system constantly monitors noise levels in your environment, creating a histogram of these measurements over time. This histogram helps calculate the ANPI value, which CONTROL uses as the basis for your Noise Factor score. By analyzing patterns in the noise histogram, CONTROL can identify: Consistent interference sources Time-based noise patterns Environmental factors affecting your network Opportunities for optimization How to Improve Your Noise Factor If your Noise Factor score is lower than desired, consider these optimization strategies: Identify and eliminate interference sources — Common culprits include microwaves, cordless phones, Bluetooth devices, baby monitors, and wireless security cameras Change your WiFi channel — Select a channel with less interference from neighboring networks Use a WiFi analyzer — Deploy a WiFi analyzer app to identify less congested channels in your area Consider the 5 GHz band — The 5 GHz frequency band is often less crowded than 2.4 GHz, resulting in lower noise levels Update router firmware — Ensure your router's firmware is current, as newer versions may include improved noise-handling capabilities Optimize router placement — Position your router away from potential interference sources and metal objects Noise Factor in Context While a good Noise Factor is important, it works in conjunction with other metrics like Signal Factor. The relationship between signal strength and noise is captured in the Signal-to-Noise Ratio (SNR), which is a key determinant of overall WiFi performance. A strong signal (high Signal Factor) combined with low noise (high Noise Factor) produces an excellent SNR, resulting in optimal network performance. Conversely, even a strong signal can be compromised by high noise levels. Remember : Noise Factor is just one piece of the puzzle in understanding your overall WiFi performance. CONTROL combines it with other metrics to give you a comprehensive view of your network's health and capabilities. Interference Factor in WiFi Evaluation Overview The Interference Factor is a crucial metric for evaluating your WiFi network's performance within the CONTROL portal. It quantifies the impact of other WiFi networks and devices operating on the same or adjacent channels as your network. Lower interference levels correlate directly with better overall WiFi performance. Technical Foundation The Interference Factor calculation is based on several core technical concepts from WiFi standards: Channel Overlap : WiFi channels can overlap, particularly in the 2.4 GHz band. This overlap is a primary source of interference between networks. Signal Strength of Neighboring Networks : The received signal strength from nearby WiFi networks directly impacts the level of interference experienced by your network. Operating Channel Bandwidth : Wider channel bandwidths (such as 40 MHz compared to 20 MHz) increase the likelihood of interference with neighboring networks due to greater spectrum occupancy. Measurement Methodology Data Collection The CONTROL system analyzes your WiFi environment and calculates an interference score based on data obtained from the TR-181 parameter: Device.WiFi.NeighboringWiFiDiagnostic.Result. This parameter provides a "Neighboring SSID table" that models all WiFi SSIDs detectable by your device. At most one entry in this table can exist with a given value for BSSID . Calculation Process To calculate the Interference Factor, the system: Retrieves the neighboring WiFi networks table Compares this data with your CPE (Customer Premises Equipment) transmission channels (2.4 GHz and/or 5.0 GHz) Analyzes the "Current Operating Channel Bandwidth" Evaluates the overlap and signal strength relationships The system considers multiple factors during calculation: Number of Overlapping Networks : More networks on the same or adjacent channels increase interference Signal Strength of Interfering Networks : Stronger signals from other networks cause more significant interference Channel Width : Wider channels (e.g., 40 MHz in 2.4 GHz) are more susceptible to overlap with other networks Frequency Band : The 2.4 GHz band is typically more congested and prone to interference than the 5 GHz band Scoring Scale The resulting interference score is translated into a user-friendly scale from 2 to 10: 10 (Excellent) : Minimal interference, ideal conditions 8 (Good) : Low interference, suitable for most applications 6 (Fair) : Moderate interference, may affect some high-bandwidth applications 4 (Poor) : Significant interference, likely to impact performance 2 (Very Poor) : Severe interference, major impact on WiFi performance Interpreting Your Interference Factor Understanding your Interference Factor score helps you assess your WiFi environment: 10-9 : Ideal environment with minimal interference from other networks 8-7 : Good environment, most applications should work well 6-5 : Noticeable interference present, may affect some applications 4-3 : Significant interference, likely to impact overall WiFi performance 2 : Severe interference, major issues with WiFi performance expected Impact on Network Performance Why Interference Factor Matters Network Performance : High interference can significantly reduce your WiFi speed and reliability Consistency : In high-interference environments, your WiFi performance may be inconsistent and unpredictable Range : Interference can effectively reduce the usable range of your WiFi network Relationship to Other Metrics The Interference Factor works alongside other metrics like Signal Factor and Noise Factor. While a strong signal can sometimes overcome interference, reducing interference is often the key to improving overall WiFi performance, especially in densely populated areas. Remember that Interference Factor is just one component of a comprehensive WiFi evaluation that helps you understand and optimize your network's capabilities. Optimization Strategies If your Interference Factor score is lower than desired, consider these improvement strategies: Change your WiFi channel to one with less interference If possible, use the 5 GHz band, which typically experiences less interference Reduce your channel width (e.g., from 40 MHz to 20 MHz) in crowded environments Position your router away from neighbors' WiFi equipment In dense areas, consider using a WiFi system that can automatically select the optimal channel References TR-181 Issue 2 Amendment 15 IEEE 802.11 standards SNR Factor in WiFi Evaluation Overview The SNR Factor, based on the Signal-to-Noise Ratio (SNR), is a critical metric for evaluating WiFi network performance within CONTROL. It measures the relationship between your WiFi signal strength and the background noise level in your environment. A higher SNR value indicates better WiFi performance and connection quality. Technical Foundation Core Principles SNR Factor is built on fundamental wireless communication principles: Signal Strength : The power of the WiFi signal received by your device Noise Floor : The ambient background noise level in the environment SNR Calculation : SNR = Signal Strength - Noise Floor (measured in dB) Standards Compliance The SNR Factor aligns with the IEEE 802.11 standard, incorporating key parameters: BeaconSNR : Signal-to-noise ratio of received Beacon frames DataFrameSNR : Signal-to-noise ratio of received Data frames Implementation Details CONTROL obtains SNR data using the TR-181 parameter: Device.WiFi.AccessPoint.AssociatedDevice.SNR This parameter is defined as: "An indicator of signal to noise ratio, in dB, on the uplink from the associated device to the access point, measured in dB, as an average of the last 100 packets received from the device." SNR Factor Scale CONTROL translates raw SNR measurements into a user-friendly scale ranging from 1 to 10: Rating Quality Level SNR Range (dB) 10 Excellent 35 or higher 9 Very Good 30 to 34 8 Good 25 to 29 7 Fair 20 to 24 6 Marginal 15 to 19 5 Poor 10 to 14 4 Very Poor 5 to 9 3 Unreliable 0 to 4 2 Highly Unreliable -5 to -1 1 No Connection Below -5 Interpreting Your SNR Factor Performance Expectations 10-9 (Excellent) : Optimal connection quality, ideal for high-bandwidth applications such as 4K streaming, video conferencing, and online gaming 8-7 (Good) : Reliable connection suitable for most online activities including HD streaming and general browsing 6-5 (Adequate) : Sufficient for basic tasks like web browsing and email, but may experience issues with bandwidth-intensive applications 4-3 (Poor) : Degraded connection with frequent interruptions, disconnections, and slow data rates 2-1 (Critical) : Severely compromised or unusable connection Why SNR Factor Matters Understanding SNR Factor is essential for several reasons: Connection Quality : Higher SNR values provide clearer signal reception, resulting in superior WiFi performance with fewer errors Dynamic Data Rates : WiFi devices automatically adjust their transmission rates based on SNR—higher SNR enables faster data throughput Network Stability : Strong SNR leads to more stable connections with reduced packet loss and fewer dropouts Effective Range : Improved SNR can extend the practical usable range of your WiFi network Technical Insight: SNR and Modulation Schemes SNR directly influences the Modulation and Coding Scheme (MCS) that your WiFi connection can utilize. Higher SNR values enable more sophisticated modulation schemes, which deliver higher data rates: SNR > 25 dB : Supports 256-QAM modulation (highest data rates) SNR ≈ 20 dB : Typically uses 64-QAM modulation Lower SNR values : Fall back to simpler schemes such as 16-QAM or QPSK for reliability This adaptive behavior ensures your connection remains stable while maximizing throughput based on current conditions. Improving Your SNR Factor Optimization Strategies Consider these approaches to enhance your SNR Factor: Optimize Router Placement : Position your WiFi router centrally and elevated to improve signal strength throughout your space Minimize Distance : Move closer to your WiFi router when maximum performance is needed Reduce Interference : Identify and eliminate sources of noise such as microwaves, cordless phones, and neighboring WiFi networks Channel Optimization : Use a WiFi analyzer tool to identify the least congested channel in your area Expand Coverage : Deploy WiFi extenders or mesh networking systems to improve coverage in weak signal areas Hardware Upgrades : Consider routers with advanced features such as improved antennas, beamforming, or MIMO (Multiple Input Multiple Output) capabilities SNR Factor in Context SNR Factor works in conjunction with other CONTROL metrics to provide a comprehensive assessment of your WiFi network: Signal Factor : Measures raw signal strength Noise Factor : Quantifies environmental noise levels SNR Factor : Combines both metrics to evaluate overall connection quality While strong signal strength is important, maintaining a low noise floor is equally critical for achieving high SNR and optimal WiFi performance. CONTROL analyzes all these factors together to give you a complete picture of your network health. References TR-181 Issue 2 Amendment 15 IEEE 802.11 Standards Standard Factor in WiFi Evaluation Overview Standard Factor is a key metric for evaluating your WiFi network's performance. It measures how effectively your connected devices utilize the WiFi standards (protocols) supported by your router. A higher Standard Factor score indicates that your devices are taking full advantage of the latest available WiFi technologies, ensuring optimal network performance. Technical Foundation Standard Factor is based on WiFi standards defined by the IEEE 802.11 working group. The most common standards include: 802.11b, g – Older 2.4 GHz standards 802.11n – Improved speed and range, operates on both 2.4 GHz and 5 GHz bands 802.11ac – High-speed standard for 5 GHz band 802.11ax (Wi-Fi 6) – Latest standard supporting both 2.4 GHz and 5 GHz bands Measurement Methodology CONTROL evaluates the WiFi standard used by each connected device and compares it to the best standard supported by your router. This assessment is translated into a user-friendly scale ranging from 4 to 10. 2.4 GHz Band Scoring 10 – Device using 802.11n (highest standard for 2.4 GHz) 8 – Device using 802.11g when 802.11n is available on the router 6 – Device using 802.11g, which is the best standard available on the router 4 – Device using older standards or unable to utilize the best available standard 5 GHz Band Scoring 10 – Device using the latest available standard (e.g., 802.11ac or 802.11ax) 8 – Device using 802.11n when a newer standard is available on the router 6 – Device using 802.11n, which is the best standard available on the router 4 – Device using older standards or unable to utilize the best available standard Interpreting Your Standard Factor Score Score 10 – Your devices are using the best WiFi standard available, ensuring optimal performance Score 8 – Good performance with room for improvement through device upgrades Score 6 – Acceptable performance; consider upgrading devices or router for better results Score 4 – Devices are not leveraging your router's full capabilities, potentially limiting WiFi performance Why Standard Factor Matters Understanding your Standard Factor score is important for several reasons: Speed – Newer WiFi standards offer significantly faster data transfer rates Efficiency – Modern standards use more efficient encoding and modulation, delivering better performance even in congested WiFi environments Range – Recent standards provide improved signal range and wall penetration capabilities Future-Proofing – Higher scores indicate your network setup is better prepared for evolving WiFi technologies WiFi Standards and Performance Specifications Different WiFi standards offer varying theoretical maximum speeds: 802.11g – Up to 54 Mbps 802.11n – Up to 600 Mbps 802.11ac – Up to 3.5 Gbps 802.11ax (Wi-Fi 6) – Up to 9.6 Gbps Note: Real-world speeds are typically lower than theoretical maximums due to factors such as distance, interference, number of connected devices, and environmental conditions. Technical Specifications These speed capabilities are based on the following technical specifications: IEEE 802.11g-2003 – Uses OFDM modulation in the 2.4 GHz band with a maximum physical layer bit rate of 54 Mbit/s [1] IEEE 802.11n-2009 – Introduces MIMO technology allowing multiple spatial streams. With 4 streams and 40 MHz channels, achieves up to 600 Mbit/s [2] IEEE 802.11ac-2013 – Operates in the 5 GHz band, uses wider 160 MHz channels, higher-order 256-QAM modulation, and up to 8 MIMO spatial streams for speeds up to 3.5 Gbit/s [3] IEEE 802.11ax-2021 (Wi-Fi 6) – Introduces OFDMA and 1024-QAM modulation. With 160 MHz channels and 8 spatial streams, theoretically achieves up to 9.6 Gbit/s [4] These standards also introduce significant improvements in efficiency and capacity beyond raw speed. For example, 802.11ax is specifically designed to perform better in dense environments with many connected devices. References [1] IEEE Std 802.11g-2003 [2] IEEE Std 802.11n-2009 [3] IEEE Std 802.11ac-2013 [4] IEEE Std 802.11ax-2021 Improving Your Standard Factor Score To optimize your Standard Factor score, consider the following recommendations: Upgrade devices to models that support the latest WiFi standards Update router firmware to ensure you have the latest features and security patches Replace older routers with models supporting newer WiFi standards (802.11ac or 802.11ax) Optimize band usage by using legacy devices on the 2.4 GHz band while reserving 5 GHz for newer devices Standard Factor in Context While Standard Factor is an important metric, it should be evaluated alongside other performance indicators within CONTROL, such as Signal Factor and Interference Factor. A high Standard Factor ensures you're leveraging the best available WiFi technology, but signal strength and interference levels also play crucial roles in determining overall network performance. Standard Factor is one component of a comprehensive WiFi performance assessment. It helps ensure you're taking full advantage of the best technology available for your WiFi connection. SpeedFactor in WiFi Evaluation What is Speed Factor? Speed Factor is a crucial component in evaluating your WiFi network's performance within CONTROL. It measures how well your actual connection speed matches the theoretical maximum speed of your WiFi standard and configuration. A higher Speed Factor indicates that you're getting closer to the full potential of your WiFi setup. Note on Terminology : In this document, we use the terms "speed", "data rate", and "throughput" interchangeably. These all refer to the rate at which data is transmitted over your WiFi connection, which directly impacts the user's experience. While technically "speed" can be misleading as it's often used colloquially, here it's used synonymously with the more accurate terms "data rate" and "throughput". Technical Foundation Speed Factor is based on several technical aspects: WiFi Standards : Each standard (802.11n, 802.11ac, etc.) has different theoretical maximum speeds. Channel Bandwidth : Wider channels (e.g., 40 MHz vs 20 MHz) allow for higher speeds. Actual Data Rates : The real-world upload and download speeds your devices are achieving. How is Speed Factor Measured? CONTROL compares the actual data rates (both uplink and downlink) with the theoretical maximum for your WiFi standard and channel bandwidth using the following process: Step 1: Identify Maximum Theoretical Data Rate The system uses the TR-181 parameter: Device.WiFi.Radio.MaxBitRate : The maximum PHY bit rate supported by this interface (expressed in Mbps ) Step 2: Measure Actual Data Rates The system measures actual uplink and downlink data rates using the TR-181 parameters: Device.WiFi.AccessPoint.{i}.AssociatedDevice.{i}.LastDataDownlinkRate : The data transmit rate in kbps that was most recently used for transmission from the access point to the associated device Device.WiFi.AccessPoint.{i}.AssociatedDevice.{i}.LastDataUplinkRate : The data transmit rate in kbps that was most recently used for transmission from the associated device to the access point Step 3: Calculate Speed Factor Percentage Speed Factor Percentage = (Actual Data Rate / MaxBitRate) × 100 Where Actual Data Rate is the average of LastDataDownlinkRate and LastDataUplinkRate . Step 4: Assign Speed Factor Score Based on the calculated percentage, CONTROL assigns a Speed Factor score: 10 (Excellent) : 80% or more 8 (Very Good) : 60-79% 6 (Good) : 40-59% 4 (Fair) : Less than 40% This comparison between the actual data rates (throughput) and the maximum supported bit rate gives a clear indication of how well your WiFi connection is performing relative to its theoretical capabilities, which translates directly to the speed and quality of the user's experience. Calculation Example Consider the following scenario: MaxBitRate is 1300 Mbps (typical for 802.11ac with 80 MHz channel) LastDataDownlinkRate is 780 Mbps LastDataUplinkRate is 650 Mbps Calculation: Average Actual Speed = (780 + 650) / 2 = 715 Mbps Speed Factor Percentage = (715 / 1300) × 100 ≈ 55% Result : Speed Factor score of 6 (Good) This comparison between the actual speeds and the maximum supported bit rate gives a clear indication of how well your WiFi connection is performing relative to its theoretical capabilities. What Does Your Speed Factor Mean? 10-9 : You're getting the most out of your WiFi setup. Ideal for all applications, including high-bandwidth activities. 8-7 : Very good performance. Suitable for most high-bandwidth applications. 6-5 : Good performance for general use, but might struggle with very demanding applications. 4 : Your speed is significantly below potential. You may experience issues with high-bandwidth applications. Why is Speed Factor Important? Performance Indicator : It shows how well your actual speeds match up to what's theoretically possible. Troubleshooting Tool : A low Speed Factor can indicate issues that need addressing. Value Assessment : It helps you understand if you're getting the full value from your WiFi setup and internet plan. Reference Speeds for WiFi Standards The following table provides typical maximum theoretical speeds for common WiFi standards and configurations: 802.11n (20 MHz channel) : Up to 72 Mbps 802.11n (40 MHz channel) : Up to 150 Mbps 802.11ac (80 MHz channel) : Up to 1300 Mbps 802.11ax (160 MHz channel) : Up to 2400 Mbps Note : These are simplified figures. Actual maximums can vary based on specific configurations and number of spatial streams. References [1] IEEE Std 802.11n-2009 [2] IEEE Std 802.11ac-2013 [3] IEEE Std 802.11ax-2021 How Can You Improve Your Speed Factor? To optimize your Speed Factor score, consider the following recommendations: Ensure you're using the latest WiFi standards supported by your router Use wider channel bandwidths when possible (e.g., 40 MHz instead of 20 MHz) Reduce interference from other devices and networks Position your router for optimal coverage Consider upgrading your router or internet plan if you consistently get low scores Speed Factor in Context While Speed Factor is important, it works in conjunction with other metrics like Signal Factor and Interference Factor within CONTROL. A high Speed Factor indicates that you're efficiently using your WiFi technology, but factors like signal strength and interference also play crucial roles in overall performance. Remember, Speed Factor helps you understand if you're getting the speeds you should be getting based on your WiFi setup. It's a key indicator of your WiFi efficiency and performance. Understanding Your WiFi Device Score Overview Your device's WiFi Experience Score provides a comprehensive assessment of your wireless connection quality. The score is calculated using six key performance factors, each weighted according to its impact on your overall WiFi experience. The final score ranges from 1 to 10 , with higher values indicating superior WiFi performance. Scoring Factors and Weights Each factor contributes differently to your overall score based on its importance in determining connection quality: Factor Weight Description Interference 0.30 The most critical factor affecting WiFi performance. Interference directly impacts both the quality and stability of your wireless connection. Signal Strength 0.20 Essential for maintaining a stable, high-speed connection. Signal strength determines the effective range and reliability of your WiFi coverage. SNR (Signal-to-Noise Ratio) 0.15 Measures signal clarity relative to background noise. A higher SNR is crucial for maintaining consistent connection quality. Speed 0.15 Particularly important for user satisfaction when using high-bandwidth applications such as video streaming, gaming, or large file transfers. Noise 0.10 Background noise degrades signal quality. Note that noise impact is partially accounted for in the SNR calculation. Standard 0.10 The WiFi standard (e.g., 802.11ac, 802.11ax) determines the theoretical maximum capabilities and influences potential performance levels. How the Score is Calculated The weighting system prioritizes factors that have direct, measurable effects on connection stability and quality over theoretical maximum capabilities. Your device's final WiFi Experience Score is calculated by: Evaluating each of the six factors listed above Applying the corresponding weight to each factor's measurement Combining all weighted factors into a single composite score Normalizing the result to a scale of 1-10 This methodology ensures that real-world performance indicators have greater influence on your score than theoretical specifications alone. The final score for each device results in a value between 1 and 10, where higher scores indicate better WiFi experience. WiFi Optimization System Overview The WiFi Optimization System analyzes and optimizes wireless network performance by evaluating channel usage, bandwidth efficiency, device connectivity, and transmit power levels. The system delivers comprehensive recommendations for optimal network settings, device placement, and configuration adjustments to enhance overall network performance. Key Components Channel Evaluation Functions: calculate_channel_score and find_best_channel These functions assess WiFi channels across both 2.4GHz and 5GHz frequency bands: calculate_channel_score — Evaluates each channel based on interference from neighboring networks 2.4GHz band: Considers overlapping channels within a 4-channel range 5GHz band: Focuses on co-channel interference and adjacent channel interference find_best_channel — Iterates through available channels to identify the option with the least interference Bandwidth Optimization Function: evaluate_bandwidth This function recommends optimal channel bandwidth based on current interference levels: High interference (factor ≥ 8): Suggests wider bandwidth for increased throughput Moderate interference (6 ≤ factor < 8): Maintains current bandwidth settings Low interference (factor < 6): Recommends narrower bandwidth to reduce overlap Device-Specific Analysis Function: calculate_weighted_score This function performs comprehensive analysis of each connected device: Calculates a normalized score (1-10) based on multiple factors including: Interference levels Signal strength Signal-to-Noise Ratio (SNR) Connection speed Noise levels WiFi standard compatibility Generates device-specific recommendations based on the analysis results Recommendation Types The system provides six categories of optimization recommendations: 1. Channel Change Suggests migrating to a less congested channel for improved performance. Example: "Change channel to 1 for better performance" 2. Bandwidth Adjustment Recommends optimal bandwidth settings based on current interference levels. Example: "Change bandwidth to 40MHz for optimal performance" 3. Band Switching Advises switching between 2.4GHz and 5GHz bands based on device capabilities and signal conditions: 2.4GHz devices with excellent signal: Suggests switching to 5GHz for better performance 5GHz devices with poor signal: Recommends switching to 2.4GHz for better coverage Examples: "Consider switching to 5GHz band for better performance, if supported by your device" "If device is far from router, consider switching to 2.4GHz band for better coverage" 4. Signal Improvement Suggests deploying WiFi extenders for devices experiencing consistently weak signals. Example: "Consider using a WiFi extender to improve signal strength" 5. Wired Connection Recommends Ethernet connections for devices with poor wireless performance. Example: "Consider using Ethernet connection for better stability and performance" 6. Transmit Power Adjustment Optimizes router transmit power based on device signal conditions: Weak signals: Increase transmit power to improve coverage Very strong signals: Decrease transmit power to reduce interference Examples: "Increase transmit power to improve signal strength. Current: 40, Max supported: 100" "Consider decreasing transmit power to reduce interference. Current: 100, Min supported: 20" Optimization Mechanisms The system employs six core optimization strategies: 1. Intelligent Channel Selection Minimizes co-channel and adjacent channel interference Selects channels with the least impact from neighboring networks 2. Dynamic Bandwidth Adjustment Balances throughput potential against interference mitigation Recommends wider bandwidths in low-interference environments for higher speeds Suggests narrower bandwidths in high-interference scenarios for stability 3. Adaptive Band Steering Guides devices to the most appropriate frequency band based on their capabilities and current signal conditions 4. Transmit Power Optimization Adjusts transmit power to balance signal strength against potential interference with neighboring networks 5. Network Load Balancing Advises on distributing devices between 2.4GHz and 5GHz bands based on their physical location and usage patterns 6. Alternative Connection Methods Suggests WiFi extenders or Ethernet connections when wireless optimization alone proves insufficient Implementation Details Scoring System The system uses a scoring mechanism where higher scores indicate better conditions (less interference, stronger signal, better performance). Real-Time Analysis Recommendations are based on real-time analysis of the network environment and connected devices, ensuring current and relevant suggestions. Non-Intrusive Operation The optimization process provides suggestions without automatically changing router or device settings, leaving control in the hands of the network administrator. User Interface A tooltip system displays the number of recommendations for each device, with detailed recommendations shown on hover for easy review. Summary The WiFi Optimization System provides a comprehensive approach to enhancing wireless network performance. By analyzing channel interference, signal strength, bandwidth usage, and device capabilities, it delivers tailored recommendations to improve overall network efficiency and user experience. The system's adaptability to different network environments and device-specific issues makes it an essential tool for maintaining optimal WiFi performance in CONTROL. WiFi Analytics Configuration Guide Introduction WiFi Analytics is a built-in diagnostic feature of the CONTROL ACS platform that evaluates the quality of a CPE's WiFi network. After triggering a neighboring-WiFi scan from the device's Diagnostics tab, the engine collects radio, client, and neighbor data from the CPE and produces a structured score report. The evaluation covers six quality factors: Signal , Noise , SNR , Interference , Standard , and Speed . Each factor is scored on a scale of 1–10 and then combined into a single Overall Score using configurable weights. This lets you tune the scoring model to reflect the conditions of your own network — for example, increasing the Interference weight for dense urban deployments. The engine supports both TR-181 and TR-098 CPEs. For standard TR-181 devices with sequential radio indexes, the engine can auto-discover the radio configuration without any additional setup. For TR-098 or vendor-specific devices with non-standard parameter paths, an explicit Service configuration is required to supply the correct path templates and JSON key names. Prerequisites Before configuring WiFi Analytics, ensure the following conditions are met: Requirement Details Managed CPE The device must be connected to CONTROL and actively reporting via TR-069/CWMP. WiFi parameters in device Type The Type profile must include parameters for periodic collection: Channel, OperatingFrequencyBand, AssociatedDevice tables, Noise, TX power, and supported standards. ServiceType 23 present The "CWMP WIFI Neighbor test" ServiceType must exist in CONTROL Settings. This is included in the default platform fixtures and should already be present. Note: If ServiceType 23 is missing, contact your platform administrator to load the WiFi Analytics fixtures. Configuration Steps Step 1: Create a Service for WiFi Analytics A Service instance of ServiceType 23 holds all the configuration that tells the engine how to map radio and client parameters for a specific device model. Navigate to Settings > Services > Add Set the Service Type field to CWMP WIFI Neighbor test (ServiceType 23) Give it a descriptive name, for example: WiFi Diagnostic Score - Model XYZ Check Active and Public Save the Service After saving, the Service will display four parameter groups: Parameter Group Purpose 2.4 GHz Band Configuration Radio and client configuration for the 2.4 GHz band 5 GHz Band Configuration Radio and client configuration for the 5 GHz band 6 GHz Band Configuration Radio and client configuration for the 6 GHz band Score Weights Relative importance of each quality factor (must sum to 100%) Configure only the bands that are relevant to the device model. Bands that are left disabled are excluded from scoring. Step 2: Configure Band Parameters Each band group (2.4 GHz, 5 GHz, 6 GHz) contains the same set of fields. Repeat this configuration for every band the device supports. Band Enable and Index Fields Field Description Enabled Enable or disable analysis for this band. Disabled bands are ignored entirely. Radio index The value substituted for the {i} placeholder at runtime. For TR-181, this is the Device.WiFi.Radio.{i} object index (e.g., 1 for 2.4 GHz, 2 for 5 GHz). For TR-098, this is the WLANConfiguration index. SSID indexes Comma-separated list of SSID object indexes to read SSID-level data from. AP indexes Comma-separated list of AccessPoint object indexes. These are iterated when collecting connected-client data. Important: The {i} placeholder is the only token substituted by the engine. All other numbers in path templates (e.g., LANDevice.1 ) are treated as literal strings and are never modified. Variable Override Fields These fields allow you to supply explicit TR-181 or TR-098 parameter paths. Leave them blank for standard TR-181 devices — the engine uses the correct Device.WiFi.* defaults automatically. For TR-098 or vendor-specific devices, enter the full path template using {i} where the radio index should appear. Field TR-181 default (auto) TR-098 example Channel Device.WiFi.Radio.{i}.Channel InternetGatewayDevice.LANDevice.1.WLANConfiguration.{i}.Channel Possible channels Device.WiFi.Radio.{i}.PossibleChannels InternetGatewayDevice.LANDevice.1.WLANConfiguration.{i}.PossibleChannels Radio noise Device.WiFi.Radio.{i}.Stats.Noise InternetGatewayDevice.LANDevice.1.WLANConfiguration.{i}.Stats.Noise Bandwidth Device.WiFi.Radio.{i}.CurrentOperatingChannelBandwidth Supply vendor-specific path Standards Device.WiFi.Radio.{i}.OperatingStandards InternetGatewayDevice.LANDevice.1.WLANConfiguration.{i}.Standard TX power Device.WiFi.Radio.{i}.TransmitPower Supply vendor-specific path Client Field Override Fields These fields specify the JSON key names used to read per-client metrics from the AssociatedDevice table entries. These are short key names, not full parameter paths . Leave them blank for standard TR-181 devices. For TR-098 or vendor devices, enter the vendor-specific key name. Field TR-181 default Vendor example Noise field Noise X_ALCATEL_Noise SNR field (auto-calculated) X_ALU-COM_SNR Signal field SignalStrength X_VENDOR_RSSI Downlink rate LastDataDownlinkRate — Uplink rate LastDataUplinkRate — Standard field OperatingStandard — Clients Table Path and Active Filter Field Description Clients table path Template path for the AssociatedDevice table. Leave blank for TR-181 default. TR-098 example: InternetGatewayDevice.LANDevice.1.WLANConfiguration.{i}.AssociatedDevice. Active field JSON key for active-client filtering. Default: Active . Leave blank to skip filtering. Hosts table path LAN Hosts table for MAC-based cross-reference when AssociatedDevice.Active is unreliable. Step 3: Configure Score Weights The Score Weights parameter group controls how much each quality factor contributes to the Overall Score. The six weights must add up to 100% . Quality Factor Default Weight What it measures Signal 24% Client signal strength (RSSI in dBm) Noise 19% Background noise level on the radio channel SNR 4% Signal-to-noise ratio per client Standard 14% WiFi standard in use (802.11n, ac, ax, etc.) Speed 9% Per-client uplink and downlink rates Interference 30% Neighboring network congestion on the channel Adjust these values to match your deployment environment. For example, increase Interference weight to 40–50% for dense urban areas, or increase Signal weight if coverage is the primary concern. Step 4: Create a Test Profile A Test Profile links the Service to a device Type, so the engine knows which Service configuration to use when running a diagnostic. Navigate to Userx > Profiles > Add Give it a descriptive name (e.g., WiFi Analytics — Model XYZ ) Check Is active In the Locations, tests and limits settings section, add the Service created in Step 1 to the Test services field Save the Test Profile Step 5: Assign the Test Profile to a Device Type Navigate to Inventory > Profiles and select the device Type for the target CPE model Locate the Automatic tests profile field Select the Test Profile created in Step 4 Save the Type From this point on, any device of this Type will use the configured Service when a WiFi diagnostic is run. Running the WiFi Diagnostic Navigate to the target device's Diagnostics tab From the Operation dropdown, select WiFi neighbor diagnostics The Parameter name field defaults to .WiFi.NeighboringWiFiDiagnostic . The engine automatically prefixes this with Device. for TR-181 or InternetGatewayDevice. for TR-098 Click Proceed Wait for the CPE to scan neighboring networks (typically 10–30 seconds ) Understanding the Results Once the diagnostic completes, a WiFi Analytics mini-dashboard appears below the form. Header Summary Element Description Bands Number of active bands analyzed Clients Total WiFi clients across all bands Overall Weighted average score as a colored badge (Green ≥8, Yellow ≥5, Red <5, Gray = N/A) Band Cards Each band displays its current channel, bandwidth, connected client count, a score progress bar, and a quality label (Excellent / Fair / Poor). Recommendations and Tips Recommendations (yellow accent): Channel changes, bandwidth suggestions, or "No issues" when optimal Tips (blue accent): Missing parameters, discovery suggestions, or vendor contact recommendations No clients : When no WiFi clients are connected, Overall shows N/A with an info message How the Overall Score is Calculated The Overall Score is a weighted average of all available factor scores across all bands: Each client's 6 factors are scored individually Factors with N/A are excluded; remaining weights are renormalized to sum to 100% The weighted average produces a per-client score (1–10) All client scores within a band are averaged to produce the band score All band scores are averaged to produce the Overall Score The default weight distribution emphasizes Interference (30%) and Signal (24%) as the highest-impact factors for typical residential WiFi environments. Quality Factors — Detailed Breakdown Below each band card, six horizontal bars show the individual factor scores. Each factor is scored 1–10 based on specific inputs from the CPE. When a factor cannot be calculated, it shows N/A and its weight is redistributed proportionally across the remaining factors. Signal Factor Measures the received signal strength (RSSI) of each connected WiFi client. Input: SignalStrength from the AssociatedDevice table (or the vendor-specific JSON key configured in the Service). Signal strength (dBm) Score ≥ −50 10 (Excellent) ≥ −60 9 ≥ −70 8 ≥ −80 7 ≥ −90 6 < −90 4 (Poor) The final Signal score for the band is the average across all connected clients. Noise Factor Measures the background noise floor on the radio channel. Input: Per-client Noise field from AssociatedDevice, or fallback to Device.WiFi.Radio.{i}.Stats.Noise (radio-level noise). Noise level (dBm) Score < −90 10 (Very quiet) < −80 8 < −70 6 ≥ −70 4 (Noisy) Lower noise is better — a value below −90 dBm indicates a very clean radio environment. SNR Factor (Signal-to-Noise Ratio) Measures the gap between signal and noise for each client. Higher SNR means clearer communication. Input: Either a vendor-specific SNR field (e.g., X_ALU-COM_SNR ) or auto-calculated as SignalStrength − Noise when no dedicated SNR field is available. SNR (dB) Score ≥ 35 10 ≥ 30 9 ≥ 25 8 ≥ 20 7 ≥ 15 6 ≥ 10 5 ≥ 5 4 ≥ 0 3 ≥ −5 2 < −5 1 Interference Factor Evaluates how much congestion the CPE experiences from neighboring WiFi networks on the same or adjacent channels. Inputs: Device.WiFi.Radio.{i}.Channel — the CPE's current operating channel Device.WiFi.Radio.{i}.CurrentOperatingChannelBandwidth — channel width (affects adjacency range) Neighboring networks — the full list of detected WiFi neighbors from the NeighboringWiFiDiagnostic scan How neighbors are scored: Each detected neighbor contributes to a raw interference accumulator based on two criteria: whether it is on the same channel or an adjacent channel , and its signal strength : Neighbor position Strong signal (≥ −60 dBm) Medium (≥ −80 dBm) Weak (< −80 dBm) Same channel +5.0 +3.0 +1.0 Adjacent channel +2.5 × proximity +1.5 × proximity +0.5 × proximity Non-overlapping 0 0 0 Proximity is a value between 0 and 1 based on how close the neighbor's channel is within the adjacency range Adjacency range depends on the CPE's channel bandwidth: 20 MHz covers ~4 channels, 40 MHz covers ~8, 80 MHz covers ~16, 160 MHz covers ~32 (for 5 GHz / 6 GHz) A bandwidth multiplier is applied to the accumulated raw score based on the CPE's own bandwidth (40 MHz ×1.5, 80 MHz ×2, 160 MHz ×3) The raw accumulator is then mapped to a score: Raw interference Score 0 (no neighbors on channel) 10 ≤ 10 8 ≤ 20 6 ≤ 30 4 > 30 1 (Severe congestion) N/A condition: If the CPE's Channel parameter is missing from DeviceSettings, the engine cannot determine which neighbors overlap — the Interference factor shows N/A. Standard Factor Evaluates the WiFi standard (protocol generation) used by the CPE's radio. Input: Device.WiFi.Radio.{i}.OperatingStandards — the active standard(s) for this radio. The score depends on the band: 2.4 GHz band: Standard Score WiFi 7 (be) / WiFi 6 (ax) 10 WiFi 4 (n) 8 WiFi 3 (g) 6 WiFi 1 (b) 4 5 GHz band: Standard Score WiFi 7 (be) / WiFi 6 (ax) 10 WiFi 5 (ac) 8 WiFi 4 (n) 6 WiFi 2 (a) 4 Newer standards support higher throughput, better modulation, and features like OFDMA and MU-MIMO, which directly improve network quality. Speed Factor Measures actual throughput as a percentage of the theoretical maximum for the current standard and bandwidth combination. Inputs: LastDataDownlinkRate and LastDataUplinkRate from each client (in kbps) OperatingStandards and CurrentOperatingChannelBandwidth from the radio The engine calculates: average_speed = (downlink + uplink) / 2 , then compares it against a reference throughput table: Standard 20 MHz 40 MHz 80 MHz 160 MHz n 300 Mbps 600 Mbps — — ac 437 Mbps 875 Mbps 1750 Mbps 3500 Mbps ax 574 Mbps 1148 Mbps 2402 Mbps 4804 Mbps be 690 Mbps 1380 Mbps 2880 Mbps 5760 Mbps Actual / Max ratio Score ≥ 80% 10 ≥ 60% 8 ≥ 40% 6 < 40% 4 N/A condition: If downlink or uplink rate data is missing for all clients, Speed shows N/A. Additional Notes Without a Service/TestProfile , the system auto-discovers radios from DeviceSettings (works for standard TR-181 CPEs with sequential indexes 1, 2) For TR-098 or vendor-specific CPEs , explicit Service configuration is required Score weights are per-Service — you can create multiple Services with different weight profiles for different environments The {i} placeholder is the only substitution the engine performs. All other numbers in paths are literal TR-098 Quick Reference Field Example value Radio index 1 AP indexes 1 Clients table path InternetGatewayDevice.LANDevice.1.WLANConfiguration.{i}.AssociatedDevice. Channel override InternetGatewayDevice.LANDevice.1.WLANConfiguration.{i}.Channel Noise override InternetGatewayDevice.LANDevice.1.WLANConfiguration.{i}.Stats.Noise Hosts table path InternetGatewayDevice.LANDevice.1.Hosts.Host. SNR client field X_ALU-COM_SNR (vendor-specific) React Components React component Overview The Radar Score component displays a clickable icon that opens a modal window containing a radar chart visualization. This component is useful for presenting multi-dimensional score data in an interactive format. Visual Examples Icon Display: Modal with Radar Chart: When the icon is clicked, a modal opens displaying the radar chart with the configured data. Component Syntax Parameters paramid (String): Unique identifier for the radar-score element score (Integer): Total score value displayed on the icon and in the modal labels (String): Comma-separated list of labels for the chart axes data (String): Comma-separated list of numerical values corresponding to each label Usage Example In this example: The icon displays a score of 8 Six data points are plotted on the radar chart Each value in the data parameter corresponds to a label in the labels parameter Dashboard: Main Overview The Zequenze CONTROL Portal Dashboard provides a comprehensive real-time overview of device management and monitoring capabilities. This main dashboard serves as the central hub for administrators to monitor device status, track performance metrics, and access various system management tools. Key Features Real-Time Device Monitoring Devices Up Chart : Visual bar chart showing device availability over a 24-hour period Device Logs Graph : Line chart displaying device activity and log patterns over time Devices Per Status : Pie chart visualization showing the distribution of device statuses Live Device Count : Real-time counter showing total devices (178) Navigation & Access Control Left sidebar navigation with organized menu structure User profile display (ipenaa@zequenze.com) with Zequenze organization access Language selection (EN) and theme toggle options Auto-refresh functionality with manual override controls UI Elements Dashboard Widgets Devices Up Widget : Green bar chart showing consistent values with 4 devices up at early time periods and 7 devices up across most time periods, displaying data points from Feb 13 2:00 am through Feb 13 11:00 pm Device Logs Widget : Blue line graph showing activity patterns spanning from Feb 12 6:00 pm through Feb 14 4:00 pm, with significant spikes reaching approximately 1.0 events around Feb 12 8:00 pm and Feb 13 8:00 pm Devices Per Status Widget : Donut chart with prominent red section showing 171 devices and a small green section Device Counter : Large numeric display (178) with refresh icon Navigation Sidebar Control Section : Dashboard (currently active) Applications Menu : Inventory Firmware Portals Locations Files Organization Settings User log Top Navigation Home and Dashboard breadcrumb navigation Auto-refresh toggle (currently set to "Auto: off") User account display in top-right corner showing "ipenaa@zequenze.com" with organization "Zequenze" User Interactions Widget Controls Time Range Selection : 24-hour view with dropdown options Data Export : CSV export functionality available for all widgets Chart Type Toggle : Line view option available for Device Logs widget Chart View Options : Doughnut view selection available for Devices Per Status widget Refresh Controls : Manual refresh and auto-refresh settings Navigation Click on sidebar menu items to access different portal sections Expandable menu sections indicated by arrow icons Breadcrumb navigation for easy page tracking Navigation Access Path URL : https://control-dev.zequenze.com/admin/ Primary Navigation : MAIN > Home > Dashboard User Level : Zequenze organization access required Related Sections Users can navigate to specialized management areas through the sidebar: Device management via Inventory System configuration through Settings and Organization Monitoring and logging via User log sections Data Displayed Performance Metrics Device Uptime : Consistent availability (7 devices up for most time periods, with 4 devices up at earlier time periods) Activity Patterns : Device logs show significant spikes around Feb 12 8:00 pm and Feb 13 8:00 pm reaching approximately 1.0 events, with minimal activity levels maintained throughout the rest of the monitoring period Status Distribution : Small-scale deployment (178 total devices) Time Series Data : Extended time window showing daily patterns with hourly granularity System Information Total Devices : 178 managed devices Active Monitoring : Real-time status tracking Historical Data : Time-based trend analysis showing daily patterns Status Categories : Multiple device states tracked in pie chart with 171 devices in the primary status category and a small number in a secondary status Actions Available Dashboard Management Export Data : Download CSV reports for all widgets Refresh Data : Manual or automatic data updates Time Range Adjustment : Modify monitoring time windows Chart View Customization : Toggle between different chart types (Line view for Device Logs, Doughnut view for status charts) System Navigation Quick Access : Direct links to all major system functions Configuration : System settings and organizational controls Monitoring : Real-time and historical data analysis Notes/Tips Best Practices Monitor the "Devices Up" chart for consistent availability patterns Use the Device Logs graph to identify unusual activity spikes or anomalies such as the significant spikes observed around Feb 12 8:00 pm and Feb 13 8:00 pm Export data regularly for compliance and reporting purposes Enable auto-refresh for real-time monitoring scenarios Utilize chart view options (Line view toggle, Doughnut view) for optimal data visualization Performance Considerations The dashboard displays data for 178 devices, indicating small to medium-scale deployment Time-series data updates hourly for optimal performance CSV export functionality available for detailed analysis Dashboard widgets are optimized for real-time updates Access Requirements Zequenze organization privileges required for full dashboard access Development environment URL suggests testing/staging deployment User authentication via email-based accounts (ipenaa@zequenze.com shown) Devices Overview The Device Inventory page in the Zequenze CONTROL Portal provides a comprehensive view of all managed devices across your network infrastructure. This centralized interface displays device status, configuration details, and organizational hierarchy in both tabular and map-based views. Key Features Dual View Options : Toggle between Basic table view and Status map view for different perspectives on device data Interactive Map : Geographic visualization showing device locations with status indicators Real-time Status Monitoring : Live status updates for all devices with color-coded indicators Advanced Filtering : Multi-criteria filtering system for refined device searches Bulk Operations : Import/export capabilities and bulk device management Hierarchical Organization : View devices organized by sub-organizations and groups UI Elements Top Navigation Bar Device Selection Dropdown : "SELECT DEVICE TO CHANGE" allows switching between managed devices Breadcrumb Navigation : Home > Inventory > Devices path for easy navigation User Account : Displays logged-in user (jpenaa@zequenze.com) with organization assignment Main Content Area View Toggle Tabs : Switch between "Basic" (table view) and "Status map" (geographic view) Search Bar : Global search functionality across all device attributes Action Buttons : Import devices Export data Reports Add new devices Bulk delete (X button) Interactive Map View Geographic Display : Shows device locations across multiple continents including North America, Africa, and the Middle East Location Markers : Red markers indicating device positions with visible markers in Mexico and Nigeria regions Map Controls : Zoom in/out buttons Style selector (emerald-v8 theme) Reset button for map view Fullscreen toggle Device Data Table Displays comprehensive device information in columns: Name : Device identifier with clickable links Status : Real-time operational status (Up/Down with color indicators) Profile : Device configuration profile type (Mikrotik RouterOS, ZG9V9-Zequenze ONT, Dual radio WiFi AP, etc.) Serial : Hardware serial numbers SW Version : Current software/firmware version Child Devices : Count of subordinate devices (showing "-" for no child devices) Organization : Organizational assignment (Zequenze) Right Panel Filters The filter panel is now expanded on the right side of the interface, displaying comprehensive filtering options: Filter Header : Shows "FILTER" with a counter badge (0) and a close button (×) to collapse the panel Proceed Button : Prominent blue "Proceed" button at the top for applying selected filters Filter Sections : Active filters : Displays "5 Hidden" with a "Proceed" button for managing hidden filter criteria Active alert : Dropdown menu set to "Any or no date/time" for filtering by alert status Records per page : Dropdown selector set to "50 records" for pagination control Childs : Multi-select dropdown with "Click for options" placeholder Status : Dropdown filter set to "All" for device status filtering Profile : Multi-select dropdown with "Click for options" placeholder for filtering by device profile Device class : Multi-select dropdown with "Click for options" placeholder Organization : Multi-select dropdown with "Click for options" placeholder and "Sub-organizations" checkbox below Action Button : Blue "Proceed" button at the bottom of the filter panel for applying all selected filters User Interactions Primary Actions Device Selection : Click on device names to view detailed configuration Status Monitoring : Visual status indicators provide immediate operational overview Search and Filter : Use search bar and expanded filter panel for targeted device discovery Map Navigation : Interact with geographic map to locate devices spatially, with zoom and fullscreen capabilities Bulk Operations : Select multiple devices for group actions Map Interactions Zoom Controls : Use + and - buttons to adjust map zoom level Style Selection : Change map appearance using the style dropdown Reset View : Return to default map positioning Fullscreen Mode : Toggle fullscreen display for better map visibility Filter Interactions Expanded Filter Panel : The filter panel is currently expanded, showing comprehensive filtering options: Filter Toggle : Click the close button (×) in the header to collapse the filter panel Filter Counter : The badge shows "0" indicating no active filters are currently applied to the visible filter options Hidden Filters : "5 Hidden" indicator shows additional filter criteria that are currently hidden from view Active Alert Filtering : Select date/time criteria for filtering devices by active alerts Pagination Control : Adjust the number of records displayed per page (currently set to 50 records) Multi-criteria Filtering : Use dropdown menus to filter by Childs, Status, Profile, Device class, and Organization Sub-organization Option : Enable checkbox to include sub-organizations in the organization filter Proceed Action : Click the blue "Proceed" button (available at both top and bottom of panel) to apply selected filters Panel Management : Click the close button (×) to collapse the filter panel and maximize table viewing area Secondary Actions Data Export : Export filtered device lists for external analysis Report Generation : Create custom reports based on current view Device Import : Bulk device addition via import functionality Navigation Access Path Primary: Admin Portal → Inventory → Devices Direct URL: https://control-dev.zequenze.com/admin/inventory/device/ Related Sections Dashboard : Return to main overview Settings : Device configuration management Profiles : Device profile management Groups : Device grouping and organization Data Displayed Device Information Operational Status : Real-time up/down status with visual indicators (showing mix of Up and Down devices) Hardware Details : Serial numbers (HCQ08DN739Q, ZTEGD8854D31, ZTEGD8831103, etc.), device models, firmware versions Network Configuration : Profile assignments (Mikrotik RouterOS, ZG9V9-Zequenze ONT, OpenWRT based dual radio WiFi access point, etc.) and network parameters Organizational Structure : Parent-child relationships and organizational assignments (Zequenze organization) Status Indicators 🔴 Red Circle : Device is down or unreachable (visible on multiple devices including ZTEGD8854D31, ZTEGD8831103, etc.) 🟢 Green Circle : Device is operational and responsive (visible on E4RDBCHCQ08DN739Q device) Blue Links : Clickable elements for detailed views Actions Available Individual Device Actions View Details : Click device name for comprehensive device information Status Monitoring : Real-time operational status tracking Profile Management : View and modify device configuration profiles Bulk Operations Multi-device Selection : Select multiple devices for group operations Data Export : Export device lists in various formats Import New Devices : Bulk device addition and configuration Report Generation : Create custom reports based on filtered data Administrative Functions Add New Device : Manual device addition and configuration Delete Devices : Remove devices from management (bulk delete available) Expanded Filter Management : The expanded filter panel provides comprehensive filtering capabilities: Quick Access : Two "Proceed" buttons (top and bottom of panel) for immediate filter application Filter Status : The counter badge (0) shows the number of visible active filters, with "5 Hidden" indicating additional hidden filter criteria Multi-criteria Selection : Filter by Active alert (date/time), Status (All/Up/Down), Profile types, Device class, Child devices, and Organization Pagination Control : Adjust records per page (50 records default) for optimal table viewing Hierarchical Filtering : Enable "Sub-organizations" checkbox to include sub-organization devices in results Panel Collapse : Use the close button (×) to collapse the panel and maximize device table space Hidden Filters : Access to 5 additional hidden filter criteria through the "5 Hidden" section at the top Notes/Tips Status Colors : Red indicators require immediate attention; green indicates normal operation Pagination : Navigate through 175 total results using pagination controls at the bottom of the table Map View : Switch to Status map tab for geographic device distribution visualization with full interactive capabilities across global locations Filter Panel : The filter panel is expanded, showing comprehensive filtering options including Active alert, Records per page, Status, Profile, Device class, Organization, and Childs filters Filter Status : The badge counter (0) indicates no visible active filters, while "5 Hidden" shows additional filter criteria available Pagination Control : Adjust the "Records per page" setting to view more or fewer devices per page (currently set to 50 records) Real-time Updates : Page displays live status information; refresh periodically for latest data Map Navigation : Use fullscreen mode for detailed geographic analysis of device distribution across continents Device Types : The inventory includes RouterOS devices, ONT devices, WiFi Access Points, and various network appliances with different software versions Filter Application : Click the "Proceed" button (available at top and bottom of filter panel) to apply your selected filter criteria Device Settings View Overview The Device Details page in the CONTROL admin portal provides comprehensive information and management capabilities for individual IoT devices. This page displays device identification, hardware specifications, system metrics, and various configuration profiles for the Linksys WRT1900ACS router (Device ID: 149182-WRT1900ACS-18E10604600470). Key Features Real-time Device Monitoring : Track device connectivity status, CPU usage, and uptime metrics Device Information Management : View and edit detailed device specifications including OS version, hardware details, and model information Multi-Profile Configuration : Access and manage various connection and communication profiles (WAN, MQTT, WiFi) Historical Data Visualization : Interactive charts displaying CPU usage trends and uptime history over 24-hour periods Diagnostic Tools : Download diagnostic files and access device logs for troubleshooting Navigation Accessing the Device Details Page Navigate from Home → Inventory → Devices Select the specific device from the inventory list The device details page opens with the device identifier in the header Breadcrumb Navigation Home > Inventory > Devices > [Device ID] Device group indicator: OBU/SPA LISD/MQTT (pap) Device Status Bar Located at the top of the page, displaying critical status information: Last connection : 4 seconds ago (with timestamp indicator) Status change : 20 hours ago (with timestamp indicator) Alert : Inactive status indicator Action Buttons : History (with notification badge) Refresh : Update device information Update : Apply configuration changes Main Navigation Tabs The page includes six primary tabs for device management: Settings : Device configuration and parameters Setup : Initial device setup and onboarding Diagnostics : Troubleshooting and system analysis Combined logs : Aggregated log viewing Logs : Individual log file access CLI : Command-line interface access Device Information Section 1. DeviceInfo General [USP] This expandable section displays core device specifications: Field Value Description OS prplOS 4.2.0-29358b5d r9021323585b54e8 Operating system version and build Model:DeviceInfo.SerialNumber SN14918288A789 Unique device serial number Model:DeviceInfo.HardwareVersion mvebu/cortexa9 Hardware platform identifier Model:DeviceInfo.Manufacturer linksys Device manufacturer name Model:DeviceInfo.ManufacturerOUI 149182 Organizationally Unique Identifier Model:DeviceInfo.ModelName Linksys WRT1900ACS Commercial product name Model:DeviceInfo.ProductClass wrt1900acs Product classification code Model:SoftwareVersion 4.2.0-29358b5d Current firmware version Each field includes an ellipsis menu (⋯) for additional actions. Performance Metrics CPU Usage Monitor Visual Display: Real-time CPU usage percentage (currently showing 7%) Color-coded severity scale: Normal : 0-17.6% (Green/Blue) 17.6-34.2% : Light monitoring 34.2-51.8% : Elevated usage Warning : 68.6-85.4% (Yellow) Error : 77.4% (Orange) Critical : 86.2-99.0% (Red) Chart Features: Time Range : 24-hour view (selectable) Area Visualization : Line chart with shaded area Interactive Timeline : Hover for specific data points Peak Analysis : Shows historical spike around Feb 12 8:00 pm Export Options : CSV download available View Controls : Area selector dropdown Timeline Display: X-axis: Time stamps from Feb 12 6:00 pm through Feb 14 4:00 pm Y-axis: Percentage scale (0-100%) Current state: Low stable usage (~7%) after initial spike Uptime Tracking Visual Display: Current Uptime : 0 day(s), 21 hour(s), 27 minute(s), 27 second(s) Cumulative uptime graph showing device availability Chart Features: Time Range : 24-hour view (selectable) Line Graph : Steadily increasing line representing continuous uptime Current Reading : Approximately 60K seconds (displayed on Y-axis) Timeline : Same period as CPU usage (Feb 12-14) Export Options : CSV download and additional options menu View Controls : Line visualization with customizable time range Scale Information: Y-axis: Time in seconds (20K, 40K, 60K, 80K increments) X-axis: Synchronized with CPU usage timeline Configuration Profiles The page provides access to multiple expandable profile sections: 2. WAN Connection [USP] Network connectivity configuration for Wide Area Network settings 2. MQTTClientCon:1 Profile [USP] MQTT client connection profile for IoT messaging protocols 3. MQTTClientSubscribe:1 Profile [USP] MQTT subscription topics and message handling configuration 4. MQTTAgent:1 Profile [USP] MQTT agent settings for message broker communication 5. MQTTController:1 Profile [USP] MQTT controller configuration for device management 6. WiFi 2.4GHz:1 Profile [USP] 2.4 GHz wireless network configuration settings 7. WiFi 5.0GHz [USP] 5.0 GHz wireless network configuration settings Each profile section can be expanded by clicking the chevron icon (∨) to reveal detailed configuration parameters. Diagnostic Tools Diagnostic - Download [TR-069] Expandable section providing access to TR-069 protocol diagnostic files for advanced troubleshooting and device analysis. Testing Group Dedicated section for device testing and validation procedures, accessible through the expandable panel at the bottom of the page. Actions Available Primary Actions (Bottom Action Bar) 💾 Save : Commit changes to device configuration 🗑️ Delete : Remove device from inventory ✕ Close : Exit without saving changes 💾 Save and close : Save changes and return to inventory 💾 Save and add another : Save current device and create new device entry Secondary Actions 🔄 Update : Manual firmware or configuration update (top right) Off Toggle : Quick enable/disable switch (bottom right) Update Button : Additional update options (bottom right) User Interactions Viewing Device Information Scroll through the page to view different sections Click on any field's ellipsis menu (⋯) for field-specific actions Hover over chart elements to see detailed data points Editing Device Parameters Click on editable fields to modify values Use the ellipsis menus for advanced field options Click Save or Save and close to commit changes Monitoring Performance Review real-time metrics in the status bar Analyze CPU usage patterns in the graph Check uptime trends for connectivity issues Adjust time ranges using the 24-hour selector Managing Profiles Click on any profile section to expand its configuration Modify profile-specific parameters Save changes using the action buttons Downloading Diagnostics Expand the "Diagnostic - Download [TR-069]" section Select desired diagnostic data Download files for offline analysis Navigation Tips Sidebar Menu : Use the left navigation panel to switch between applications (Dashboard, Inventory, Firmware, Portals, Locations, Files, Organization, Settings, User log) Top Bar : Access device-specific tools (History, Refresh, Update) Breadcrumbs : Quick navigation to parent levels Action Buttons : Persistent at bottom of page for easy access Notes & Best Practices Device Status Monitoring Green indicators : Device is healthy and connected Last connection timestamp : Should update regularly (every few seconds) Alert status : Monitor for "Active" alerts requiring attention CPU Usage Interpretation Normal operation typically shows usage below 20% Spikes may indicate firmware updates, configuration changes, or processing intensive tasks Sustained high usage (>70%) requires investigation Uptime Considerations Recent uptime of 21+ hours indicates a device restart approximately one day ago Check Combined Logs if uptime resets unexpectedly Normal maintenance may require periodic restarts Configuration Management Always review changes before saving Use "Save and close" for single device updates Use "Save and add another" for batch device provisioning Changes may require device reboot to take effect Data Export Use CSV export for creating reports or importing into analysis tools 24-hour time window can be adjusted for longer historical views Consider downloading diagnostics before major configuration changes Footer Information Copyright : 2026 © zequenze Links : Terms of service | Privacy policy | Changelog System : CONTROL admin portal (dev) v1.2.20-dev User : jerinab@zequenze.com (org: Zequenze) This device details page serves as the central hub for managing and monitoring individual IoT devices within the CONTROL platform, providing administrators with comprehensive visibility and control over device operations, connectivity, and performance. Device logs Overview The Device Logs section of the Zequenze CONTROL Portal provides a comprehensive view of all device activity and configuration changes. This page displays real-time and historical log entries for network devices, allowing administrators to monitor device events, track configuration modifications, and troubleshoot network issues. Key Features Real-time Log Monitoring : View live device events and configuration changes as they occur Comprehensive Search : Advanced search functionality to filter logs by various criteria Export Capabilities : Export log data for external analysis and reporting Reports Generation : Generate custom reports from filtered log data Advanced Filtering System : Expandable filter panel with comprehensive filtering options for precise log analysis No Data State Management : Clear messaging and guidance when search results return no data UI Elements Header Section Search Bar : Located at the top center for quick log entry searches Reports Button : Light blue "Reports" button for generating custom reports Filter Toggle : Green "FILTER" button with close (X) option for toggling the filter panel Main Data Table The central table displays log entries with the following columns: Created : Timestamp of when the event occurred Origin : Source of the event (e.g., "Automatic") Device : Device identifier or name Action : Type of action performed (e.g., "Set", "Create", "Event: Boot", etc.) Name/Variable Name : Specific parameter or event name affected Value : Current or new value of the parameter Status : Overall status indicator Current Data Display The page currently shows no search results with a "No Data" state displaying: Search Icon : Large magnifying glass icon with folder representation indicating search functionality No Data Message : "Oops! We couldn't find any data" prominently displayed Helpful Text : "Your search did not match any results. Please try altering your search term, or change the filters." Results Counter : "0 results" shown at the bottom left Filter Panel (Right Side) The expandable filter panel is currently open and displays comprehensive filtering options: Panel State : Currently expanded, showing all available filter options Toggle Control : Green filter button with X close option for showing/hiding the panel Active Filters Header : "Active filters" section at the top showing currently applied filters Primary Action : Green "Proceed" button at the top for applying filter selections Filter Options (currently visible): Created : Time-based filtering with "Last hour" dropdown selection Records per page : Currently set to "50 records" State : Dropdown with "All" selected Origin : Dropdown with "All" selected User : "Click for options" field Parent device : "Click for options" field Profile : "Click for options" field Command / method : "Click for options" field Action : "Click for options" field Parameter : "Click for options" field Status : "Click for options" field Organization : "Click for options" field with "Sub-organizations" checkbox option Apply Button : Green "Proceed" button at the bottom of the panel to apply all selected filters User Interactions Searching and Filtering Quick Search : Enter search terms in the top search bar and click the search icon Filter Panel Access : Click the green "FILTER" button to expand the advanced filtering options Advanced Filtering : Use the expandable filter panel on the right with multiple filtering options including time-based, state, origin, and parameter filters Panel Management : Use the X button to close the filter panel when not needed Filter Application : Use the green "Proceed" buttons (at top and bottom of filter panel) to apply selected filters Dropdown Interactions : Click on dropdown menus for Created, Records per page, State, and Origin filters to select specific options Expandable Options : Click on "Click for options" fields to access additional filtering criteria Sub-organization Filtering : Use the "Sub-organizations" checkbox under Organization to include or exclude child organizations Data Management Generate Reports : Use the "Reports" button to create custom analytical reports Filter Toggle : Use the green "FILTER" button to show/hide the filtering interface Pagination Control : Adjust records per page display using the dropdown in the filter panel Event Analysis Search Refinement : When encountering no results, modify search terms or adjust filters as suggested Filter Adjustment : Use various filter options to expand or narrow search criteria Time-based Analysis : Use the "Last hour" filter and other time controls for temporal analysis Navigation Access Path Navigate from Home → Inventory → Device logs (as shown in breadcrumb) Direct URL access via the inventory section of the CONTROL Portal Related Sections Dashboard : Return to main dashboard for overview Inventory : Access device inventory and management Settings : Configure logging preferences and parameters Data Displayed No Results State When no data matches the current search and filter criteria, the system displays: Clear Visual Indicator : Large search icon with folder to indicate the search function Informative Message : Clear explanation that no data was found Helpful Guidance : Suggestion to modify search terms or adjust filters Filter State Visibility : Current active filters remain visible for easy modification Event Types (When Data Available) Configuration Events : Device parameter setting and management operations Creation Events : Device interface and component creation events Boot Events : CWMP '1 BOOT' events for device startup monitoring Auto-onboarding Events : Automated device provisioning and configuration events Management Events : Device management server configuration activities Actions Available Primary Actions Search : Filter and locate specific log entries Generate Reports : Create analytical reports from log data Toggle Filters : Use the green "FILTER" button to show/hide advanced filtering options Real-time Monitoring : View live device events and changes Filtering Actions Panel Toggle : Click the green "FILTER" button to expand/collapse filtering options Time Filtering : Use "Created" dropdown to filter by time periods (Last hour, etc.) Records Control : Adjust "Records per page" to control data display (currently 50 records) State Filtering : Filter by device operational state using the State dropdown Origin Filtering : Filter by event source or origin using the Origin dropdown User-based Filtering : Access user filtering options by clicking "Click for options" in the User field Parent Device Filtering : Access parent device filtering by clicking "Click for options" Profile Filtering : Access profile filtering by clicking "Click for options" Command/Method Filtering : Access command/method filtering by clicking "Click for options" Action Filtering : Access action filtering by clicking "Click for options" Parameter Filtering : Access parameter-based filtering by clicking "Click for options" Status Filtering : Access status filtering by clicking "Click for options" Organization Filtering : Access organization filtering by clicking "Click for options", with option to include sub-organizations via checkbox Filter Application : Use the green "Proceed" buttons at the top and bottom of the filter panel to apply all selected filters Active Filter Management : View currently applied filters in the "Active filters" section at the top of the filter panel Search Optimization Actions Search Term Modification : Alter search terms when no results are found Filter Adjustment : Modify active filters to broaden or refine search scope Filter Reset : Clear filters to expand search results Notes/Tips No Results Guidance : When no data is found, the system provides clear guidance to modify search terms or adjust filters Filter Visibility : Active filters remain visible even when no results are found, making it easy to identify and modify search parameters Search Refinement : Use the search functionality combined with advanced filters for highly specific log queries Dual Apply Buttons : The filter panel includes "Proceed" buttons at both the top and bottom for convenient filter application regardless of scroll position Active Filter Tracking : The "Active filters" section at the top of the filter panel shows currently applied filters for easy filter state management Time-based Filtering : Use the "Last hour" and other time-based filters for temporal log analysis Pagination Control : Adjust the records per page (currently 50) to optimize data viewing and performance Filter Visibility : When the filter panel is expanded, all filtering options are clearly visible for immediate access Interactive Filter Fields : Several filter options display "Click for options" to indicate they contain expandable selection menus Organization Hierarchy : Use the "Sub-organizations" checkbox to include or exclude logs from child organizations in your search Search Optimization : When encountering no results, try broadening search criteria or adjusting time-based filters Real-time Updates : The log view updates automatically to show new events when they occur Device type models Overview The Device Type Models page in the Zequenze Control Portal provides administrators with a comprehensive view and management interface for all device type models in the system. This page allows users to browse, filter, and manage various device models from different manufacturers, displaying detailed information about each device's specifications and characteristics. Key Features Comprehensive Device Catalog : View all registered device type models across multiple manufacturers Advanced Filtering System : Filter devices by manufacturer, device type, model, OS name, and origin Multi-Manufacturer Support : Supports devices from major manufacturers including Apple, Brightsign, Honor, Motorola, Oppo, Samsung, Tp-link, Xiaomi, and more Device Type Classification : Categorizes devices into types such as IoT devices, phones, tablets, routers, and PCs Operating System Information : Displays OS details including Android, iOS, and Windows variants Bulk Operations : Add and manage multiple device models simultaneously UI Elements Header Section Search Bar : Located at the top for quick device model searches Action Buttons : "Add" button (blue) for adding new device models "X" button (green) for bulk operations Filter Panel : Expandable right sidebar with filtering options Main Data Table The central table displays device information with sortable columns: Manufacturer : Company name with brand logos/icons Device Type : Visual icons representing device categories (IoT, Phone, Tablet, Router, PC) Model : Specific device model names and identifiers OS Name : Operating system information with OS icons OS Version : Version numbers and release information (currently showing "Unknown" for most entries) Origin : Source attribution (typically "AI Assistant") Filter Sidebar Manufacturer Filter : Dropdown to select specific manufacturers Device Type Filter : Category-based filtering options Model Filter : Search and filter by model names OS Name Filter : Filter by operating system Origin Filter : Filter by data source User Interactions Searching and Filtering Use the search bar to find specific device models by name or keyword Click the "FILTER" button to open the filtering sidebar Select desired filters from dropdown menus in the sidebar Click "Proceed" to apply filters or reset to clear all filters Data Management Click column headers to sort data in ascending/descending order Use checkboxes to select multiple device entries for bulk operations Click the "Add" button to register new device type models Navigate through pages using the pagination controls at the bottom Navigation Access this page through: Home → Enduser device → Device type models Use the left navigation menu under "User devices" → "Metadata" Breadcrumb navigation shows the current location in the portal hierarchy Data Displayed The page displays comprehensive device information including: Device Categories Mobile Devices : iPhones, Android phones from Honor, Motorola, Oppo, Samsung, and Xiaomi Tablets : Samsung Galaxy tablets IoT Devices : BrightSign digital signage devices Network Equipment : Tp-link routers Computing Devices : Windows PCs Technical Information Device model numbers and specifications (iPhone, Xd1132, Xt1143, X7b, X8, Moto-g13, A53, A80-5g, A15, A32, Galaxy a15, Galaxy tab a9, etc.) Operating system versions (currently showing "Unknown" for most entries) Manufacturer branding and categorization Actions Available Primary Actions Add New Models : Register new device type models in the system Filter and Search : Locate specific devices using multiple criteria Sort and Organize : Arrange data by any column for better organization Bulk Selection : Select multiple entries for batch operations Data Management View detailed specifications for each device model Export device information for reporting purposes Manage device categorization and classification Update device metadata and specifications Navigation Context Current Location : User devices → Metadata → Device type models Parent Sections : Accessible through the CONTROL admin portal navigation Related Pages : Links to other device management sections and inventory views Notes/Tips The page shows 19 total results with pagination controls for easy navigation Device icons provide quick visual identification of device types The "Unknown" entries indicate devices that may need additional metadata configuration for OS versions AI Assistant origin indicates automatically detected or classified devices Use the date navigation (November 11, 2025) to view historical device data The system supports real-time filtering and search without page refreshes This interface is essential for administrators managing large device inventories and ensuring proper device classification and metadata management across the Zequenze platform. Firmware Images Overview The Images page within the CONTROL admin portal provides a centralized interface for managing firmware images across the Zequenze ecosystem. This page allows administrators to view, search, filter, and manage firmware images that can be deployed to devices. The interface displays key metadata about each firmware image including version information, device compatibility, and deployment status. Key Features Firmware Image Repository : Displays all available firmware images in a structured table format Advanced Filtering : Comprehensive filter panel for narrowing down images by multiple criteria Status Tracking : Visual indicators showing active status and public availability Device Profile Association : Clear display of compatible device profiles for each image Version Management : Track different versions and releases of firmware images Organization Assignment : Images can be assigned to specific organizations within the system Quick Actions : Toolbar with options to add new images and perform bulk operations UI Elements Main Navigation Breadcrumb Trail : "Home > Firmware > Images" at the top provides clear navigation context Left Sidebar : Full application menu with sections including: Dashboard Inventory Firmware (with sub-items: Images, Profiles, Logs, Reports) Portals Locations Files Organization Settings User log Data Table Columns Name : Firmware image identifier Is active : Status indicator (green checkmark = active) Version : Version number or identifier (e.g., "test", "7.20.8") Device profile : Compatible device types with dropdown indicators Upgrade profile : Associated upgrade configuration Is public : Public availability status (red indicator = not public) Organization : Assigned organization (displays "Zequenze") Filter Panel (Right Side) Located in the right sidebar under "Active filters": Release date : Dropdown showing "Any or no datetime" Active : Dropdown set to "All" Device profile : "Click for options" dropdown Upgrade profile : "Click for options" dropdown Organization : "Click for options" with "Sub-organizations" checkbox Proceed : Button to apply selected filters Action Toolbar Search bar : Full-width search field for quick filtering Refresh button : Circular arrow icon to reload data Settings icon : Configuration options + Add button : Blue button to create new firmware image Dropdown menu : Green button with "x" for bulk actions FILTER toggle : Opens/closes the filter panel User Interactions Viewing Images The table displays 3 results by default showing: prueba - 2 : test version with Adrian TA414BG device profile prueba - 3 : test version with Adrian TA414BG device profile Mikrotik 7.20.8 [MIPSBE] : Version 7.20.8 with Mikrotik - RB952Ui (ppv4) device profile Each row provides comprehensive information about the firmware image at a glance Searching Images Use the search bar at the top to quickly find specific images by name or other attributes Real-time filtering as you type Filtering Images Click the "FILTER" button in the top right to open the filter panel Select criteria from available dropdowns: Filter by release date range Filter by active/inactive status Filter by specific device profile Filter by upgrade profile Filter by organization (with option to include sub-organizations) Click "Proceed" to apply filters Adding New Images Click the blue "+ Add" button in the toolbar Opens a form to upload and configure a new firmware image Navigation Getting to This Page From Dashboard → Firmware → Images (left sidebar) Breadcrumb navigation shows: Home > Firmware > Images Direct URL: /admin/firmware/image/ Related Pages Profiles : Manage device profiles associated with images Logs : View firmware deployment and update logs Reports : Generate reports on firmware usage and status Data Displayed Status Indicators Green checkmark (✓): Image is active and available for deployment Red dot (●): Image is not public/restricted access Version numbers : Display firmware version (test, 7.20.8, etc.) Device Profile Information Each device profile is shown as a clickable dropdown button (indicated by "▼" symbol): Adrian TA414BG : Custom device profile Mikrotik - RB952Ui (ppv4) : Mikrotik router profile with architecture specification Result Count "3 results" displayed at the bottom left of the table Updates dynamically based on active filters Actions Available Primary Actions Add New Image : Create and upload new firmware images Edit Image : Click on any row to modify image details Filter/Search : Narrow down visible images using search or filters Refresh Data : Reload the table to see latest changes Bulk Operations : Use the green dropdown menu for actions on multiple images Row-Level Actions Click device profile dropdowns to view or change associations Toggle active status Modify public availability settings Change organization assignments Notes/Tips Best Practices Image Naming : Use clear, descriptive names for firmware images (e.g., "Mikrotik 7.20.8 [MIPSBE]") Version Control : Maintain consistent versioning schemes (test, production versions) Device Profile Assignment : Always associate images with appropriate device profiles before deployment Active Status : Only active images are available for deployment to devices Public vs Private : Use the "Is public" flag to control image visibility across organizations Important Considerations Architecture Compatibility : Note architecture specifications (e.g., [MIPSBE]) to ensure compatibility Organization Scope : Filter by organization when managing multi-tenant environments Sub-organizations : Enable "Sub-organizations" checkbox to include child organization images Status Monitoring : Red indicators for "Is public" show restricted images requiring attention User Information Logged in as: tpena@zequenze.com (displayed in top right) Current role: Zequenze organization admin Portal version: CONTROL admin portal (dev) v1.2.26-dev (shown in footer) Firmware Image Detail Overview The Firmware Image Change page in the CONTROL admin portal is used to configure and manage firmware images for network devices. This page specifically displays the configuration for MikroTik 7.20.8 [MIPSBE] firmware (ID: 411), allowing administrators to define device profiles, upgrade settings, release information, and distribution parameters for firmware deployments. Key Features Firmware Image Configuration : Complete setup of firmware images including name, version, and device compatibility Device Profile Assignment : Link firmware to specific device models and hardware types Upgrade Profile Management : Define which devices should receive firmware updates based on selectors Release Date Control : Schedule when firmware becomes available for automatic updates Organization Management : Associate firmware with specific organizations and control public visibility File Management : Upload firmware files or provide alternative download URLs Version History : Track creation and modification dates for audit purposes UI Elements Header Section Page Title : "MikroTik 7.20.8 [MIPSBE] ID: 411" Timestamp Information : Created: Feb 10, 2026, 02:58:51 6:18 PM Last change: Feb 10, 2026, 02:58:51 6:18 PM Action Buttons : History (blue): View revision history Refresh (blue): Reload page data Image Settings Form Basic Information Fields Name Text field displaying: "MikroTik 7.20.8 [MIPSBE]" Identifies the firmware image in the system ID Read-only field showing: "411" Unique identifier for this firmware image Is Active Checkbox (checked): Indicates firmware is currently active and available for deployment Version Text field showing: "7.20.8" Help text: Explains version matching requirements for automatic updates and downgrades Device and Upgrade Configuration Device profile Tag-based selector displaying: "Mikrotik - RB952UI-5ac2nD - cfg: mtgeneric df1" Blue close button (×) to remove profile Plus button (+) to add additional profiles Help text: "Device profiles this firmware will auto-apply to" Upgrade profile Dropdown menu: "Click for options" Expandable/collapsible selector with plus (+) and minus (-) buttons Copy button for profile duplication File Currently shows: "firmware/1d7d5fdbf21bce6rie5-7-20-8-mipsbe.npk" (clickable link) Choose File button with "No file chosen" status Clear button to remove current file Labeled as "Change:" to indicate file upload option URL Text field (empty in screenshot) Help text: "Alternative URL where file can be downloaded. Used only if and when the file option is not specified." Release date Date field showing: "2026-01-30" Help text: Explains automatic update scheduling based on this date Selector Fields Apply to selector Dropdown menu: "Click for options" Help text: Defines matching method for device software version comparison Used for "Equal or selector" logic Apply to (version) Text field (empty) Help text: Specifies device software version requirements (leave blank for all versions) Hardware version Text field (empty) Help text: Specifies device hardware version requirements (leave blank for all hardware versions) Factory Checkbox (unchecked) Help text: "Activate the factory reset option on the devices after sending the firmware upgrade command" Organization Settings Organization Dropdown showing: "Zequenze" Associates firmware with specific organization Is public Checkbox (unchecked) Controls visibility across organizations Description Text area (empty) For adding detailed firmware notes or documentation Order Numeric field showing: "165" Controls display priority/sorting order Important Dates Section Collapsible section displaying: Last change : Feb. 10, 2026, 2:58 p.m. Created : Feb. 10, 2026, 2:58 p.m. Actions Available Bottom Action Bar Save (Blue button) Saves all changes to the firmware image configuration Delete (Red button) Removes the firmware image from the system Use with caution as this action may be irreversible Close (Gray button with X) Closes the page without saving changes Save and close (Blue button) Saves changes and returns to the previous page Save and add another (Blue button) Saves current configuration and opens a new blank form for adding another firmware image User Interactions Configuring Firmware Images Basic Setup : Enter a descriptive name for the firmware Specify the exact version number Activate/deactivate using the "Is active" checkbox Assigning Device Profiles : Click the plus (+) button next to "Device profile" Select applicable device models from the picker Multiple profiles can be assigned Remove profiles using the × button on each tag Upload Firmware File : Click Choose File button Select the firmware .npk file from local storage Alternative: Provide a URL in the URL field for remote downloads Setting Release Parameters : Enter release date to control when automatic updates begin Configure "Apply to selector" and version filters for targeted deployments Optionally specify hardware version requirements Organization Assignment : Select the owning organization from dropdown Check "Is public" to make firmware visible across organizations Add description for documentation purposes Navigation Access Path CONTROL admin portal (dev) → Firmware → Images → Select specific image Left Sidebar Menu Users can navigate to other sections: Dashboard Inventory Firmware (expanded) Images (current) Profiles Logs Reports Devices Locations Files Organization Settings User log Breadcrumb Navigation Home → Firmware → Images Data Displayed Configuration Metadata Firmware identification : Name, ID, version Status : Active/inactive state File information : Current firmware file path or URL Compatibility : Device profiles, hardware versions, software versions Deployment settings : Release date, upgrade profiles, selectors Organization ownership : Assignment and visibility settings Audit trail : Creation and modification timestamps Device Profile Tags Display format includes: Manufacturer (Mikrotik) Model (RB952UI-5ac2nD) Configuration type (cfg: mtgeneric df1) Notes/Tips Best Practices Version Matching : Ensure the version field exactly matches the version reported by devices to enable proper automatic updates and downgrades Device Profile Assignment : Always assign at least one device profile to ensure the firmware can be properly matched to compatible devices Release Date Strategy : Set future release dates to schedule automatic rollouts; leave blank or set past date for immediate availability File vs URL : Upload files for internal hosting or use URLs for external repositories. The system prioritizes uploaded files over URLs. Testing Before Activation : Configure firmware settings while "Is active" is unchecked, test with specific devices, then activate for broader deployment Factory Reset Option : Use the "Factory" checkbox cautiously as it will reset devices to factory defaults after upgrade Order Value : Use the order field to control how firmware images are prioritized in lists and selection interfaces Important Warnings Version Accuracy : Incorrect version numbers may prevent automatic updates from working correctly Device Profile Requirement : Firmware without device profiles won't auto-apply to any devices Deletion Impact : Deleting firmware images may affect scheduled upgrades and device configurations Factory Reset : Enabling factory reset will erase device configurations after firmware installation Technical Notes The .npk file format is specific to MikroTik RouterOS devices The [MIPSBE] designation indicates MIPS Big-Endian architecture compatibility Device profiles use composite identifiers including model and configuration type The system supports both push (immediate) and pull (scheduled) firmware deployment models