Persist resolved unit type for Number entities as well as Sensor entities

[ccutrer]

Otherwise we were setting the unit on the channel definition, but not being applied to the incoming state, so if the linked Item uses a different unit, it wasn't getting converted correctly.

[Copilot]

Pull request overview

This pull request refactors unit type resolution logic to ensure that the resolved unit is persisted in the configuration for both Number and Sensor entities. Previously, the unit was set on the channel definition but not applied to incoming states, causing unit conversion issues when linked Items used different units.

Key Changes:

• Centralized unit type resolution logic by moving it from SensorMessageHandler to AbstractMessageHandler
• Updated both SensorMessageHandler and NumberMessageHandler to use the shared resolution method and persist units in configuration

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
AbstractMessageHandler.java	Added Configuration parameter to resolveNumericItemType() method to enable unit persistence; method now stores valid units in the configuration
SensorMessageHandler.java	Removed duplicate unit validation logic and removed unused UnitUtils import; now delegates to shared resolveNumericItemType() method
NumberMessageHandler.java	Updated resolveNumericItemType() call to pass configuration parameter for unit persistence

Comments suppressed due to low confidence (1)

src/main/java/no/seime/openhab/binding/esphome/internal/message/AbstractMessageHandler.java:195

• Variable deviceClass may be null at this access as suggested by this null guard.

            itemTypeToUse = deviceClass.getItemType();

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.