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. |