Description
Thermostat does not reliably change states based upon temperature satisfaction unless the mode is set to "Heat/Cool"
Expected Behavior
In 'Cool' mode
Thermostat automatically changes from "cooling" to "idle" when set temperature is reached OR thermostat automatically changes from "idle" to "cooling" when temperature is above set point
In 'Heat' mode
Thermostat automatically changes from "heating" to "idle" when set temperature is reached OR thermostat automatically changes from "idle" to "heating" when temperature is below set point.
Exhibited BehaviorIn 'Cool' mode
Thermostat does not always change states at appropriate times based upon temperature. Thermostat may stay in idle state when temperature is multiple degrees higher than set point. In the condition where thermostat is in cooling state, it may not always change back to idle, even when set point is satisfied by multiple degrees.
In 'Heat' mode
Thermostat does not always change states at appropriate times based upon temperature. Thermostat may stay in idle state when temperature is multiple degrees lower than set point. In the condition where thermostat is in heating state, it may not always change back to idle, even when set point is satisfied by multiple degrees.
How to Reproduce the Issue
Create a thermostat instance with the following configuration:
Artificially increase room temperature such that the set point is exceeded.
Observe thermostat action.
Repeat up to 5 times until undesired outcome is reached.
Repeat tests for 'Heat' mode, but instead artificially reduce the room temperature.
Observe identical behavior.
Repeat tests for 'Heat/Cool' mode.
Observe that the issue does not occur.
Additionally....
Observe that if the thermostat is 'stuck' in a state, adjusting the set point may cause the thermostat to change states accordingly.
Additional Notes
This is not a new bug. I have witnessed this behavior since my initial installation of the add-on, which would have been commit 75f6674. Since then, this exact behavior has been exhibited on my system, and I cannot seem to find anything inherently wrong with the way my automations are configured. For example, the ONLY state machine in control of the 'virtual' heating or cooling call booleans is in fact the thermostat add-on. The switch controlled by the thermostat add-on is a in-duct booster fan. As such, I do not use the switch as a 'fan' unless the thermostat is placed into 'fan' mode. Otherwise, the switch is controlled by an automation that considers the state of my home's main thermostat, and compares it to the state of a ha-dualmodegeneric thermostat instance. Since the thermostat instance's fan entity is set to 'neutral' this should not be a conflict.
Pertinent Logs
2024-06-30 04:01:48.036 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'dualmode_generic' calls `async_track_state_change` instead of `async_track_state_change_event` which is deprecated and will be removed in Home Assistant 2025.5 at custom_components/dualmode_generic/climate.py, line 364: async_track_state_change(, please report it to the author of the 'dualmode_generic' custom integration
2024-06-30 04:01:48.037 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'dualmode_generic' calls `async_track_state_change` instead of `async_track_state_change_event` which is deprecated and will be removed in Home Assistant 2025.5 at custom_components/dualmode_generic/climate.py, line 378: async_track_state_change(, please report it to the author of the 'dualmode_generic' custom integration
2024-06-30 04:01:48.039 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'dualmode_generic' calls `async_track_state_change` instead of `async_track_state_change_event` which is deprecated and will be removed in Home Assistant 2025.5 at custom_components/dualmode_generic/climate.py, line 385: async_track_state_change(, please report it to the author of the 'dualmode_generic' custom integration
2024-06-30 04:01:48.040 WARNING (MainThread) [homeassistant.helpers.frame] Detected that custom integration 'dualmode_generic' calls `async_track_state_change` instead of `async_track_state_change_event` which is deprecated and will be removed in Home Assistant 2025.5 at custom_components/dualmode_generic/climate.py, line 392: async_track_state_change(, please report it to the author of the 'dualmode_generic' custom integration
2024-06-30 04:01:48.041 WARNING (MainThread) [custom_components.dualmode_generic.climate] Undefined target temperature,falling back to 60.0
2024-06-30 04:01:48.046 WARNING (MainThread) [custom_components.dualmode_generic.climate] Undefined target temperature,falling back to 60.0
2024-06-30 04:01:48.051 WARNING (MainThread) [custom_components.dualmode_generic.climate] Undefined target temperature range,falling back to 60.0 to 80.0
Description Thermostat does not reliably change states based upon temperature satisfaction unless the mode is set to "Heat/Cool"
Expected Behavior
In 'Cool' mode Thermostat automatically changes from "cooling" to "idle" when set temperature is reached OR thermostat automatically changes from "idle" to "cooling" when temperature is above set point
In 'Heat' mode Thermostat automatically changes from "heating" to "idle" when set temperature is reached OR thermostat automatically changes from "idle" to "heating" when temperature is below set point.
Exhibited Behavior In 'Cool' mode Thermostat does not always change states at appropriate times based upon temperature. Thermostat may stay in idle state when temperature is multiple degrees higher than set point. In the condition where thermostat is in cooling state, it may not always change back to idle, even when set point is satisfied by multiple degrees.
In 'Heat' mode Thermostat does not always change states at appropriate times based upon temperature. Thermostat may stay in idle state when temperature is multiple degrees lower than set point. In the condition where thermostat is in heating state, it may not always change back to idle, even when set point is satisfied by multiple degrees.
How to Reproduce the Issue
Create a thermostat instance with the following configuration:
Set the thermostat to 'Cool' mode.
Artificially increase room temperature such that the set point is exceeded.
Observe thermostat action.
Repeat up to 5 times until undesired outcome is reached.
Repeat tests for 'Heat' mode, but instead artificially reduce the room temperature.
Observe identical behavior.
Repeat tests for 'Heat/Cool' mode.
Observe that the issue does not occur.
Additionally.... Observe that if the thermostat is 'stuck' in a state, adjusting the set point may cause the thermostat to change states accordingly.
Additional Notes This is not a new bug. I have witnessed this behavior since my initial installation of the add-on, which would have been commit 75f6674. Since then, this exact behavior has been exhibited on my system, and I cannot seem to find anything inherently wrong with the way my automations are configured. For example, the ONLY state machine in control of the 'virtual' heating or cooling call booleans is in fact the thermostat add-on. The switch controlled by the thermostat add-on is a in-duct booster fan. As such, I do not use the switch as a 'fan' unless the thermostat is placed into 'fan' mode. Otherwise, the switch is controlled by an automation that considers the state of my home's main thermostat, and compares it to the state of a ha-dualmodegeneric thermostat instance. Since the thermostat instance's fan entity is set to 'neutral' this should not be a conflict.
Pertinent Logs