Thank you for helping me understand the connection between the frontend’s chart history and the climate component.
Just to confirm that I understand your explanation, I’ve put together all the links in the chain:
From the climate base class, state is set to self.current_operation:
class ClimateDevice(Entity):
"""Representation of a climate device."""
@property
def state(self):
"""Return the current state."""
if self.is_on is False:
return STATE_OFF
if self.current_operation:
return self.current_operation
if self.is_on:
return STATE_ON
return STATE_UNKNOWN
MQTT HVAC doesn’t override this method so its state is the same as self.current_operation. Its current_operation method returns an internal property called self._current_operation.
@property
def current_operation(self):
"""Return current operation ie. heat, cool, idle."""
return self._current_operation
That internal property is handled in several places but, most importantly, in the handle_mode_received method. Here it gets set to the payload of CONF_MODE_STATE_TOPIC.
@callback
def handle_mode_received(topic, payload, qos):
"""Handle receiving mode via MQTT."""
if CONF_MODE_STATE_TEMPLATE in self._value_templates:
payload = self._value_templates[CONF_MODE_STATE_TEMPLATE].\
async_render_with_possible_json_value(payload)
if payload not in self._operation_list:
_LOGGER.error("Invalid mode: %s", payload)
else:
self._current_operation = payload
self.async_schedule_update_ha_state()
Whew! The chain is complete. The operation mode is ultimately what is represented in the shaded area of chart history for MQTT HVAC.
So the ultimate question is: What’s more informative?
- Seeing a chart of when the HVAC system is enabled.
- Seeing a chart of when the HVAC system is operating (actively heating or cooling).
Personally, I think the second option is more useful. Seeing a chart of when my furnace is producing heat (and consuming energy) is more interesting than a multi-hour chart of the furnace sitting in “heat mode”.
I don’t know if there’s a design guide for climate platforms but, even if there is, the authors of each platform have decided to go their own way. I agree with you that the first option (charting the operation mode) appears to be the norm. However, the author of the Proliphix platform appears to have chosen the second option (charting the operation state).
In the Proliphix platform, current_operation is set to the result of self._pdp.hvac_state.
@property
def current_operation(self):
"""Return the current state of the thermostat."""
state = self._pdp.hvac_state
if state in (1, 2):
return STATE_IDLE
if state == 3:
return STATE_HEAT
if state == 6:
return STATE_COOL
The Proliphix API, provides one command (thermHvacMode) to return the HVAC system’s mode and a separate one (thermHvacState) for its state.
The Proliphix platform sets current_operation to the HVAC system’s state, not mode. Therefore its history chart will look different from other platforms, shading the time periods when the furnace is actively heating.
That’s the way I believe MQTT HVAC platform should work. I’ll be modifying my local instance of the platform to function that way.
Last but not least, I’m puzzled by the decision to exclude Hold mode from the frontend UI. Oddly, Swing mode is displayed and that’s something normally buried in a physical thermostat’s configuration menu. In contrast, Hold is normally shown on a thermostats as plainly as temperature and fan control.
I found the relevant code and I know what needs to be done to display a control for Hold mode. However, I’m stumped by the next step, namely creating a modified local instance.
The instructions suggest I need to clone the entire frontend repo followed by many more steps that seem onerous for my need to just tweak a few lines in one file. It’s not as easy as with a platform where you just put a modified copy of it in config/custom_components. Is there any shortcut or am I obliged to download the entire repo, install node.js, etc?
