93 lines
3.3 KiB
Markdown
93 lines
3.3 KiB
Markdown
---
|
|
title: "CommandMessage Class - Message Parsing System"
|
|
description: "Documentation for the CommandMessage class used to parse and structure messages in a Modbus system"
|
|
keywords: ["ESP-32", "Modbus", "communication", "command parsing", "messaging"]
|
|
---
|
|
|
|
## CommandMessage
|
|
|
|
**Path**: [src/modbus/command_message.h](../src/modbus/command_message.h)
|
|
|
|
**Revision History**: Initial documentation
|
|
|
|
The CommandMessage class provides a structured approach to parse, validate, and manage command messages within the system. It supports message serialization and deserialization with defined start/end markers and delimiters. This class is designed for efficient messaging in industrial Modbus-485 communications.
|
|
|
|
## REQUIREMENTS
|
|
|
|
- No specific hardware pins required
|
|
- Requires StringUtils and enums support
|
|
|
|
## PROVIDES
|
|
|
|
- **CommandMessage**: The main class for message handling
|
|
- **DEBUG_MESSAGES_PARSE**: Conditional compilation flag for verbose message parsing output
|
|
- **DEBUG_MESSAGES_PARSER**: Macro for debug logging of message parsing operations
|
|
- **MESSAGE_TOKENS**: Constant defining the expected number of tokens in a valid message
|
|
|
|
## FEATURES
|
|
|
|
- Structured message storage with ID, verb, flags, and payload
|
|
- Timestamp tracking for message receipt
|
|
- Validation of message format with start/end markers
|
|
- Parsing of delimited message content
|
|
- Clear method for resetting message state
|
|
- Match checking for message format validation
|
|
|
|
## DEPENDENCIES
|
|
|
|
- [Vector](../src/Vector.h)
|
|
- [ArduinoLog](../src/ArduinoLog.h)
|
|
- [StringUtils](../src/StringUtils.h)
|
|
- [Enums](../src/modbus/enums.h)
|
|
|
|
```mermaid
|
|
graph TD
|
|
CommandMessage --> StringUtils
|
|
CommandMessage --> ArduinoLog
|
|
CommandMessage --> Vector
|
|
CommandMessage --> Enums
|
|
```
|
|
|
|
## BEHAVIOUR
|
|
|
|
```mermaid
|
|
sequenceDiagram
|
|
participant Client
|
|
participant CommandMessage
|
|
|
|
Client->>CommandMessage: Create message with id, verb, flags
|
|
Client->>CommandMessage: parse(message)
|
|
CommandMessage->>CommandMessage: clear()
|
|
CommandMessage->>CommandMessage: Extract content between markers
|
|
CommandMessage->>CommandMessage: Split by delimiters
|
|
CommandMessage->>CommandMessage: Validate token count
|
|
CommandMessage->>CommandMessage: Assign id, verb, flags, payload
|
|
CommandMessage->>CommandMessage: Set timestamp
|
|
CommandMessage-->>Client: Return success/failure
|
|
```
|
|
|
|
## TODOS
|
|
|
|
### PERFORMANCE
|
|
|
|
- Consider pre-allocating memory for the message parsing to avoid heap fragmentation
|
|
- Evaluate the use of String vs. char arrays for payload handling in memory-constrained environments
|
|
- Potential for optimizing token parsing with a more efficient approach than strtok
|
|
|
|
### SECURITY
|
|
|
|
- Consider implementing message integrity checking (checksums or CRC)
|
|
- Add length validation to prevent buffer overflows
|
|
- Implement validation of message payload content based on expected verb/command
|
|
|
|
### COMPLIANCE
|
|
|
|
- Ensure all message processing complies with Modbus protocol standards where applicable
|
|
- Consider adding support for standard industrial message formats
|
|
|
|
### RECOMMENDATIONS
|
|
|
|
- Add support for binary payloads for more efficient communication
|
|
- Consider implementing a message queue system to handle multiple messages
|
|
- Add methods to serialize a CommandMessage back to a string for bidirectional communication
|
|
- Consider adding timeout functionality for message handling |