fix: specify unit_class in import_statistics metadata (fixes #623)

[Marlboro62]

Fixes #623

Ajoute la clé unit_class dans les 4 dicts metadata envoyés à recorder/import_statistics (kWh → "energy", EURO → None), pour éliminer le warning de dépréciation côté Home Assistant.

[bidord]

@Marlboro62

J'ai testé ton fix sur ma prod avec la dernière version d'Home Assistant (2026.9.0). Les avertissements concernant unit_class ont bien disparu, mais il reste les avertissements concernant mean_type:

2026-09-03 10:57:33.329 WARNING (MainThread) [homeassistant.components.recorder.websocket_api] WS command recorder/import_statistics called without specifying mean_type in metadata, this is deprecated and will stop working in HA Core 2026.11

Cf websocket_api.py L605-L616 :

    if "mean_type" not in metadata:
        _LOGGER.warning(
            "WS command recorder/import_statistics called without specifying "
            "mean_type in metadata, this is deprecated and will stop working "
            "in HA Core 2026.11"
        )
    if "unit_class" not in metadata:
        _LOGGER.warning(
            "WS command recorder/import_statistics called without specifying "
            "unit_class in metadata, this is deprecated and will stop working "
            "in HA Core 2026.11"
        )

PS: Pour ceux qui veulent tester rapidement, voilà une image docker de cette branche:
ghcr.io/bidord/myelectricaldata:0.13.4-fix-635

[m4dm4rtig4n]

Merci pour le patch @Marlboro62 🙏 J'ai relu le diff et vérifié les valeurs contre le code de HA Core 2026.9.0 — elles sont exactes :

• recorder/statistics.py (L2786-2800) calcule précisément le même fallback que ce que tu envoies : STATISTIC_UNIT_TO_UNIT_CONVERTER["kWh"].UNIT_CLASS == "energy", et EURO étant absent de la map → None.
• La validation en aval passe aussi : unit_class="energy" avec unit_of_measurement="kWh" est dans EnergyConverter.VALID_UNITS, donc pas de HomeAssistantError.
• Le schéma accepte bien None : vol.Optional("unit_class"): vol.Any(str, None). La clé présente à None suffit à lever le warning (le test est if "unit_class" not in metadata).
• Et les 4 dicts sont bien les seuls concernés (grep import_statistics src/ → un seul fichier).

Avant de merger, deux points bloquants à mon avis :

1. mean_type manque, même échéance 2026.11

Comme relevé par @bidord ci-dessus, HA loggue deux avertissements côte à côte (websocket_api.py L605-616), et l'issue #623 mentionne les deux. En l'état la PR n'en supprime qu'un : les 4 dicts envoient toujours has_mean: False sans mean_type, donc Fixes #623 ne serait pas tenu et il resterait à repasser sur le même fichier avant 2026.11.

Le complément est symétrique de ce que tu as déjà fait — dans les 4 mêmes dicts :

"has_mean": False,
"mean_type": 0,  # StatisticMeanType.NONE

L'entier nu passe la validation (vol.In(StatisticMeanType.__members__.values()) + vol.Coerce, et StatisticMeanType est un IntEnum avec NONE = 0), donc pas besoin d'introduire une dépendance à homeassistant. has_mean peut rester à côté : la colonne existe toujours dans db_schema._StatisticsMeta en 2026.9, il n'y a pas de risque de TypeError dans from_meta.

2. Risque de casse sur HA < 2025.11 (vaut aussi pour unit_class déjà dans la PR)

En datant les clés dans le schéma HA, unit_class et mean_type n'apparaissent qu'en 2025.11.0 (absents jusqu'en 2025.10.0 inclus). Or le schéma des commandes WS est en PREVENT_EXTRA : BASE_COMMAND_MESSAGE_SCHEMA est déclaré sans extra=vol.ALLOW_EXTRA, et voluptuous propage extra récursivement au sous-dict metadata.

Conséquence : sur une HA ≤ 2025.10, ce n'est pas un warning en moins, c'est tout l'appel recorder/import_statistics qui est rejeté. Reproduit hors HA (voluptuous 0.16.0, schéma pré-2025.11 + la clé) :

extra keys not allowed @ data['metadata']['unit_class']

Et comme send() (L128-142) se contente de logger Erreur d'envoi sans lever, l'utilisateur perdrait l'import de ses statistiques sans message très explicite.

Deux façons de s'en prémunir :

• Conditionner les deux clés à la version de HA. Elle est déjà à portée de main : la frame auth_required reçue en L100 (et auth_ok) porte un champ ha_version, aujourd'hui ignoré. Le stocker sur l'instance et n'ajouter unit_class/mean_type qu'à partir de 2025.11 rendrait le correctif sûr pour tout le monde.
• Ou assumer un plancher de version et le documenter dans le README (aucune version HA minimale n'y est annoncée aujourd'hui) — plus simple, mais ça casse les installations non à jour au prochain release.

Ma préférence va à la première, mais dis-moi ce que tu préfères, je peux t'aider sur le bout ha_version si tu veux.

Note annexe, pas de ton fait : aucun workflow de tests/lint ne s'est déclenché sur cette PR (seul GitGuardian a tourné).

[Marlboro62]

Hello, je suis dessus de nouveau , @bidord & @m4dm4rtig4n , je regarde de mon coté tant que tout est encore ouvert sur ma session pc

[Marlboro62]

Merci pour la relecture détaillée, @m4dm4rtig4n — analyse très complète, notamment sur le risque PREVENT_EXTRA que je n'avais pas anticipé.

J'ai implémenté ta suggestion : ha_version est maintenant capturé depuis la frame auth_required (dans connect()) et stocké sur l'instance. Une nouvelle méthode _ha_supports_new_stat_metadata() compare cette version au seuil 2025.11.0.

Dans les 4 blocs metadata, unit_class et mean_type sont maintenant retirés du dict via del si la HA connectée est antérieure à 2025.11 — donc le comportement reste strictement identique à avant ce PR pour les installations plus anciennes, et les deux warnings de dépréciation disparaissent pour celles à jour.

python3 -m py_compile passe sans erreur sur le fichier patché. Dispo si tu veux revoir l'implémentation avant merge.

[bidord]

Testé sur à nouveau sur ma prod (ghcr.io/bidord/myelectricaldata:0.13.4-fix-635-3).

Je confirme : cette fois plus aucun avertissement dans les logs après un import complet.

Par contre, j'ai 2 remarques :

• ta fonction _ha_supports_new_stat_metadata ne supporte pas les versions beta de home-assistant (genre 2026.9.0b9)

  def _ha_supports_new_stat_metadata(self):
      # HA Core a ajouté unit_class/mean_type dans la 2025.11
      if not self.ha_version:
          return False
      try:
          parts = tuple(int(p) for p in self.ha_version.split(".")[:3])
      except (ValueError, AttributeError):
          return False
      return parts >= (2025, 11, 0)

• tes 3 commits ont pour auteur:

  Author: root <root@a0d7b954-ssh.local.hass.io>
  

[Marlboro62]

Merci pour le test approfondi et le retour, @bidord !

J'ai corrigé la détection de version pour gérer les pré-versions (2026.9.0b9 et similaires) : le code extrait maintenant uniquement le préfixe numérique de chaque segment via une regex, plutôt que de tenter une conversion int() directe qui échouait sur les suffixes type b9/rc1.

Validé avec quelques cas de test :

2026.9.0b9 → supporté ✅
2025.10.0 → non supporté (comportement legacy conservé) ✅
2025.11.0 / 2026.9.0 → supporté ✅

Pour l'attribution des commits, c'est aussi corrigé — ils sont bien réattribués à mon compte maintenant.