dandri/meshcore-bot
1
0
Fork 0
mirror of https://github.com/agessaman/meshcore-bot.git synced 2026-05-31 04:44:13 +00:00
Code Issues Packages Projects Releases Wiki Activity

Move internal documentation to local docs folder

Browse Source 
- Move MODULAR_STRUCTURE.md, RACE_CONDITION_FIX.md, and REPEATER_MANAGEMENT.md to docs/local/
- Remove these files from git tracking (they were internal development notes)
- Add docs/local/ to .gitignore to prevent future commits of internal docs
- Keep only README.md as the public documentation in the repository
This commit is contained in:
agessaman
2025-09-06 11:47:17 -07:00
parent f47bf87549
commit be6bb74346
4 changed files with 3 additions and 691 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
+3
View File
@@ -120,3 +120,6 @@ Thumbs.db
config.ini
*.db
mctomqtt.py
# Local documentation (internal development notes)
docs/local/
MODULAR_STRUCTURE.md
-347
View File
@@ -1,347 +0,0 @@
# MeshCore Bot Modular Structure
The MeshCore Bot has been reorganized into a modular structure for better organization and maintainability. This document describes the new architecture.
## Directory Structure
```
meshcore_bot/
├── meshcore_bot.py # Main entry point (simplified)
├── modules/ # Core modules directory
│ ├── __init__.py # Package initialization
│ ├── core.py # Main bot class and core functionality
│ ├── models.py # Data models (MeshMessage, etc.)
│ ├── rate_limiter.py # Rate limiting functionality
│ ├── message_handler.py # Message processing and routing
│ ├── command_manager.py # Command management and response generation
│ ├── channel_manager.py # Channel operations and management
│ ├── scheduler.py # Scheduled message handling
│ └── commands/ # Individual command implementations
│ ├── __init__.py # Commands package initialization
│ ├── base_command.py # Base class for all commands
│ ├── test_command.py # Test command implementation
│ ├── ping_command.py # Ping command implementation
│ ├── help_command.py # Help command implementation
│ ├── advert_command.py # Advert command implementation
│ └── t_phrase_command.py # T-Phrase command implementation
```
## Module Descriptions
### Core Modules
#### `core.py`
- **Purpose**: Main bot class and initialization
- **Responsibilities**:
- Configuration loading
- Connection management (BLE/Serial)
- Module initialization
- Startup/shutdown logic
- Startup advert handling
#### `models.py`
- **Purpose**: Shared data structures
- **Contents**:
- `MeshMessage` dataclass for message representation
- Other shared data models
#### `rate_limiter.py`
- **Purpose**: Message rate limiting
- **Responsibilities**:
- Prevent spam by limiting message frequency
- Configurable time intervals
- Track last message time
#### `message_handler.py`
- **Purpose**: Message processing and routing
- **Responsibilities**:
- Handle incoming contact messages (DMs)
- Handle incoming channel messages
- Extract path information and metadata
- Route messages to appropriate command handlers
- Message validation and filtering
- **Enhanced Signal Quality Extraction**:
- Extract SNR (Signal-to-Noise Ratio) from multiple sources
- Extract RSSI (Received Signal Strength Indicator) from multiple sources
- Cache signal quality data from RF log events
- Associate signal quality with corresponding messages
- **Advanced Packet Decoding**:
- Decode MeshCore packet structure directly from message payloads
- Extract routing path information (node IDs, path length, route type)
- Parse packet headers for payload version and type
- Provide detailed routing information for enhanced responses
- **Direct extraction** - no time-based association needed
#### `command_manager.py`
- **Purpose**: Command processing and response generation
- **Responsibilities**:
- Keyword matching
- Custom syntax processing (e.g., "t phrase")
- Response formatting with message data
- Send DMs and channel messages
- Load configuration for keywords and syntax
#### `channel_manager.py`
- **Purpose**: Channel operations and management
- **Responsibilities**:
- Fetch channels from MeshCore device
- Channel name/number mapping
- Optimized channel fetching (stops at empty channels)
#### `scheduler.py`
- **Purpose**: Scheduled message handling
- **Responsibilities**:
- Load scheduled messages from config
- Time-based message scheduling
- Background scheduler thread
### Command Modules
#### `commands/base_command.py`
- **Purpose**: Base class for all commands
- **Responsibilities**:
- Define command interface
- Common command functionality
- Help text generation
- Execution validation
#### Individual Command Modules
Each command has its own module implementing the `BaseCommand` interface:
- **`test_command.py`**: Handles "test" keyword responses
- **`ping_command.py`**: Handles "ping" keyword responses
- **`help_command.py`**: Provides compact, LoRa-optimized help system
- **`advert_command.py`**: Handles "advert" command (DM only, 1-hour cooldown)
- **`t_phrase_command.py`**: Handles "t phrase" custom syntax
- **`at_phrase_command.py`**: Handles "@{string}" custom syntax (DM only)
- **`cmd_command.py`**: Lists available commands in compact format (LoRa-friendly)
- **`hello_command.py`**: Handles various greetings with robot-themed responses
## Benefits of Modular Structure
### 1. **Separation of Concerns**
- Each module has a single, well-defined responsibility
- Easier to understand and maintain individual components
- Clear interfaces between modules
### 2. **Easier Testing**
- Individual modules can be tested in isolation
- Mock dependencies for unit testing
- Better test coverage and debugging
### 3. **Simplified Development**
- New commands can be added by creating new command modules
- Existing functionality can be modified without affecting other modules
- Clear patterns for implementing new features
### 4. **Better Code Organization**
- Related functionality is grouped together
- Easier to find specific code
- Reduced file sizes and complexity
### 5. **Reusability**
- Modules can be reused in other projects
- Common functionality is centralized
- Easier to share code between different bot implementations
## Adding New Commands
To add a new command:
### **Enhanced Signal Quality Monitoring**
The bot now provides comprehensive signal quality information for all incoming messages, including both SNR (Signal-to-Noise Ratio) and RSSI (Received Signal Strength Indicator).
**Signal Quality Data:**
- **SNR**: Signal-to-Noise Ratio in dB (higher is better)
- **RSSI**: Received Signal Strength Indicator in dBm (closer to 0 is stronger)
- **Automatic Extraction**: Bot automatically extracts signal quality from RF log events
- **Smart Caching**: Associates signal quality with messages using pubkey matching
- **Multiple Sources**: Checks payload, metadata, and cached data for signal quality
**Display in Responses:**
- **Test Command**: `Message received from {sender} | {connection_info} | SNR: {snr} dB | RSSI: {rssi} dBm | Received at: {timestamp}`
- **T Phrase**: `ack {sender}: {phrase} | Direct connection (0 hops) | SNR: {snr} dB | RSSI: {rssi} dBm`
- **@ Phrase**: Same format as T Phrase (DM only)
**Technical Implementation:**
- **RF Log Handler**: Processes `RX_LOG_DATA` events to extract SNR and RSSI
- **Dual Cache System**: Separate caches for SNR and RSSI data
- **Pubkey Association**: Links signal quality data to messages using sender pubkey
- **Fallback Handling**: Gracefully handles missing signal quality data
- **Real-time Updates**: Signal quality data is updated with each RF log event
**Configuration:**
Signal quality display is automatically enabled and requires no additional configuration. The bot will show "Unknown" for SNR/RSSI when data is not available.
### **Self-Documenting Help System (LoRa-Optimized)**
The bot now features a compact, self-documenting help system designed for LoRa's 140 character limit. Each command provides its own help text via the `help <command>` syntax.
**Examples:**
- `help` → "Bot Help: test, ping, help, cmd, advert, t phrase, @string | Use 'help <command>' for details" (93 chars)
- `help @` → "Help @: Responds to '@{string}' with ack + connection info (DM only)." (69 chars)
- `help t` → "Help t: Responds to 't phrase' with ack + connection info." (58 chars)
- `help cmd` → "Help cmd: Lists commands in compact format." (43 chars)
**Features:**
- **LoRa Friendly**: All help responses fit within 140 character limit
- **Dynamic Help**: Each command provides its own help text via `get_help_text()` method
- **Command Aliases**: `help @` maps to the `at_phrase` command, `help t` maps to the `t_phrase` command
- **Compact Format**: Optimized for low-bandwidth mesh networks
- **Configurable**: General help response is configurable in `config.ini`
- **Automatic Updates**: New commands automatically appear in help when added
**Configuration:**
The general help response is configurable in `config.ini`:
```ini
[Keywords]
help = "Bot Help: test, ping, help, cmd, advert, t phrase, @string | Use 'help <command>' for details"
```
### **New cmd Command (LoRa-Friendly)**
The bot now includes a `cmd` command that lists all available commands in a compact, comma-separated format designed for LoRa's character limitations.
**Usage:**
- `cmd` → Lists all available commands in a compact format
**Response:**
```
Available commands: test, ping, help, cmd, advert, t phrase, @string
```
**Features:**
- **LoRa Optimized**: Only 68 characters, well within ~140 character limit
- **Compact Format**: Comma-separated list for easy reading
- **Complete Coverage**: Includes all basic commands, custom syntax, and special commands
- **User-Friendly**: Shows actual usage syntax (e.g., "t phrase" instead of "t_phrase")
### **New Hello Command with Robot Greetings**
The bot now includes a fun "hello" command that responds to various greeting variants with robot-themed responses from popular culture.
**Usage:**
- `hello`, `hi`, `hey`, `howdy`, `greetings`, `salutations` → Bot responds with robot greeting
**Response Format:**
```
Hi, I'm {botname}. {random_robot_greeting}
```
**Examples:**
- `hello` → "Hi, I'm HowlBot. Greetings, meat-based organism!"
- `hi` → "Hi, I'm HowlBot. Hello, meatbag!"
- `howdy` → "Hi, I'm HowlBot. Salutations, carbon-based lifeform!"
**Robot Greetings Include:**
- "Greetings, human!"
- "Hello, meatbag!"
- "Salutations, carbon-based lifeform!"
- "Greetings, organic entity!"
- "Hello, biological unit!"
- And 10+ more variations...
**Features:**
- **Multiple Variants**: Responds to 6 different greeting words
- **Random Responses**: Each greeting gets a different robot response (even same word gets different responses)
- **Bot Name Integration**: Uses configured bot name from config.ini
- **Robot Personality**: Fun, sci-fi themed responses
- **LoRa Friendly**: Responses fit within character limits
- **No Config Required**: Randomization is built into the command logic
### **New @{string} Syntax (DM Only)**
The bot now supports a new `@{string}` syntax that works exactly like the existing `t {string}` syntax, but only in direct messages. This makes it easier for users to interact with the bot via DMs.
**Examples:**
- `@hello world` → `ack {sender}: hello world | {connection_info}`
- `@test message` → `ack {sender}: test message | {connection_info}`
**Configuration:**
```ini
[Custom_Syntax]
@_phrase = "ack {sender}: {phrase} | {connection_info}"
```
**Features:**
- **DM Only**: Only works in direct messages, not in channels
- **Same Response Format**: Uses the same response template as `t_phrase`
- **Configurable**: Response format can be customized in `config.ini`
- **Automatic Detection**: Bot automatically detects `@` prefix and processes accordingly
### **Standard Command Addition**
1. **Create a new command module** in `modules/commands/`
2. **Inherit from `BaseCommand`** and implement required methods
3. **Add the command to `CommandManager`** in the `commands` dictionary
4. **Update configuration** if needed
Example:
```python
# modules/commands/weather_command.py
from .base_command import BaseCommand
from ..models import MeshMessage
class WeatherCommand(BaseCommand):
def get_help_text(self) -> str:
return "Get current weather information."
async def execute(self, message: MeshMessage) -> bool:
# Implementation here
return True
```
## Configuration
The modular structure maintains the same configuration format as before. All settings are loaded through the core module and distributed to appropriate modules as needed.
## Future Enhancements
The modular structure makes it easy to add:
- **Plugin system** for third-party command modules
- **API integrations** in separate modules
- **Advanced message processing** pipelines
- **Multiple bot instances** with different configurations
- **Web interface** for bot management
- **Database integration** for persistent storage
## Migration Notes
- **Existing functionality**: All existing bot features work exactly the same
- **Configuration**: No changes to `config.ini` required
- **API**: External interface remains unchanged
- **Performance**: No performance impact from modularization
## Advanced Packet Decoding and Routing
The bot now implements sophisticated packet decoding to extract detailed routing information directly from incoming message packets, providing the same level of routing detail as the example code you shared.
### Features
- **Raw Packet Decoding**: Decodes MeshCore packet structure from raw hex data
- **Routing Path Extraction**: Extracts actual node IDs and path information from packet headers
- **Route Type Detection**: Identifies direct vs. routed connections from packet headers
- **Payload Analysis**: Parses payload version and type information
- **Enhanced Responses**: Includes detailed routing information in all command responses
### Technical Implementation
- **`decode_meshcore_packet()` Method**: Implements the decoding strategy from your example code
- **Header Parsing**: Extracts path length, route type, payload version, and payload type
- **Path Node Extraction**: Converts raw bytes to readable 2-character hex node IDs
- **Route Classification**: Determines if message is direct or routed based on header bits
- **Message Integration**: Updates message path information with decoded routing data
- **Direct Extraction**: Routing information comes directly from message payloads, no time-based association needed
### Packet Structure Decoding
The bot now decodes the same packet structure as your example:
- **Header Byte**: Contains route type (lower 2 bits), payload type (bits 2-5), and version (bits 6-7)
- **Path Length**: Second byte indicates the number of path bytes
- **Path Bytes**: 2-byte little-endian node IDs representing the routing path
- **Payload**: Remaining data after the path information
### Response Enhancement
All commands now display enhanced connection information including:
- **Connection Type**: Direct (0 hops) or Routed (X hops)
- **Signal Quality**: SNR and RSSI values
- **Routing Details**: Actual node path (e.g., "Route: 01,5f,7e (3 nodes)") or "Direct"
RACE_CONDITION_FIX.md
-131
View File
@@ -1,131 +0,0 @@
# Race Condition Fix for RF Data Correlation
## Problem Description
The MeshCore Bot was experiencing a race condition where channel messages would sometimes show "unknown" SNR/RSSI values instead of actual measurements. This occurred because:
1. **Event Timing Dependency**: The bot expected `RX_LOG_DATA` events (containing SNR/RSSI) to arrive before or very close to `CHANNEL_MSG_RECV` events
2. **Short Time Window**: The original 5-second correlation window was too narrow for network timing variations
3. **No Fallback Strategy**: When immediate correlation failed, there was no robust fallback mechanism
## Root Cause Analysis
From the logs, we can see the issue:
```
2025-09-04 17:24:42 - MeshCoreBot - WARNING - ❌ NO RF DATA found for channel message
```
This happened because:
- The `RX_LOG_DATA` event arrived outside the 5-second correlation window
- The events were processed in an unexpected order
- The timing gap between RF data and message events was too large
## Solutions Implemented
### 1. Extended Time Window
- **Before**: 5-second correlation window
- **After**: 15-second correlation window (configurable)
- **Benefit**: Handles network timing variations and device processing delays
### 2. Multi-Strategy Correlation System
The bot now uses 4 correlation strategies in sequence:
#### Strategy 1: Immediate Correlation
- Try to find RF data immediately using exact pubkey match
- Fastest and most accurate when events arrive in order
#### Strategy 2: Message Queuing (Enhanced Mode)
- Store messages temporarily and wait 100ms for RF data
- Only enabled when `enable_enhanced_correlation = true`
- Handles cases where RF data arrives slightly after message
#### Strategy 3: Extended Timeout
- Search with 2x the normal timeout (30 seconds)
- Catches RF data that arrived much earlier than expected
#### Strategy 4: Most Recent Fallback
- Use the most recent RF data available
- Ensures we always have some signal strength information
### 3. Improved Pubkey Matching
- **Exact Match**: Full pubkey comparison (most reliable)
- **Partial Match**: First 16 characters (handles truncated pubkeys)
- **Fallback**: Most recent data (handles timing issues)
### 4. Enhanced Data Storage
- **Timestamp Index**: Fast lookup by time
- **Pubkey Index**: Fast lookup by sender
- **Automatic Cleanup**: Removes old data to prevent memory leaks
### 5. Configuration Options
Added to `config.ini`:
```ini
[Bot]
# RF Data Correlation Settings
rf_data_timeout = 15.0 # Time window for correlation
message_correlation_timeout = 10.0 # Time to wait for correlation
enable_enhanced_correlation = true # Enable advanced strategies
```
## Performance Impact
### Positive Impacts
- **Higher Success Rate**: More messages will have accurate SNR/RSSI values
- **Better User Experience**: Users see actual signal strength instead of "unknown"
- **Robust Operation**: Handles network timing variations gracefully
### Minimal Overhead
- **Memory**: Slightly more memory for correlation indexes (cleaned up automatically)
- **CPU**: Negligible impact from additional correlation attempts
- **Latency**: 100ms additional wait only when needed (Strategy 2)
## Testing Results
All correlation strategies tested successfully:
- ✅ Immediate correlation
- ✅ Message correlation system
- ✅ Extended timeout correlation
- ✅ Partial pubkey matching
- ✅ Cleanup functionality
## Configuration Recommendations
### For Stable Networks
```ini
rf_data_timeout = 10.0
enable_enhanced_correlation = false
```
### For Unstable Networks (Default)
```ini
rf_data_timeout = 15.0
enable_enhanced_correlation = true
```
### For Very Unstable Networks
```ini
rf_data_timeout = 30.0
enable_enhanced_correlation = true
```
## Monitoring
The bot now logs correlation success/failure:
- `🔍 FOUND RF DATA`: Successful correlation
- `❌ NO RF DATA found for channel message after all correlation attempts`: All strategies failed
Monitor these logs to tune the configuration for your network conditions.
## Backward Compatibility
- All changes are backward compatible
- Default configuration provides improved behavior
- Can be disabled by setting `enable_enhanced_correlation = false`
- Original 5-second behavior available by setting `rf_data_timeout = 5.0`
## Future Improvements
1. **Adaptive Timeouts**: Automatically adjust timeouts based on network conditions
2. **Machine Learning**: Learn optimal correlation strategies from historical data
3. **Network Quality Metrics**: Track correlation success rates and adjust accordingly
4. **Event Ordering**: Implement event sequence numbers for more reliable correlation
REPEATER_MANAGEMENT.md
-213
View File
@@ -1,213 +0,0 @@
# Repeater Contact Management System
## Overview
The MeshCore Bot now includes a comprehensive repeater contact management system that addresses the issue where only users in the device's contact list can DM the bot. This system automatically identifies repeaters and room servers, catalogs them in a database, and provides tools to purge them from your contact list periodically.
## Problem Solved
- **Issue**: Repeaters and room servers accumulate in your device's contact list
- **Impact**: Only contacts in the device's contact list can DM the bot
- **Solution**: Automated detection, cataloging, and purging of repeater contacts
## Features
### 🔍 Automatic Detection
- Scans your device's contact list for repeaters and room servers
- **LoRa-aware**: Uses only local contact data to avoid LoRa communication overhead
- Identifies repeaters by checking device role fields (role, device_role, type, mode)
- Analyzes advertisement flags, path information, and telemetry data
- Falls back to name pattern matching with validation
### 📊 Database Management
- **SQLite database** for reliable, lightweight storage
- Tracks repeater metadata (name, public key, device type, timestamps)
- Maintains audit log of all purging operations
- Configurable database location via `repeater_db_path` in config
### 🗑️ Intelligent Purging
- **Actual contact removal** from device using `meshcore-cli remove_contact` command
- **LoRa-aware**: 30-second timeouts and error handling for LoRa communication
- **Batch processing**: Delays between removals to avoid overwhelming the network
- Purge repeaters older than specified days
- Purge specific repeaters by name
- Restore previously purged repeaters (marks for re-discovery)
- Automatic cleanup of old audit logs
### 📈 Statistics & Monitoring
- View total, active, and purged repeater counts
- Track recent purging activity
- Monitor system health and usage
## Usage
### Bot Commands
The system provides a comprehensive `!repeater` command with multiple subcommands:
#### Scan for Repeaters
```
!repeater scan
```
Scans your current contacts and catalogs any new repeaters found.
#### List Repeaters
```
!repeater list # Show active repeaters
!repeater list --all # Show all repeaters (including purged)
```
#### Purge Repeaters
```
!repeater purge 30 # Purge repeaters older than 30 days
!repeater purge "Hillcrest" # Purge specific repeater by name
!repeater purge 30 "Auto-cleanup" # Purge with custom reason
```
#### Restore Repeaters
```
!repeater restore "Hillcrest" # Restore specific repeater
!repeater restore "Hillcrest" "Manual restore" # Restore with reason
```
#### View Statistics
```
!repeater stats
```
Shows comprehensive statistics about repeater management.
#### Get Help
```
!repeater help
```
Displays detailed help for all repeater commands.
## Configuration
Add the following to your `config.ini` file:
```ini
[Bot]
# ... existing bot settings ...
# Path to repeater contacts database
repeater_db_path = repeater_contacts.db
```
## Database Schema
### repeater_contacts Table
- `id`: Primary key
- `public_key`: Unique repeater public key
- `name`: Repeater name
- `device_type`: 'Repeater' or 'RoomServer'
- `first_seen`: When first cataloged
- `last_seen`: When last seen
- `contact_data`: JSON string of full contact data
- `is_active`: Whether currently active (not purged)
- `purge_count`: Number of times purged
### purging_log Table
- `id`: Primary key
- `timestamp`: When action occurred
- `action`: 'added', 'purged', or 'restored'
- `public_key`: Repeater public key
- `name`: Repeater name
- `reason`: Reason for action
## Implementation Details
### Repeater Detection Logic
The system identifies repeaters using local contact data analysis (LoRa-aware):
1. **Role Fields**: Checks contact data for role fields (role, device_role, type, mode)
2. **Advertisement Flags**: Analyzes flags and advert_flags for repeater indicators
3. **Path Analysis**: Uses out_path_len and path information to identify repeaters
4. **Telemetry Data**: Checks telemetry fields for repeater-specific indicators
5. **Name Validation**: Uses name patterns with validation to avoid false positives
6. **No LoRa Communication**: All detection happens locally to avoid network overhead
### Database Benefits
**SQLite** was chosen because:
- ✅ **Lightweight**: No server setup required
- ✅ **Built-in Python support**: No additional dependencies
- ✅ **ACID compliance**: Reliable data storage
- ✅ **SQL queries**: Easy to query and manage data
- ✅ **Perfect for small-medium datasets**: Ideal for repeater management
### Integration
The system is fully integrated into the bot:
- Automatically initialized when bot starts
- Repeater manager available as `bot.repeater_manager`
- Command automatically loaded via plugin system
- Database path configurable via config file
## Example Workflow
1. **Initial Setup**: Bot starts and initializes repeater manager
2. **Scan**: Run `!repeater scan` to catalog existing repeaters
3. **Monitor**: Use `!repeater list` to see what's been found
4. **Purge**: Run `!repeater purge 30` to remove old repeaters
5. **Restore**: Use `!repeater restore` if you need a repeater back
6. **Statistics**: Check `!repeater stats` for system health
## Files Added
- `modules/repeater_manager.py` - Core repeater management functionality
- `modules/commands/repeater_command.py` - Bot command interface
- `repeater_management_demo.py` - Demonstration script
- `REPEATER_MANAGEMENT.md` - This documentation
## Benefits
1. **Cleaner Contact List**: Actually removes repeater contacts from device using CLI commands
2. **Better DM Functionality**: Only real users can DM the bot (repeaters are removed from contact list)
3. **LoRa-Optimized**: Designed for LoRa networks with timeouts and batch processing
4. **Accurate Detection**: Uses local contact data analysis for reliable identification
5. **Automated Management**: Set-and-forget repeater purging with network awareness
6. **Audit Trail**: Track all purging operations
7. **Flexible Control**: Manual override for specific repeaters
8. **Statistics**: Monitor system usage and health
## Future Enhancements
Potential improvements could include:
- Automatic purging on a schedule
- Integration with meshcore-cli for actual contact removal
- More sophisticated repeater detection algorithms
- Export/import functionality for repeater databases
- Integration with external repeater databases
## Troubleshooting
### Database Issues
- Check file permissions for database location
- Ensure sufficient disk space
- Verify SQLite is available (built into Python)
### Command Not Found
- Ensure `repeater_command.py` is in the `modules/commands/` directory
- Check bot logs for plugin loading errors
- Verify the plugin loader is working correctly
### No Repeaters Found
- Run `!repeater scan` to catalog repeaters
- Check if your contacts have device role information in their contact data
- Verify contact data contains role fields, flags, or path information
- Check bot logs for any detection errors
### LoRa Communication Issues
- The system uses 30-second timeouts for LoRa commands
- Batch processing adds 2-second delays between contact removals
- If commands timeout, the system continues with database operations
- Check bot logs for timeout warnings or command errors
## Support
For issues or questions about the repeater management system:
1. Check the bot logs for error messages
2. Run `!repeater stats` to check system status
3. Use `!repeater help` for command reference
4. Review this documentation for configuration options