Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Climate 1.0 #23899
Most platform will support now a lot more features. But Somethings was also cleaned out:
Looks like a small change but they are massive. I look over all climate API and also external Interfaces like Voice Assistant, and that is the result they should be able to cover our cases.
Most of the problem was that a lot of stuff was mixed because of history for that component. Like Away mode, they were initially added and later as the hold modes come too, they were never strict merged back. Some integration was added hacks to offload it from hold mode.
That is the result of hours and hours research of what we have and what exists and how the device manufacture implement things.
I don't think our old climate was bad because no platform supports so many different devices and I learned a lot from that code. The problem was only, that no one had the overview to make a clean setup.
Implement the subset of over 100 comments from home-assistant/architecture#22
This pull request includes an updated UI to work with the new schema.
Some HA hardware interfaces (components) use a fake away. That is something that is not part of an interface schema. Logic abstraction or components level 2 allowed to fake logic but not on level 1 (hardware interfaces).
The main thing that is new is presets Things like eco mode, away mode, hold mode, manual mode, etc are now all presets and set via
Zigbee thermostats support a true "hold" mode which means that it does not execute the internal schedule, it just holds the current setpoints. It also optionally allows this hold mode to self disable after some configurable time.
I think it would be nice to at least support this hold mode somehow. Could the "preset" accommodate this?
I just want to suggest again that hvac_state is renamed to hvac_mode. You have hvac_mode(s) plurar for the list, so the current aught to be the singular.
I'd suggest the same for presets and preset. Or preset_mode and preset_modes for list. That way it's clear they belong together.
I am trying to migrate evohome to the new climate platform, PR #23969
I have a difficulty with
supported_features = SUPPORT_TARGET_TEMPERATURE | SUPPORT_CURRENT_HVAC | SUPPORT_PRESET_MODE
In the Web UI (
I do get the Target Temperature in the UI.
If I have
 More info:
Jul 8, 2019
2 of 7 checks passed
We did it! We made a lots of changes and things might have been broken. If you find a bug in one of the integrations or have a PR with improvements, please tag PRs with
Khole and I are working on fixes to the Hive climate code, which we think we have completed now and re-adding Hive hotwater support as water_heater after it was removed from climate.
We are still ironing out some bugs in the water_heater, but if not complete before Climate 1.0 goes live we will lose hotwater / water_heater support for Hive (assuming no one else is working on this)
How do you recommend we proceed? We were aiming for one PR with the new file for water_heater and the fixed file for climate.