Description of the Bug
The PID controller and the autotune functionality fail to activate if the target_sensor entity has an unavailable or unknown state during Home Assistant's startup phase.
Many sensors, especially Zigbee or Z-Wave devices, can take up to a minute to provide their first reading after a restart. The smart_thermostat integration initializes very quickly and attempts to read the sensor's state. When it receives a non-numeric value, it fails to initialize the PID controller, causing pid_mode to be permanently stuck in the "off" state for the remainder of the session.
The thermostat then falls back to a basic on/off mode, but the PID and autotune features are unusable until the next restart (if they are lucky enough to win the "race condition").
Steps to Reproduce
- Configure the smart_thermostat platform with a target_sensor that is known to be unavailable for a short period after a restart (e.g., most Zigbee sensors).
- Enable autotune in the configuration.
- Restart Home Assistant.
- Immediately observe the state attributes of the climate entity.
Expected Behavior
The integration should gracefully handle a temporarily unavailable sensor. Ideally, it should wait for a valid numeric state before initializing the PID controller, allowing pid_mode to switch to "auto" and the autotune process to begin.
Actual Behavior
The pid_mode and autotune_status attributes remain "off", and the PID control logic never activates.
Configuration
climate:
- platform: smart_thermostat
name: "Chauffage - Chambre de xyz"
unique_id: chauffage_chambre_xyz_pid_thermostat
heater: switch.radiateur_chambre_xyz
target_sensor: sensor.th_01_temperature
min_temp: 5
max_temp: 30
initial_hvac_mode: "heat"
precision: 0.1
keep_alive:
minutes: 3
min_cycle_duration: "00:05:00"
initial_temp: 30
pwm: "00:20:00"
kp: 30
ki: 0.015
kd: 5000
autotune: "ziegler-nichols"
noiseband: 0.1
Attributes:
heat
"off"
min_temp: 5
max_temp: 30
current_temperature: 17
temperature: 20.5
hvac_action: idle
away_temp: null
eco_temp: null
boost_temp: null
comfort_temp: null
home_temp: null
sleep_temp: null
activity_temp: null
control_output: 0
kp: 30
ki: 0.015
kd: 5000
ke: 0
pid_mode: "off"
pid_i: 0
autotune_status: "off"
autotune_sample_time: null
autotune_tuning_rule: ziegler-nichols
autotune_set_point: null
autotune_peak_count: 0
autotune_buffer_full: 0
autotune_buffer_length: 10
friendly_name: Chauffage - Chambre de xyz
supported_features: 385
Relevant log
DEBUG (MainThread) [custom_components.smart_thermostat.climate] climate.chauffage_chambre_de_xyz: Unable to update from sensor sensor.th_01_temperature: could not convert string to float: 'unavailable'
DEBUG (MainThread) [custom_components.smart_thermostat.climate] climate.chauffage_chambre_de_xyz: Received new temperature: None
DEBUG (MainThread) [custom_components.smart_thermostat.climate] climate.chauffage_chambre_de_xyz: Unable to update from sensor sensor.th_01_temperature: could not convert string to float: 'unknown'
DEBUG (MainThread) [custom_components.smart_thermostat.climate] climate.chauffage_chambre_de_xyz: Received new temperature: None
A few seconds later:
DEBUG (MainThread) [custom_components.smart_thermostat.climate] climate.chauffage_chambre_de_xyz: Received new temperature: 17.0
INFO (MainThread) [custom_components.smart_thermostat.climate] climate.chauffage_chambre_de_xyz: Obtained temperature 17.0 with set point 20.5. Activating SmartThermostat.
Description of the Bug
The PID controller and the autotune functionality fail to activate if the target_sensor entity has an unavailable or unknown state during Home Assistant's startup phase.
Many sensors, especially Zigbee or Z-Wave devices, can take up to a minute to provide their first reading after a restart. The smart_thermostat integration initializes very quickly and attempts to read the sensor's state. When it receives a non-numeric value, it fails to initialize the PID controller, causing pid_mode to be permanently stuck in the "off" state for the remainder of the session.
The thermostat then falls back to a basic on/off mode, but the PID and autotune features are unusable until the next restart (if they are lucky enough to win the "race condition").
Steps to Reproduce
Expected Behavior
The integration should gracefully handle a temporarily unavailable sensor. Ideally, it should wait for a valid numeric state before initializing the PID controller, allowing pid_mode to switch to "auto" and the autotune process to begin.
Actual Behavior
The pid_mode and autotune_status attributes remain "off", and the PID control logic never activates.
Configuration
Attributes:
Relevant log