Skip to content

Blog

  • 2 min read

*.*_SCHEMA deprecations

In order to align all of the top level platform components (listed below), we are deprecating the *_SCHEMA constants that are present. Some examples are SENSOR_SCHEMA, SWITCH_SCHEMA and so on.

Each entity platform component has a matching *_schema(...) function which takes the class type and common schema defaults as arguments. There are plenty of examples in the ESPHome codebase of these.

This will become a breaking change in ESPHome 2025.11.0, set to release around the 19th of November 2025. The breaking PRs will be merged right after the 2025.10.0 release goes out around the 15th of October 2025.

If you are a maintainer of external_components that use these constants, please update them to use the new *_schema(...) functions. If you are a user of external_components and see the warning in your install logs, please reach out to the maintainers of those components and ask them to update their code.

external_components are able to import the ESPHome version into their python file in order to support older versions in the cases where the relevant *_schema(...) function was not added yet.

List of affected components

  • alarm_control_panel
  • binary_sensor
  • button
  • climate
  • cover
  • datetime
  • event
  • fan
  • lock
  • media_player
  • number
  • select
  • sensor
  • switch
  • text
  • text_sensor
  • update
  • valve

Reference Pull Requests

  • 2 min read

About the removal of support for custom components

ESPHome's "custom component" mechanism was a holdover from Home Assistant's feature by the same name. It existed before external components and offered a way to "hack in" support for devices which were not officially supported by ESPHome.

Why were custom components removed?

There are several reasons for this change.

  • Custom components are very fragile:

    • There is no validation. You can easily configure a custom component incorrectly and there will be no warning.
    • Types are not checked. You might incorrectly pass a variable of an incorrect type or unit to a custom component resulting in compiler errors, unexpected behavior and/or crashes.
    • Custom components are difficult to use. You have to manually copy all of the custom component's files into just the right location on your system or else you will receive compiler errors and the component won't work.
    • Custom components lack flexibility and almost always require C++ code changes when you want them to work even slightly differently than the original author intended/designed. For example, a simple change of input units (cm to m, for example) could require significant changes to the C++ code, depending on how the original author designed the custom component.

  • External components initially require a bit more effort by the developer but are ultimately more robust and are easier to use and share:

    • Just like any other ESPHome component/platform:
      • They are configured entirely in YAML.
      • Their YAML configuration is validated.
    • They do not require the user to:
      • Manually copy files onto their system.
      • Touch/edit any C++ code.
    • They tend to be more flexible since they are configured in YAML (as opposed to editing C++ code to make changes).

What's the difference?

Custom components are typically (more or less) just the runtime part of an ESPHome component/platform. On the other hand, external components are just like any other ESPHome component -- the only difference is that they are external in the sense that they are not "officially" a part of ESPHome.

In terms of implementation, custom components just lack the Python part of an ESPHome component, specifically:

As such, most custom components can be made into external components simply by adding the required Python parts to make the custom component into a proper, complete ESPHome component.

What's next?

We encourage all custom component developers to extend their custom component(s) into proper external components; doing so will make your custom component easier to share and use. As you do so, be sure to have a look at the the sections above as it walks through ESPHome (component) architecture. In addition, it's often helpful to take a look at other, similar components and adapt them to fit the needs of your custom component. For common hardware devices such as sensors, this is often a reasonably trivial exercise and we are happy to help you along!

  • 1 min read

Hello Developers!

Welcome to the first post of this new ESPHome Developer Documentation. This is a place where you can find all the information you need to start developing for ESPHome. This website will cover everything you need to create components and how to structure your code so that it will be easy to maintain and understand.