TasmotaManager/rule1_device_mode_verification.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

4.7 KiB

Rule1 Device Mode Verification

Issue Description

The issue was reported as: "For Device mode, the Rule is not being set or enabled". This suggested that when using the --Device parameter in TasmotaManager.py to configure a single device, the rules defined in the network_configuration.json file (specifically rule1) were not being properly set or enabled on the device.

Investigation

Code Analysis

I examined the code responsible for rule setting and enabling in Device mode:

  1. The process_single_device method (line 1296) processes a single device when the --Device parameter is used.
  2. For normal (non-unknown) devices, it:
    • Creates a temporary list with just the target device
    • Saves this list to current.json temporarily
    • Calls get_device_details with use_current_json=True and skip_unknown_filter=True
  3. The get_device_details method (line 1541) loads devices from current.json and processes each device.
  4. For each device, it:
    • Gets device status information (firmware, network, MQTT)
    • Calls check_mqtt_settings to update MQTT settings if needed
    • Sets console_updated = mqtt_updated (indicating console settings are applied in configure_mqtt_settings)
  5. The configure_mqtt_settings method (line 771) is responsible for applying console settings, including rules.
  6. For rule definitions (lowercase rule1, rule2, etc.), it:
    • Detects them (line 1088)
    • Stores the rule number for later enabling (lines 1090-1091)
    • URL encodes the rule value to preserve special characters (lines 1105-1108)
    • Sends the rule command to set the rule (line 1109)
  7. After processing all console parameters, it auto-enables any rules that were defined (lines 1172-1176).

Previous Fix

I found that a fix had already been implemented for this issue, as documented in rule_enable_fix_summary.md. The issue was 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.

The fix was to remove the unnecessary check and the continue statement:

# 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")

Testing

I ran the test_rule1_device_mode.py script, which:

  1. Gets a test 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 showed that rule1 is now being correctly set and enabled in Device mode:

2025-08-06 22:30:30 - INFO - Rule1 after Device mode: {'State': 'ON', 'Once': 'OFF', 'StopOnError': 'OFF', 'Length': 42, 'Free': 469, 'Rules': 'on button1#state=10 do power0 toggle endon', 'EnableStatus': {'Rule1': {'State': 'ON', 'Once': 'OFF', 'StopOnError': 'OFF', 'Length': 42, 'Free': 469, 'Rules': 'on button1#state=10 do power0 toggle endon'}}}
2025-08-06 22:30:30 - INFO - Extracted rule text from response: on button1#state=10 do power0 toggle endon
2025-08-06 22:30:30 - INFO - SUCCESS: rule1 was correctly set!

Conclusion

The issue "For Device mode, the Rule is not being set or enabled" has been fixed. The fix was implemented by removing an unnecessary check and continue statement in the rule auto-enabling logic. This ensures that rules defined in the configuration are properly enabled when applied to Tasmota devices in Device mode.

The fix has been verified by running the test_rule1_device_mode.py script, which confirms that rule1 is now being correctly set and enabled in Device mode.

The issue description was likely written before the fix was applied, and the issue has now been resolved.