I found the source of the problem and the solution does not involve copying homeassistant/components/climate/const.py.
The 0.89 version of MQTT’s climate.py contains a subtle difference from the 0.88.1 version of the same file.
Here’s how 0.88.1 gets STATE_AUTO:
from homeassistant.components.climate import (
ATTR_OPERATION_MODE, DEFAULT_MAX_TEMP, DEFAULT_MIN_TEMP,
PLATFORM_SCHEMA as CLIMATE_PLATFORM_SCHEMA, STATE_AUTO, STATE_COOL,
Here’s how 0.89 gets STATE_AUTO:
from homeassistant.components.climate.const import (
ATTR_OPERATION_MODE, DEFAULT_MAX_TEMP, DEFAULT_MIN_TEMP,
STATE_AUTO, STATE_COOL,
0.88: homeassistant.components.climate
0.89: homeassistant.components.climate.const
Just enough to break my customized climate.py which is based 0.88 source code.
I updated my custom version and now 0.89 loads it successfully (and, most importantly, it works).
So the solution is … troubling. Maybe I misunderstood the reasoning behind this architectural change (no more partial custom component overlays) but I thought one factor was to ensure the customized component’s integrity in the face of underlying changes.
Today, if you want, you can override the Hue light platform, but not the other parts of the Hue integration. If a future update evolves the Hue component, removing or changing internal methods that the custom platform relied upon, the custom platform will start failing (like this report).
To avoid this, we’re going to no longer allow custom components to be partial overlays
Yet this was an example of a custom component requiring additional modifications in order to adapt to underlying changes. It failed it the same way when I had attempted to use a customized version of climate.py based on 0.80 in version 0.86. There were so many changes between 0.86 and 0.80 that it was understandable that my customized component would fail.
To be clear, I’m not finger-pointing but simply wish to understand how this architectural change didn’t insulate my customized climate.py from an underlying modification.