Summary
ESPHome has deprecated get_preference_hash() in 2026.2.0, with removal planned for 2027.1.0. A new make_entity_preference<T>() helper has been added to EntityBase.
When ESPHome implements get_preference_hash_v2() to fix preference hash collisions (e.g. UTF-8 names, names that sanitize identically), the migration logic will be inside make_entity_preference_(). External components that continue using get_preference_hash() directly will not have their preferences automatically migrated, meaning users will lose saved state.
Current usage
This component has a custom get_preference_hash() override in multiple places:
In components/schedule/schedule.h:
uint32_t get_preference_hash() const { return this->get_object_id_hash(); }
In components/schedule/data_sensor.cpp:
uint32_t DataSensor::get_preference_hash() const {
if (this->parent_schedule_ != nullptr) {
uint32_t parent_hash = this->parent_schedule_->get_object_id_hash();
uint32_t label_hash = fnv1_hash(this->label_);
return parent_hash ^ label_hash;
}
return fnv1_hash(this->label_);
}
And the hash is used to create preferences:
uint32_t hash = this->get_preference_hash();
this->array_pref_->create_preference(hash);
Recommended migration
The Schedule class usage is straightforward — replace calls to get_preference_hash() / get_object_id_hash() with make_entity_preference<T>().
The DataSensor class has a custom composite hash (parent object_id XOR label). This doesn't fit the standard make_entity_preference<T>() pattern directly. If DataSensor extends EntityBase, you can use make_entity_preference<T>() directly (it will use the entity's own identity). If the composite key is intentional for disambiguation, you may need to keep a custom approach but should stop relying on get_object_id_hash() which has the same collision problems.
For the simple case:
// Before:
this->pref_ = global_preferences->make_preference<T>(this->get_preference_hash());
// After:
this->pref_ = this->make_entity_preference<T>();
References
Summary
ESPHome has deprecated
get_preference_hash()in 2026.2.0, with removal planned for 2027.1.0. A newmake_entity_preference<T>()helper has been added toEntityBase.When ESPHome implements
get_preference_hash_v2()to fix preference hash collisions (e.g. UTF-8 names, names that sanitize identically), the migration logic will be insidemake_entity_preference_(). External components that continue usingget_preference_hash()directly will not have their preferences automatically migrated, meaning users will lose saved state.Current usage
This component has a custom
get_preference_hash()override in multiple places:In
components/schedule/schedule.h:In
components/schedule/data_sensor.cpp:And the hash is used to create preferences:
Recommended migration
The
Scheduleclass usage is straightforward — replace calls toget_preference_hash()/get_object_id_hash()withmake_entity_preference<T>().The
DataSensorclass has a custom composite hash (parent object_id XOR label). This doesn't fit the standardmake_entity_preference<T>()pattern directly. IfDataSensorextendsEntityBase, you can usemake_entity_preference<T>()directly (it will use the entity's own identity). If the composite key is intentional for disambiguation, you may need to keep a custom approach but should stop relying onget_object_id_hash()which has the same collision problems.For the simple case:
References