*.*_SCHEMA deprecations

[giscus[bot]]

._SCHEMA deprecations

https://developers.esphome.io/blog/2025/05/14/_schema-deprecations/

[OlegSchekotin]

Hello, ESPHome shows a deprecation warning for cover.COVER_SCHEMA, and says it will stop working in 2025.11. Please update to cover_schema(...). Details:

[jesserockz]

Maybe you didn't paste the details?
All of the code inside ESPHome has been updated to not produce these warnings, it must be coming from an external_component and the log message itself should say what one.

[OlegSchekotin]

WARNING Using cover.COVER_SCHEMA is deprecated and will be removed in ESPHome 2025.11.0. Please use cover.cover_schema(...) instead. If you are seeing this, report an issue to the external_component author and ask them to update it. https://developers.esphome.io/blog/2025/05/14/_schema-deprecations/. Component using this schema: bus_t

[randybb]

https://github.com/andrein/esphome-BusT4 or maybe https://github.com/pruwait/Nice_BusT4 ? and yes...this is an external component, which is in hands of it's creator which hast to fix it.

[PaulWieland]

Is it intentional to leave out LIGHT_SCHEMA from this change?

[jesserockz]

Yes, LIGHT_SCHEMA was more complex and so I left it out of this round of deprecations.
I did add a new light.light_schema(...) function though which can already be used. It is used by the demo component only at this time in the ESPHome codebase.

[ssieb]

I migrated my external components before I realized that it wasn't on the list. 🤣
Actually, I realized half way through but decided I might as well do it anyway.

[fnordpojk]

I am seeing this for the built in component fan:

WARNING Using fan.FAN_SCHEMA is deprecated and will be removed in ESPHome 2025.11.0. Please use fan.fan_schema(...) instead. If you are seeing this, report an issue to the external_component author and ask them to update it. https://developers.esphome.io/blog/2025/05/14/_schema-deprecations/. Component using this schema: fan

Zero external_components in use for this.

[jesserockz]

Woops, somehow the tuya fan was missed. Thank you 🙏

[pienjo]

I came here because my external component apparently needs fixing. However, this page gives me almost no useful information.

I am an embedded software engineer. I understand things sometimes need to change, and that this sometimes requires breaking changes. But tell me what needs changing, and how - or at least point me to a reference implementation.

I don't want to be an ESPHome developer. You don't want me to be an ESPHome developer. The fastest I am done with these changes, the better it is for both of us.

Please don't force me to reverse engineer your tangled web of python and "C++" code just to keep my ceiling fan going.

[bdraco]

I understand your frustration, and you're absolutely right - maintaining an external component shouldn't require becoming a core developer. Unfortunately, there aren't comprehensive migration guides available at this time, which does make it challenging when breaking changes occur.

Here's a concrete example of how the ratgdo external component handled a recent breaking change when ESPHome moved from COVER_SCHEMA to cover_schema():

Before (old pattern):

CONFIG_SCHEMA = cover.COVER_SCHEMA.extend(
    {
        cv.GenerateID(): cv.declare_id(RATGDOCover),
        cv.Optional(CONF_ON_OPENING): automation.validate_automation(
            {cv.GenerateID(CONF_TRIGGER_ID): cv.declare_id(CoverOpeningTrigger)}
        ),
        # ... other config options
    }
).extend(RATGDO_CLIENT_SCHEMA)

After (new pattern):

CONFIG_SCHEMA = (
    cover.cover_schema(RATGDOCover)  # Changed from COVER_SCHEMA to cover_schema()
    .extend(
        {
            cv.Optional(CONF_ON_OPENING): automation.validate_automation(
                {cv.GenerateID(CONF_TRIGGER_ID): cv.declare_id(CoverOpeningTrigger)}
            ),
            # ... other config options
        }
    )
    .extend(RATGDO_CLIENT_SCHEMA)
)

This pattern applies to other component types too:

• sensor.SENSOR_SCHEMA → sensor.sensor_schema(MySensor)
• binary_sensor.BINARY_SENSOR_SCHEMA → binary_sensor.binary_sensor_schema(MyBinarySensor)
• switch.SWITCH_SCHEMA → switch.switch_schema(MySwitch)
• light.LIGHT_SCHEMA → light.light_schema(MyLight) (not yet rolled out)

The key change is that the new functions take your component class as a parameter, but otherwise the structure remains the same.

I know having to dig through other components' code to figure out these changes isn't ideal. Your feedback highlights an important gap in the project's documentation. If you're stuck on a specific issue with your component, feel free to share the error message - sometimes these fixes are simpler than they appear.

[pienjo]

Thank you for your kind and swift response. This information helped me a lot; I managed to get things working again (for now, at least).

Part of the problem is probably that I don't really know what I'm doing to begin with; a long time ago I converted a ceiling fan controller to ESPhome, using someone else's custom component. When support for custom components was removed last february, I tried to clean up that code and convert it into an external component.

This wasn't plain sailing - and most of it was "monkey see, monkey do", copying from other components but not really knowing which ones should be considered reference material and which ones aren't.

This probably would've been OK if this was some kind of on-boarding excercise, but there lies the rub:

• Since it's my own component, it won't get any review. In fact, if I were to review my own work I'd reject it, because it's just beyond the "works well enough for me" stage.
• Since this is a one-off project, any knowledge I gained will probably be gone by the time I need it again (Most of my ESPhome projects don't require custom hacks beyond the odd lambda expression, which is quite amazing in its own right).

This kind of harks back to the experiences from @robertklep in https://community.home-assistant.io/t/please-consider-bringing-back-custom-components/853819 . Maybe there is a missing gap between the old custom components, and having a full-blown external component.

Either way, thanks again.

[ssieb]

That example is not quite correct. The class is in the cover_schema(RATGDOCover), so you don't need the cv.GenerateID() line.

[nic6911]

I have a component here that uses modbus - and it throws warnings on SENSOR_SCHEMA, NUMBER_SCHEMA and SWITCH_SCHEMA - but i do not see that i actually use those directly in my code... Is this something related to modbus_controller? Or can anyone point me towards where i need to look to fix this: https://github.com/nic6911/esphome_components/tree/main/components/wavinahc9000v2
?

[ssieb]

What is your config?

[nic6911]

An example config is here: https://github.com/nic6911/ESP32_Modbus_Module/blob/main/esphome_example_code/WavinAHC9000V2_example.yaml

[nic6911]

it does seem like it is in the modbus_controller component... but isn't that a native ESPHome component?

[ssieb]

Your packages used to be pulling in an old version of that. Could that still be in a config somewhere or maybe stuck in the build system? Try doing a clean build.

[nic6911]

doh... found it - i referenced to a deprecated branch of the component...