- Update get_signals API to include signals from simplified protocol signals
- Maintain backward compatibility with old protocol mappings
- Generate realistic values based on signal names and protocol types
- Fix Apply All to properly create all 3 signals instead of just 1
- Add duplicate detection to prevent creating signals with same names
- Add Clear All Signals button for testing
- Update cache-busting versions for JavaScript files
- 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