- Modified get_signals() API to only show real protocol mappings data
- Removed all fallback mock data that could confuse users
- Returns empty signals list when no protocol mappings configured
- Removed _create_fallback_signals() function
- Updated documentation to reflect no-fallback approach
This ensures users only see real protocol data and are not confused by mock signals.
- Fix duplicate protocol_type ID by renaming mapping-modal field to mapping_protocol_type
- Update populateModalFields to search for fields within modal context instead of globally
- Add debugging to show which fields are found in the modal
- Ensure protocol type and address fields are properly populated from discovery data
- Fix loadProtocolMappings reference error in dashboard.js by calling loadAllSignals()
- Add debugging to populateModalFields to identify field availability issues
- Ensure protocol mapping tab is activated before auto-populating from discovery
- Add delay to ensure tab content is loaded before attempting auto-population
- Add simplified protocol signals table for discovery integration
- Add signal modal for discovery data population
- Fix JavaScript null element reference issues with fallback selectors
- Improve auto-populate function to work with both signal and mapping forms
- Add error handling for missing DOM elements
- Fix global function exposure for discovery integration
- Update template to include discovery-compatible UI elements
- Add event binding for discovery scan button
- Implement startDiscoveryScan method with proper UI updates
- Add comprehensive debug logging to track discovery flow
- Fix discovery results container detection
- Improve error handling and user feedback
Now the discovery workflow should work properly:
1. Click 'Start Discovery Scan' button
2. See progress status and results
3. Click 'Use This Signal' to populate form
4. Click 'Apply All as Protocol Signals' to create all
- Fix global function references between discovery.js and protocol_mapping.js
- Add 'Apply All as Protocol Signals' functionality to discovery results
- Implement bulk signal creation from discovery results
- Add proper CSS styling for discovery results and notifications
- Expose key functions to global scope for cross-script communication
- Improve modal auto-population with better timing and error handling
Now discovery results properly:
- Populate the signal form when clicking 'Use This Signal'
- Create all signals at once when clicking 'Apply All as Protocol Signals'
- Show clear notifications for success/failure
- Refresh the protocol signals display automatically
- Replace complex ID system with intuitive signal name + tags approach
- Update main dashboard protocol mapping interface to use simplified system
- Add comprehensive API endpoints for protocol signals management
- Create simplified configuration manager and data models
- Implement discovery integration with auto-population of signal forms
- Add migration scripts and comprehensive test suite
- Update JavaScript files to use simplified system
- Create modern UI with filtering, tag cloud, and responsive design
Key improvements:
- Human-readable signal names instead of complex IDs
- Flexible tag-based categorization and filtering
- Seamless discovery to signal conversion
- Cleaner architecture with reduced complexity
- Better user experience and maintainability
- Add robust modal opening with multiple fallback methods
- Implement proper timing waits for modal and dropdown loading
- Add comprehensive logging for debugging
- Fix field population sequence and validation
- Add waitForStationsLoaded method to handle async dropdown loading
- Ensure all form fields are properly populated including mapping_id
- Set default database source based on device name
Co-authored-by: openhands <openhands@all-hands.dev>
- Update field IDs to match actual form (station_id, equipment_id, data_type_id)
- Add validation methods to check if metadata IDs exist
- Use actual sample metadata IDs instead of hardcoded defaults
- Fix station/equipment/data type dropdown population
- Update Apply All functionality to use real metadata
- Ensure discovery results properly prefill protocol mapping form
Co-authored-by: openhands <openhands@all-hands.dev>
- Add Control Station to demonstrate more location types
- Add Control Valve and PLC Controller to use more equipment types
- Add Valve Position and Emergency Stop data types
- Better coverage of core tag categories
- More realistic industrial automation scenario
- Maintains same custom tags but with better categorization
Co-authored-by: openhands <openhands@all-hands.dev>
- Create metadata initializer to load sample data on application startup
- Add sample metadata file with realistic water system configuration
- Update main application to initialize metadata during startup
- Sample includes 2 stations, 4 equipment, 4 data types with descriptive tags
- Provides realistic data for protocol mappings UI testing
Co-authored-by: openhands <openhands@all-hands.dev>
- Update displayProtocolMappings to show station/equipment/data type names from tag metadata
- Ensure tag metadata is loaded before displaying protocol mappings
- Update table headers to indicate Name & ID format
- Users now see descriptive names instead of raw IDs in the mappings table
Co-authored-by: openhands <openhands@all-hands.dev>
- Remove legacy configuration classes: PumpStationConfig, PumpConfig, SafetyLimitsConfig
- Update ProtocolMapping model with tag metadata validators
- Replace text inputs with dropdowns in UI templates
- Add tag metadata loading functions to JavaScript
- Remove legacy API endpoints and add tag metadata endpoints
- Update security permissions to remove configure_safety_limits
- Clean up configuration manager and hardware discovery
- All integration tests pass successfully
Co-authored-by: openhands <openhands@all-hands.dev>
- Fix total_discovered_endpoints count to use DISTINCT device_id instead of counting all endpoints
- Fix apply_discovery_results endpoint to handle dictionary data correctly
- Replace object attribute access with dict.get() methods for scan results
Resolves issues where discovery count doubled with each scan and
apply results failed with '[object Object]' errors.
- Add persistent discovery service auto-initialization in start_dashboard.py
- Fix 'is_scanning' field in discovery status API
- Fix scan results API to handle dictionary data correctly
- Fix database schema issues for discovery_results table
- Add debugging for service initialization
Resolves issues with discovery service not persisting across restarts
and API endpoints returning incorrect data formats.
- Add discovery_results table to database schema
- Create persistent discovery service with database storage
- Update dashboard API to use persistent discovery service
- Initialize persistent discovery service on application startup
- Fix 404 errors when polling discovery scan results
- Fixed syntax error in dashboard.js (missing closing bracket for DOMContentLoaded)
- Added favicon.ico file to static directory
- Added favicon link to dashboard HTML template
- All JavaScript errors should now be resolved
- Dashboard should load without console errors
Fixed TypeError in SSHDeployer.execute_remote() method by adding 'silent' parameter
- Added silent parameter with default value False
- Modified print statements to respect silent mode
- Health checks now work correctly during deployment
This ensures the deployment script can properly wait for services to start and validate the deployment
Created detailed deployment guides:
- DEPLOYMENT.md: Complete step-by-step deployment guide with configuration and key management
- DEPLOYMENT_CHECKLIST.md: Quick reference checklist for deployment process
Both guides cover:
- SSH key configuration and management
- Environment setup and configuration
- Multiple deployment methods (Python SSH, shell script, manual)
- Post-deployment verification and health checks
- Troubleshooting and rollback procedures
- Security considerations
Documentation provides clear instructions for production, staging, and test deployments
Updated references in:
- deploy/deploy-onprem.sh: Fixed paths for test-deployment.sh and test_dashboard_local.py
- deploy/validate-deployment.sh: Fixed path for test-e2e-deployment.py
- tests/integration/test-e2e-deployment.py: Fixed paths for mock servers
All file references now point to correct locations in the new organized structure
- Add discovery protocol test files for debugging and direct testing
- Add remote test integration scripts and configuration
- Update deployment and monitoring scripts with recent changes
- Include test-remote.yml configuration for remote testing
- Updated discovery service import to use protocol_discovery_fast
- Fixed recent discoveries endpoint to properly extract endpoints from scan results
- Enhanced dashboard JavaScript with complete functionality
- Updated Docker configuration for discovery module inclusion
- Added remote deployment documentation
This resolves the discovery API 404 errors and ensures all dashboard features work correctly.
- Add ProtocolDiscoveryService with network scanning for all protocols
- Create discovery API endpoints for scan management and results
- Implement discovery UI components in dashboard
- Add comprehensive unit tests for discovery functionality
- Integrate discovery with configuration manager for automatic mapping creation
- Support background task execution for long-running discovery scans
- Include discovery status monitoring and recent discoveries endpoints
- Created 35 comprehensive tests covering ConfigurationManager, protocol validation, and database integration
- Added unit tests for ConfigurationManager with database persistence
- Added protocol-specific validation tests for all 4 protocols (Modbus TCP, Modbus RTU, OPC UA, REST API)
- Added integration tests for protocol server integration
- Enhanced existing API tests for protocol mapping endpoints
- Fixed database integration issues in ConfigurationManager
- Improved validation logic and error handling
- All tests passing with comprehensive coverage of Phase 1 functionality
- Extended Modbus server input register range from 300 to 400 registers
- Fixed IllegalAddress errors for performance registers (400-499)
- Added timeout protection for Modbus operations in dashboard API
- Added protocol architecture diagram to documentation
- Confirmed both OPC UA and Modbus servers are running correctly
- Protocol clients now successfully read real data with 0% error rate
Test Results:
- OPC UA: 15/15 signals active, 0% error rate
- Modbus: 18/18 signals active, 0% error rate
- REST: 3/3 signals active, 0% error rate
- Replace get_pump_data with direct register reads
- Read holding register 350 for pump speed
- Read input register 0 for flow rate
- Calculate derived values for power, pressure, and status
- Use real Modbus data when available
- Keep fallback for OPC UA until security policy issues are resolved
- Maintain graceful fallback to mock data if protocol clients fail
Only configure secure security policies when certificates are available. When certificates are not available, only offer the None security policy and skip certificate validation configuration.
- OPC UA client: Explicitly set security policy to 'None' to match server
- OPC UA client: Fix connection handling to check if connection succeeded
- Modbus client: Update register addresses to match server configuration
- Modbus client: Add proper connection success checking
- Updated test-deployment.sh to use port 8081 instead of 8080
- Updated test-e2e-deployment.py to use port 8081 instead of 8080
- Updated setup-test-environment.sh to use port 8081 instead of 8080
- All test scripts now work correctly with test environment configuration
openhands