Sensors have no state_class, so Home Assistant never records long-term statistics

[Nathan-Cunha]

Thanks for this integration — it's the only working way to get a Geely EX5 into Home Assistant. I'm running it on HA 2026.7.4 (currently via @alexandrepossebom's fork, since I'm in Brazil and needed the multi-region login fix, but this report applies to sensor.py in both trees — the code is identical here).

Problem

None of the entities built from SENSOR_SPECS set state_class, so Home Assistant's recorder never promotes them to long-term statistics. Dumping the attributes of every sensor on my EX5:

sensor.geely_ex5_bateria            84.0     state_class=None  device_class=battery   unit=%
sensor.geely_ex5_autonomia          349      state_class=None  device_class=distance  unit=km
sensor.geely_ex5_hodometro          4646.0   state_class=None  device_class=distance  unit=km
sensor.geely_ex5_consumo_medio      16.4     state_class=None  device_class=None      unit=kWh/100km
...

For comparison, another vehicle integration on the same instance reports state_class=total_increasing on its odometer and measurement on battery/range.

Practical consequences:

• statistics-graph cards render empty — no "km per day", no monthly charging totals, no daily min/mean/max battery.
• No aggregation survives recorder.purge_keep_days; history is limited to the raw retention window.
• utility_meter helpers still work (I'm using them for weekly/monthly km), but they only count forward from creation and can't backfill from statistics.

Suggested change

SENSOR_SPECS is a tuple of (key, friendly_name, path, unit, device_class, value_type, value_map). Adding an 8th element and passing it through GeelySensor.__init__ would be enough:

if state_class is not None:
    self._attr_state_class = state_class

Proposed values:

Sensors	state_class
battery, range, interior_temp, exterior_temp, speed, avg_speed, avg_consumption, 12v_battery, 12v_voltage, tire_pressure_fl/fr/rl/rr, time_to_full_min, days_to_service, distance_to_service	MEASUREMENT
total_mileage	TOTAL_INCREASING
trip_meter	TOTAL (resettable by the driver, so TOTAL_INCREASING would log false resets)
engine_state, park_brake, charger_connected	none — these are enums

One caveat worth checking: distance_to_service and days_to_service count down, so MEASUREMENT is right for them; TOTAL_INCREASING would be wrong.

Happy to send a PR if you'd like — just let me know whether you'd prefer the extra tuple element or a small dataclass for the specs.