TasmotaManager/rule_enable_fix_summary.md
Mike Geppert 126cd39555 Major code improvements and bug fixes:
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
2025-08-08 19:04:33 -05:00

3.1 KiB

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:

# 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:

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