jmcollin78/versatile_thermostat: the Home Assistant thermostat that swallows your heating automations

A thermostat that takes the automations away from you

Versatile Thermostat is a highly configurable virtual thermostat for Home Assistant that transforms any heating equipment, radiators, air conditioners, heat pumps and the rest, into an intelligent and adaptive system. Its stated aim is to consolidate and centrally control several different heating systems while automatically optimising energy consumption.

The argument for it is made in the second paragraph of the README, and it is the argument that matters. All the typical heating events, nobody home, activity detected in a room, a window open, power load shedding, are natively managed by the thermostat, so you do not need complicated scripts and automations to manage your thermostats. That is the real feature. Anyone who has built a heating setup in Home Assistant knows that the automations accumulate, that a window sensor needs to suspend a schedule, that presence has to interact with a target temperature, and that the energy price has to reach the boiler. Here, those are configuration items of one component rather than a pile of YAML.

The component is a complete rewrite, and an upgrade, of the Awesome thermostat component by dadge, with added features. The project therefore sits on the shoulders of an approach that has been in Home Assistant for years.

It is a HACS custom integration, MIT licensed, with the documentation site at versatile-thermostat.org, and a separate repository for the Lovelace UI card, so the interface and the logic live in two projects.

TPI, auto-TPI and the slope of the temperature curve

The README's glossary is where the interesting engineering is, because it defines the terms the rest of the documentation assumes.

TPI and auto-TPI are the algorithms the component runs on, and the claim attached to them is that the thermostat adapts to your home and your habits, providing optimal comfort and a significant reduction in heating bills. The glossary does not expand TPI, but it does explain the measurement it depends on.

EMA is the Exponential Moving Average, used to smooth sensor temperature measurements. It represents a moving average of the room's temperature and is used to calculate the slope of the temperature curve, which would be too unstable on the raw data. The slope is measured in degrees per hour, Celsius or Kelvin, and is positive when the temperature is increasing and negative when it is decreasing, and it is calculated based on the EMA.

That is the core of the control loop in three definitions. A room sensor reports a temperature, the raw reading is noisy, so it is smoothed, and the slope of the smoothed curve tells the component how fast the room is warming or cooling. From that, a proportional controller can decide how much heat to request, and the auto variant adjusts the constants as it observes how the home responds, which is the learning part of the description.

The glossary also shows the care taken with device types. A TRV is a thermostatic radiator valve equipped with a valve that opens or closes to allow hot water to pass. An AC is air conditioning, and there the temperatures are reversed, so Eco is warmer than Comfort, which is warmer than Boost, and the algorithms take that information into account. That inversion is the kind of detail that separates a component that works for cooling from one that only works for heating.

Version 10 introduced plugins, and every release since has moved a feature into one

The release history in the README is a lesson in how the project evolves, because several features have moved out into plugins.

Release 10.0 introduced the plugin mechanism, which allows external integrations to be used as plugins for VTherm, with the list of available plugins on the project website. Release 10.1 added auto start and stop mode selection, where a new `select` entity chooses the mode applied when a stop condition is detected, `Off` by default, or `Fan only` or `Dry`, and those two are only proposed when the underlying appliance supports them. The same release changed self-regulation, which is now disabled when an `over_climate` thermostat is not in `Heat` or `Cool` mode, so the original non-regulated setpoint is sent to the device.

Release 10.2.0 moved the auto fan feature out to an external plugin, `vtherm_auto_fan_extended`, with the original legacy version still available inside VTherm but requiring explicit disabling in the thermostat configuration before the plugin is used. Release 10.3.0 made the power units configurable, with W as the default, and migrated existing entries using the historical device power value, treating values above 100 as W and other values as kW. Release 10.4.0 added `current_humidity` from an external sensor for all thermostat types, selectable in the Humidity menu or detected automatically on the room temperature sensor device, and gave `over_valve` thermostats the same valve control parameters as `over_climate` ones, namely `opening_threshold_degree`, `min_opening_degrees`, `max_closing_degree` and `max_opening_degrees`, plus Sleep mode for `over_valve`, which displays the thermostat as off and sends a raw 100% opening request without requesting central boiler heating.

The pattern is a strangler migration rather than a rewrite, and it is the kind of approach that keeps a working system working while features move out.

The migration advice is more careful than most

The 10.5.0 release note is the most detailed, and it is about a feature that has moved into a plugin, the `vtherm_heating_failure_detection` plugin, which provides central settings and per-VTherm overrides, and whose forms pre-fill the existing core settings to make migration easier.

Two rules are stated. During the transition period, plugin settings take precedence, while values not defined by the plugin continue to use the legacy core configuration, and the legacy feature has to be disabled for a VTherm before the plugin is enabled, to avoid duplicate configuration.

The second rule is about entity identity, and it is the kind of detail that breaks a user's dashboard if it is ignored. The heating failure binary sensor is now provided by the plugin, and when this can be done without a conflict, its existing `entity_id` is retained so that dashboards and automations keep working. If the legacy sensor is disabled and the plugin entry reloaded, and the sensor remains active, Home Assistant may create a new `entity_id` that existing consumers have to be pointed at.

The 10.3.0 note has the same care about statistics. Changing the power unit to kW produces a repair notification such as the unit of `sensor.total_power_active_for_boiler` was changed, and the documentation explains that this is expected because the unit was previously unspecified, and that the fix is to select the repair action to update the unit of long term statistics.

Both of these are examples of a component author thinking about the user who already has the thing installed, rather than about the person configuring it for the first time.

Where this is the wrong component

The first wrong case is a single room with a self regulating TRV. A thermostatic radiator valve decides its own opening from its own temperature, and if that is the only heating device in the house, a central controller adds a layer without adding a decision. The value of VTherm appears with several devices, several rooms, or several types of equipment, and it is in the coordination.

The second wrong case is a setup you want to keep simple forever. This is a large integration with an entity model, a per device configuration, a central configuration, plugins, a glossary and a documentation site, and the README's own list of features, presence, motion, window and power load shedding, all natively handled, is a list of things you are delegating to the component rather than controlling yourself. If you would rather understand every automation in your own YAML, this is a different relationship with your system.

The third is a hard requirement for a specific UI. The Lovelace card lives in a separate repository, and the screenshots in the README are of that card. The component works without it, but the experience the documentation describes is tied to a card you install and update separately.

The fourth is an environment where custom components are not permitted. This is a HACS custom integration, so it runs in your Home Assistant instance with the trust that entails, and the dependency list in `requirements_dev.txt` and `requirements_test.txt` is what a developer needs to work on it rather than what an end user installs.

On the state of the project, the current release is 10.5.1, published on 2026-10-12, and there are beta tags for it from two days earlier, which is a sensible release process. The last push was on 2026-10-13, the repository is not archived, and the licence is MIT. The project is developed in the open with contributing guides in English, French, German, Czech and Polish, and a devcontainer, a VS Code configuration, pylint, pyright and black configured with a 180 character line length.

Editorial conclusion

Adopt versatile_thermostat if you run Home Assistant with more than one heating device and want one place that decides when to heat, since the TPI and auto-TPI algorithms and the natively handled events remove the layer of automations that every heating setup otherwise accumulates. Do not adopt it if you have a single room with a smart TRV that already regulates itself locally, since the component adds a central controller where none is needed. Verify first which of your devices are of the over_climate or over_valve type and that the matching documentation under `documentation/en/` covers them, that your HA version is compatible with the current release, 10.5.1 from 2026-10-12, and that you read the migration notes for the features you already use, because version 10.5.0 moves heating failure detection into a plugin and version 10.3.0 changes the unit of the power sensors.

Frequently asked questions

Official sources

1. jmcollin78/versatile_thermostat on GitHub
2. License: MIT
3. Project website
4. README
5. Releases