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
83 lines
4.7 KiB
Markdown
83 lines
4.7 KiB
Markdown
# 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:
|
|
|
|
```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.
|
|
|
|
The fix was to remove the unnecessary check and the continue statement:
|
|
|
|
```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")
|
|
```
|
|
|
|
### 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. |