Mike Geppert
126cd39555
1. Restructured configuration: Moved config_other and console to top level 2. Added common _match_pattern function for regex pattern matching 3. Implemented Unifi Hostname bug fix in is_hostname_unknown 4. Created common get_device_hostname function to eliminate code duplication 5. Added comprehensive test scripts for all new functionality 6. Added detailed documentation for all changes
57 lines
3.1 KiB
Markdown
57 lines
3.1 KiB
Markdown
# Rule Enable Fix Summary
|
|
|
|
## Issue Description
|
|
|
|
The issue was that rules defined in the configuration were not being enabled when applied to Tasmota devices. Specifically, when a rule (e.g., `rule1`) was defined in the `console` section of the configuration, the rule was being set on the device but not enabled (via the `Rule1 1` command).
|
|
|
|
## Root Cause Analysis
|
|
|
|
After examining the code in `TasmotaManager.py`, the issue was identified in the rule auto-enabling logic in the `configure_mqtt_settings` method:
|
|
|
|
```python
|
|
# Check if the lowercase version (rule1) is in the config
|
|
lowercase_rule_param = f"rule{rule_num}"
|
|
if lowercase_rule_param in console_params:
|
|
self.logger.info(f"{name}: Found lowercase {lowercase_rule_param} in config, will enable {rule_enable_param}")
|
|
# Don't continue - we want to enable the rule
|
|
else:
|
|
self.logger.info(f"{name}: No rule definition found in config, skipping auto-enable")
|
|
continue
|
|
```
|
|
|
|
The issue was that:
|
|
|
|
1. The code was checking if the lowercase rule parameter (e.g., "rule1") was in `console_params`, which was redundant because rules were already detected and added to `rules_to_enable` earlier in the code.
|
|
2. If the lowercase rule parameter was not found in `console_params`, it would log "No rule definition found in config, skipping auto-enable" and continue to the next rule, effectively skipping the rule enabling.
|
|
3. But if a rule is in `rules_to_enable`, it means it was already found in `console_params`, so this check was unnecessary and was causing rules to not be enabled.
|
|
|
|
## Fix Implemented
|
|
|
|
The fix was to remove the unnecessary check for the lowercase rule parameter and the continue statement that was causing rules to not be enabled:
|
|
|
|
```python
|
|
# If we're here, it means we found a rule definition earlier and added it to rules_to_enable
|
|
# No need to check again if it's in console_params
|
|
self.logger.info(f"{name}: Will enable {rule_enable_param} for rule definition found in config")
|
|
```
|
|
|
|
This change ensures that:
|
|
|
|
1. If a rule definition (e.g., "rule1") is found in the configuration, it's added to `rules_to_enable`.
|
|
2. When processing `rules_to_enable`, the code only checks if the uppercase rule enable command (e.g., "Rule1") is already in the configuration.
|
|
3. If the uppercase rule enable command is not in the configuration, the rule is enabled by sending the `Rule1 1` command to the device.
|
|
|
|
## Testing
|
|
|
|
The fix was tested using the `test_rule1_device_mode.py` script, which:
|
|
|
|
1. Gets a device from `current.json`
|
|
2. Gets the expected rule1 value from `network_configuration.json`
|
|
3. Runs TasmotaManager in Device mode
|
|
4. Checks if rule1 was properly set and enabled after running
|
|
|
|
The test confirmed that rule1 is now being properly enabled when applied to Tasmota devices.
|
|
|
|
## Conclusion
|
|
|
|
This fix ensures that rules defined in the configuration are properly enabled when applied to Tasmota devices, allowing the rules to function as expected. The auto-enabling feature now works correctly, eliminating the need to manually add both the rule definition (e.g., "rule1") and the rule enable command (e.g., "Rule1 1") to the configuration. |