New Entity Proposal: TemperatureControl

sebirdman commented 3 years ago

Context

I've been working on an integration for Traeger wifi connected grills. In the past there have been some proposals for cooker entities and cooler entities. These seem to have stalled, and I'm also not sure those proposals are abstract enough for HA.

As @awarecan stated in the cooker entity MR:

Then, what is Anova Precision Cooker? a sensor you can get temperature, a switch you can turn on/off, or multiple type of entity mapped in HA. In home-assistant, it is normal one device may have multiple entity, each represent one of its features. We also have very strict limit to add new type of entity, for example, if you really feel that you need a cooker to better present that subclass of kitchen appliance, you have to first make a proposal in https://github.com/home-assistant/architecture.

In keeping with that comment, I've tried to make sure this proposal is the very base set of features needed to control a temperature.

Proposal

The TemperatureControl Entity is an entity type that manages a feature on a device that a user can adjust the temperature on. This entity:

May heat or cool itself
May maintain a temperature for a long (indefinite) period of time
May have heating or cooling presets that are specific to the device

This entity does not:

Cover heating/cooling of items without temperature control (most coffee pots, and potentially other devices)

TemperatureControlEntity

Much of the proposed state below is taken from climate or water heater entities

State: [
  STATE_OFF,  # device is currently off and not controllable
  STATE_READY, # device is ready to be controlled but is not actively moving to a temperature
  STATE_MAINTAIN,  # holding desired temperature
  STATE_CHANGING, # device is moving to the desired temperature
]

State Attributes: [
  'current_temperature', 
  'target_temperature', 
  'preset_mode', # The current active preset. Requires SUPPORT_PRESET_MODE
]

Device Attributes: [
  'unit_of_measurement ',
  'min_temperature',
  'max_temperature', 
  'target_temperature_step', # The supported step size a target temperature can be increased/decreased
  'precision',  #  whole degrees or tenths of a degree
  'preset_modes', # The available presets. Requires SUPPORT_PRESET_MODE
}

Supported Feature: [
  SUPPORT_TURN_ON, # some appliance won't allow remote turn on, only be able to remote turn off 
  SUPPORT_PRESET_MODE,
  SUPPORT_TURN_OFF,  
]

Services: [
  'turn_off', # Requires SUPPORT_TURN_OFF
  'turn_on': { # Requires SUPPORT_TURN_ON
    'service_data': ['target_temperate', 'preset_mode']
  }
  'adjust_temperature': {
    'service_data': ['target_temperate', 'preset_mode']
  }
]

Consequences

Positive:

Reusing and sharing code between climate and water heater entities becomes more possible
Cards that target this entity will easily be able to work across more devices
Future device types (cooker/coolers) are one step closer to first class devices in HA

Negative:

More abstract does not always mean better, if a cooker/cooler/climate/water heater entity one day may need to implement this, along with other sub-entities to create itself - it may become confusing and hard to follow from a code standpoint.
Preset mode is a bit odd here to me still. some Devices may not support it, or some cooker/cooler type entities may only do preset modes and no temperature control at all. It seems like it may make more sense to have a completely separate proposal for them, as a PresetEntity.

balloob commented 3 years ago

This sounds like it's exactly the same as our climate entity?

sebirdman commented 3 years ago

It's very similar, but the climate entity is focused on a specific task:

The Climate integration allows you to control and monitor HVAC (heating, ventilating, and air conditioning) devices and thermostats.

Most of the services and attributes of the climate entity are focused on controlling and reporting a human climate. Whereas TemperatureEntity would be more generalized for controlling any temperature.

yuvalabou commented 3 years ago

You can however use the generic thermostat as a generic thermostat for grill or cooker, that why it is called "generic", dosn't it?

sebirdman commented 3 years ago

@yuvalabou this is absolutely something that can be "worked around" with a climate or water heater entity. Either workarounds do quite well for just the temperature control element of the entity. The issue comes when attempting to control the device on/off states. Many cooker devices allow a user to remotely turn the device off but not on.

in the case of the generic thermostat, there's a required "heater" field that must be a toggle device

heater string REQUIRED entity_id for heater switch, must be a toggle device. Becomes air conditioning switch when ac_mode is set to true.

yuvalabou commented 3 years ago

Well, true. However I still disagree becouse if we do need a generic thermostat for specific application or device that is not an AC one can make the built-in generic thermostat integration more versatile, say - allow to configure a "device class" or somthing similar, but there is no need to make a whole new platform or integration to achieve this.

sebirdman commented 3 years ago

@yuvalabou fair point, Do you know if i should make a proposal to make the built in one more versatile or should i just make an MR?

home-assistant / architecture