New Entity Proposal: Cooker

[arbreng]

I am in the process of adding support for my Anova Precision Cooker in the Google Assistant and Alexa components, however this is currently not possible as none of the current components really matches up well with its functionality.

Connected microwaves, ovens, tea kettles, and coffee pots are all things, but we have no good way to support them natively in Home Assistant.

I propose creating a new type of Entity: the Cooker. A Cooker can encompass anything that heats food or beverage to a set temperature, for a set time, or both.

This is needed if we want to expose cooker-type entities to assistant services, since breaking the cooker up into its constituent switches and sensors will not work well for that.

State

• STATE_OFF
• STATE_ON or STATE_HEAT
• STATE_PROBLEM
• Timer Started/Stopped? How do these interplay with the other states?

Properties

• current_temperature
• target_temperature
• min_temperature
• max_temperature
• unit_of_measurement (C or F)
• precision (whole degrees or tenths of a degree)
• Time Left on Timer
• Cooking Mode -- Bake, Broil, Etc

Microwaves use power instead of temperature, which would have to be accounted for somehow.

I have a PR open for the sous-vide type cooker here.

[arbreng]

FWIW this guy already said he would convert his MQTT-based solution to an mqtt cooker platform if we implement this:

https://community.home-assistant.io/t/anova-sous-vide-control-over-mqtt/48146

[balloob]

Don't have time for full feedback, but just to let you know that we cannot store relative times in the state machine (Time left on timer). Instead, you could store the timestamp that the cooker will be done.

[awarecan]

My thought on this:

State: [
  STATE_OFF,  # offline or idle
  STATE_ON,  # working
  STATE_DONE,  # depends on device, may means keep warming or idle
]

State Attributes: [
  'operation_mode': [Bake, Broil, Warming, etc]  # when state is in STATE_ON or STATE_DONE
  'done_at': date_time  # when the state will change / has changed from STATE_ON to STATE_DONE
  'current_temperature', 
  'target_temperature', 
]

Device Attributes: [
  'unit_of_measurement ',
  'min_temperature',
  'max_temperature', 
  'precision',  #  whole degrees or tenths of a degree
]

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

Services: [
  'turn_off',
  'turn_on': {
    'service_data': ['operation_mode', 'target_temperate', 'operation_period']
]

[niemyjski]

Same could be said for climate or water heater...

[allenporter]

Yes, that is right. My impression from reading other architecture discussions on topics like this is climate would be done this way if introduced now. Or put another way, the current design standards are based on observations/learnings about previous entities.

[allenporter]

I see there is a lawn mower entity for example that is being worked through #894 (comment) you could argue the same rationale for it -- i am not sure if there are specific rationales for why that benefits from an entity. I just know its easier to start w/o it and introduce it later if there is a specific reason.

[mikey0000]

It still could be argued it needs a base platform whether that is ApplianceEntity or CookerEntity or widget entity, just need it to be very simple with all the extras done as part of the integration being built on top of that entity using all the other compose-able entity types. In future when broad support for a feature is present across the board, new features can additionally be added to the ApplianceEntity/CookerEntity

So yeah a few Feature flags may initially be required, such as grillingFeature, HeatingFeature and so on. To start with it will have to be quite small.

[allenporter]

Is that about how it shows up in the frontend? (e.g. you include all the same controls on a UI panel?) I'm curious how that would compare to the device panel for that device, with all its entities for the device shown together. It seems like given this discussion has been open since 2018, going with separate entities could be a much faster path forward given operation was the only unique attribute in your proposal. (i think the proposal is good to have all those other separate entities)

[arbreng]

@awarecan Nice proposal, I've added a little bit to it.

Also, can you explain to me the difference between state attributes and device attributes? I'm still learning hass 🏡 😄

State: [
  STATE_OFF,  # offline or idle
  STATE_PREHEAT,  #  most devices have some sort of preheat phase.  Could also re-use STATE_HEAT for this?
  STATE_ON,  # working; if any time is present it will start running now
  STATE_DONE,  # depends on device, may means keep warming or idle
  STATE_PROBLEM,  # general error condition
]

State Attributes: [
  'preparation_mode': [Preheat, None]
  'operation_mode': [Bake, Broil, Warming, Grinding, etc]  # Grinding is for coffee makers, and implies warming
  'prepared_at': date_time  # when the state will change / has changed from STATE_PREPARING to STATE_ON.  optional, only used if support_prepare_timer is true
  'done_at': date_time  # when the state will change / has changed from STATE_ON to STATE_DONE.
  'idle_at':  date_time # when the state will change / has changed from STATE_DONE to STATE_OFF
  'current_temperature', # None if supports_temperature is false
  'target_temperature', # None if supports_temperature is false
  'power_level',  #  Numeric power level.  Devices which use low/medium/high can be converted to 1,2,3.  None if supports_power is false
  'unit_of_measurement ',  # None if supports_temperature is false
  'min_temperature',  # None if supports_temperature is false
  'max_temperature',  # None if supports_temperature is false 
  'precision',  #  whole degrees or tenths of a degree.  None if supports_temperature is false
  'min_power',  # None if supports_power is false
  'max_power',  # None if supports_power is false
]

Supported Feature: [
  'support_turn_off',
  'support_turn_on',  # some appliance won't allow remote turn on, only be able to remote turn off 
  'support_temperature',  # some appliances support direct temperature control (oven and teakettle, but not microwave or coffee maker)
  'support_power',  # some appliances instead support control via power levels (microwave and coffee maker, but not oven or tea kettle)
  'support_timer',  # some devices support timed cooking (oven, but not coffee maker)
  'support_prepare_timer',  # some devices support timed prewarming (coffee maker, but not oven)
  'support_done_timer',  # most devices with keep warm support a timer for it
]

Services: [  # some devices allow setting these parameters ahead of time
  'set_preparation_mode':  { 'service_data': ['preparation_mode'] }
  'set_preparation_period':  { 'service_data': ['preparation_period'] }
  'set_operation_mode':  { 'service_data': ['operation_mode'] }
  'set_operation_period':  { 'service_data': ['operation_period'] }
  'set_temperature': { 'service_data': ['target_temperature'] }
  'set_power': { 'service_data': ['power_level'] }

  'turn_off',
  'turn_on': {  'service_data': ['preparation_mode', 'preparation_period', 'operation_mode', 'target_temperate', 'power_level', 'operation_period'] }
]

I'm not sure how to support extra modes or toggles yet. I might look at the vacuum component for inspiration

I own the 4 devices that I linked in the OP, and this state should be able to support all 4 of them.

[awarecan]

Also, can you explain to me the difference between state attributes and device attributes?

I actually have same question, because device_state_attributes will override state_attributes... I finally found a piece of document this time

In order to expose attributes for a platform, you will need to define a property called device_state_attributes on the entity class, which will return a dictionary of attributes:

Entities also have a similar property state_attributes, which normally doesn't need to be defined by new platforms. This property is used by base components to add standard sets of attributes to a state. Example: The light component uses state_attributes to add brightness to the state dictionary. If you are designing a new component, you should define state_attributes instead. ref

[arbreng]

Awesome, thanks for the docs.

That means state_attributes is for all of the attributes we are defining here. device_state_attributes will be specific to the platform and won't have anything list here. Example: Anova lets you read calibration_factor and temperature_history.

I updated my proposal to reflect that everything should belong in state_attributes for what we are discussing now.

I also have a question about component/directory structure for these things. The type of entity is cooker, and I have multiple platforms to add. Even though 2 of the new platforms are by the same company (Smarter), I keep them as separate platforms because the config info is different per device.

Here is the proposed structure:

homeassistant/
    components/
        cooker/
            __init__.py
            anova.py  ## Configuration is bluetooh MAC of device, don't want an 'anova' component.

            demo.py  ## Will contain code for a a demo sous-vide, oven, microwave, coffee, and tea based on supported_features.  Similar to vacuum demo

            mqtt_anova.py  ## Do we want to merge with anova and make it a config of that platform to switch between bluetooth or MQTT?

            smarter_coffee.py   ## Configuration is IP:Port of device, do we still want a 'smarter' component?  Do we want a single 'smarter' platform with coffee or tea as a config (they both use the same library)?

            smarter_tea.py  ## Configuration is IP:Port of device, do we still want a 'smarter' component?
Do we want a single 'smarter' platform with coffee or tea as a config (they both use the same library)?

            whirlpool_microwave.py  # Will probably be combined with a whirlpool: component for login info
tests/
    components/
        cooker/
            __init__.py
            test_anova.py
            test_demo.py
            test_smarter_coffee.py
            test_smarter_tea.py

(I don't know how to write tests for mqtt_sous_vide or whirlpool_microwave yet)

[awarecan]

Component should support only one communication protocol, BLE and TCP/IP should resident in different component as my understanding.

MQTT is a different story, IMO, you should have a cooker/mqtt.py, not cooker/mqtt_anova.py. I know you familiar with vacuum component, you can reference vacuum/mqtt.py

demo.py is not for specific brand or communication protocol, it basic use as an example for other developers and for unit test purpose.

[rytilahti]

@syssi has a rice cooker, so pinging him if he has some ideas / to let him know this is being discussed here.

[balloob]

Had some time for this, this looks ok. Most of the linked examples companies like the ones for smart kettle or coffeemaker will probably be out of business in a couple of years, but sure let's add them to the mix ☕️ .

[anna-oake]

Take a look at this. https://github.com/aprosvetova/xiaomi-kettle

[arbreng]

Awesome, ty. Looking into this over the weekend

[niemyjski]

I think this would be super useful

[Hypfer]

I second this.
I've taken @aprosvetova s research and built an MQTT Bridge for the Mi Smart Kettle, but I can't really use it within HA because it doesn't match any existing entity.

[ajdezigns]

https://github.com/roblandry/pywemo/tree/crockpot This would make a good addition to this component

[ajmarks]

This would be fantastic. I'm currently working on a Python API for GE kitchen appliances, starting with my oven. I'd love to create an HA integration as well, but without a matching entity type, all I can do is be hacky with sensors and switches (and maybe water heaters?).

[ajmarks]

To maybe add a little motivation here, I've been able to implement a halfway (well, eighthway, anyway) decent oven and a pretty solid fridge using the WaterHeaterEntity for GE appliances. It's not ideal, but it's a very good start. This make me think that could be used to bootstrap a proper Cooker or Cooler entity.

[mrbeamstx]

@ajmarks would you mind sharing how you created this card. Newbie with HA but loving in.

[sebirdman]

I've begun thinking about this for my Traeger grill integration. While some of this makes sense for my cooker some of it doesn't quite line up with what I'd need.

I'm curious why this proposal and the climate/water heater entities are so specific?

It feels like it would be more powerful to have all these entities become collections of even smaller parts such as:

• TemperatureControlEntity

This would handle setting a temperature and maintaining a temperature. Could have the properties suggested above.

• OptionEntity

This would be an entity that basically lets you set modes in a drop down of some kind.

These two small entities would let any kind of device take advantage of these kinds of features. This way we can handle edge cases in higher level logic instead of continuing to duplicate entity logic (like we have now with climate and water heaters)

I can create more formal proposals for these if anyone's interested.

Edit: Renamed SwitchEntity because of course that already exists xD

[arbreng]

It's really specific because I didn't have a very good understanding of how entities worked at the time, or how to properly decompose them. Also I think Integrations didn't exist as a concept yet back then?

I definitely agree w/ what you put here, and would close this in favor of what you've suggested. The Anove, Taegor, etc specific logic would live in the Integration, which would make use of these small decomposed entities.

EDIT: Oh, I see the issue was already closed. Yeah, your idea sounds better :D

[blakadder]

I have a few former Tuya, now Tasmota MQTT based cookers if you need some info

[ex-nerd]

This would also help extensions like https://github.com/simbaja/ha_gehome/ that currently represents ovens as water_heater entities (the cooktops themselves show up as a mix of sensor and binary_sensor, which seems fine).

[matchett808-gh]

Is this thread still active?

I started #945 for adding cookers (and might've ended up on a workable 'generic appliance' domain):

I sortof danced around the idea in my post but a generic 'appliance' with run/pause and modes (other optional things like 'run for x', 'set temperature' etc might be useful) - this would serve things like cookers/ovens and things like dishwashers and laundry machines (could even see showers, kettles, EV chargers - and plenty more managing to fit quite easily into this generic)

[mikey0000]

Yeah I believe it's a bit ui and also a fixed set of services. 16/08/2023 6:05:28 pm Allen Porter ***@***.***>:

…

Is that about how it shows up in the frontend? (e.g. you include all the same controls on a UI panel?) I'm curious how that would compare to the device panel for that device, with all its entities for the device shown together. It seems like given this discussion has been open since 2018, going with separate entities could be a much faster path forward given *operation* was the only unique attribute in your proposal. — Reply to this email directly, view it on GitHub[#501 (reply in thread)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AALDOPLGWKQPWIA5JRG6U2TXVRPIDANCNFSM4W6QIDPA]. You are receiving this because you commented.[Tracking image][https://github.com/notifications/beacon/AALDOPN3PU3KVMOWVRGU233XVRPIDA5CNFSM4W6QIDPKYY3PNVWWK3TUL52HS4DFWFCGS43DOVZXG2LPNZBW63LNMVXHJKTDN5WW2ZLOORPWSZGOABTMZKI.gif]

[iRonin]

I'm looking to integrate Dreo ChefMaker. To my surprise there is no Cooking Platform in HA.
There is already https://github.com/tsunglung/XiaomiAirFryer
Some modes and params of ChefMaker:

COOKING_MODES = [
    'Air Fry', 'Roast', 'Defrost', 'Toast', 'Reheat', 'Bake', 'Broil', 'Dehydrate'
]

COOKING_RANGES = {
    'Air Fry': {'temp_range': (200, 450), 'duration_range': (1, 3600)},
    'Roast': {'temp_range': (200, 450), 'duration_range': (1, 3600)},
    'Defrost': {'temp_range': (100, 150), 'duration_range': (1, 3600)},
    'Toast': {'temp_range': (200, 400), 'duration_range': (1, 600)},
    'Reheat': {'temp_range': (200, 400), 'duration_range': (1, 600)},
    'Bake': {'temp_range': (200, 400), 'duration_range': (1, 3600)},
    'Broil': {'temp_range': (350, 450), 'duration_range': (1, 3600)},
    'Dehydrate': {'temp_range': (100, 175), 'duration_range': (1, 43200)}
}

Will be working on it here https://github.com/iRonin/hass-dreo/tree/chefmaker-support

[mikey0000]

As a side note Broil is an American term not used by the rest of the world (to my knowledge) definitely not used in New Zealand, it's grill here

[ajdezigns]

Turns out you’re right! The term is unique to North America (Canada, USA, & Mexico)

[AJediIAm]

The split between vacuum and lawn mower some time ago was a nice improvement which got me thinking about this topic. I wasn't aware of architectural discussions at the time. when I noticed this discussion, it surprised me that it is still open. With the introduction of Voice, controlling appliances and differentiating an appliance from other devices is becoming more and more relevant.

As discussed above:
The trend seems to be to have specific entity types such as Vacuum and Lawn Mower. Both are robots which do almost the same thing.
It might be difficult or overkill to define all cooking appliances as their own thing. A stove, coffee machine and microwave are very different things. Then there are the combined devices like combi-ovens which have multiple functions in a single appliance.

Based

Proposal 1:
introduce "appliance" entity.

Pro's:

• generic entity to capture basic functionality for various devices from washing machine to microwave.
• Catch-all solution which still allows for specific entities to be added later.
  Con's:

• it can either limit the defined properties of cause confusion due to unambiguous use of properties for different types of appliances.

Proposal 2:
Introduct "cooking appliance", "washing appliance" and (optionally) "generic appliance"

Pro's:

• Allow for detailed properties with unambiguous function for food preparation and washing dishes or clothes.
• No confusion whether a multifunctional oven is a oven, microwave or steamer.
  Con's:

• Still a need for many custom parameters which could lead to deviation between different integrations providing the same type of device.

Proposal 3:
Introduce "Cooker appliance" (or just "Cooker") with the intent of adding an entity for every type of appliance.

Pro's:

• Best standardized definition
  Con's:

• Lots of entity types to be added to cover everything.

Personally, I would lean towards option 2 since this gives the best bang for your buck. It allows for a large number of appliances to be easily captured and organized.

[iRonin]

Maybe it should be "Kitchen" platform and "kitchen appliances" - consider an "ice maker" - definitely not a "cooling appliance". Maybe "Food & beverage" platform so that it's not "room" specific.

[satmandu]

Hello all, I'd like to get my Anova Precision Cooker 1.0 (Bluetooth-only) supported. I see this discussion has been going for six years now.

The current Anova integration appears to use the anova API, which is being deprecated for older devices (and which if I understand it was never going to work with the even older Bluetooth devices anyways.)

Maybe I try to bring the original PR from @arbreng to a workable state? Do we still need a new entity for this, or is there something I can glob onto? (What is the anova wifi integration using?)