Versatile Thermostat - piloter votre chauffage avec la solution la plus complète

[Bix]

J’ai mis à jour le post pour ajouter quelques infos. Je suis sur la 8.3.0

Je vois de ça dans les logs si ça peut te guider

Enregistreur: homeassistant.components.sensor
Source: helpers/entity_platform.py:843
intégration: Capteur (documentation, problèmes)
S'est produit pour la première fois: 13 décembre 2025 à 14:02:05 (24 occurrences)
Dernier enregistrement: 12:45:20

Platform versatile_thermostat does not generate unique IDs. ID nb_device_active_boiler already exists - ignoring sensor.nb_device_active_for_boiler
Platform versatile_thermostat does not generate unique IDs. ID total_power_active_boiler already exists - ignoring sensor.total_power_active_for_boiler
Platform versatile_thermostat does not generate unique IDs. ID nb_device_active_boiler already exists - ignoring sensor.nb_device_active_for_boiler_2
Platform versatile_thermostat does not generate unique IDs. ID total_power_active_boiler already exists - ignoring sensor.total_power_active_for_boiler_2

[Benoit_cp]

Hello,

j’ai le même souci de mon côté…
Je suis avec la VT en 8.3.0 et 2.1.2 pour la carte.

[Jean-Marc_Collin]

Hello,

J’ai l’impression qu’il vous a créé des nouveaux sensors au lieu de réutiliser les précédents.
Il faudrait faire un peu de ménage :

1. supprimer les anciennes entités plus utilisées,
2. renommer les nouvelles avec les anciens nom pour ne pas avoir à tout modifier (automatisation, dahsboards, …).

Je vais essayer de comprendre pourquoi mais je ne me souviens pas avoir eu ce soucis.

Edit: je vois que d’autres ont le soucis aussi: sensor.nb_device_active_for_boiler tracks incomplete VTherm list after central config update · Issue #1406 · jmcollin78/versatile_thermostat · GitHub

L’appareil central configuration doit avoir ça :

[KipK]

@Jean-Marc_Collin C’est peut être le meme soucis que j’ai rencontré en cours de dev à cause du PR pour CONF_UNIQUE_ATTR_ID

KipK

[Bix]

J’allais justement répondre qu’en supprimant puis recréant la config centrale, cela semble de nouveau fonctionner (« sensor.nb_device_active_for_boiler_3 » est correctement à jour)

Quand je regarde les entités de Versatile, je vois effectivement plusieurs entités non groupées

edit : par contre je ne vois pas comment les supprimer…Impossible depuis l’onglet Entités, j’ai essayé d’utiliser recorder.purge_entities depuis l’outil de dev, mais ça n’a rien supprimé non plus.

Non c’est bon l’outil de purge fonctionne correctement

[Jean-Marc_Collin]

@KipK

Feat: Auto TPI - Automatic TPI Coefficient Learning & Calibration by KipK · Pull Request #1396 · jmcollin78/versatile_thermostat · GitHub

Si tu parles de ça : Use unique_id to generate _attr_unique_id by spolitov · Pull Request #1337 · jmcollin78/versatile_thermostat · GitHub justement je ne l’ai pas pris en 8.3, je voulais le tester un peu plus. Il est dans la 8.4 prévisionnel (sur laquelle tu es aussi).

Et je l’aurai vu quand j’ai installé chez moi. Y a un truc sur certains utilisateurs. Si c’était systématique. Et ici on me dit qu’un simple restart permet de résoudre. Mystère…

[Jean-Marc_Collin]

Dans les logs de @Bix on voit ça:

2025-12-13 14:02:05.055 ERROR (MainThread) [homeassistant.components.sensor] Error while removing entity sensor.nb_device_active_for_boiler
...
  File "/usr/src/homeassistant/homeassistant/helpers/event.py", line 442, in _remove_listener
    callbacks[key].remove(job)
    ~~~~~~~~~~~~~~~~~~~~~^^^^^
ValueError: list.remove(x): x not in list

et juste après on voit bien :

2025-12-15 12:44:48.098 ERROR (MainThread) [homeassistant.components.sensor] Platform versatile_thermostat does not generate unique IDs. ID nb_device_active_boiler already exists - ignoring sensor.nb_device_active_for_boiler_2

En gros, HA n’arrive pas à supprimer les entités existantes et en recréé d’autres avec des _2 ou _3.

Dans la stacktrace je n’ai aucun code VTherm donc je ne sais pas trop ce qui se passe. Je n’ai pas eu le soucis ni le log de mon coté donc y a qqe-chose dans votre conf qui provoque ça. Si vous avez des idées…

EDIT: Chatgpt m’a dit ce qui ne va pas. (il est fort)

→ Release 8.3.1 · jmcollin78/versatile_thermostat · GitHub

[KipK]

@Jean-Marc_Collin Une petite analyse depuis le codebase par Gemini ( histoire de challenger GPT )

Bug Fix: Central Boiler Sensor Tracking & Reload Errors

Goal Description

Fix a bug where sensor.nb_device_active_for_boiler tracks an incorrect number of devices after a central configuration change. Also fix ValueError: list.remove(x): x not in list errors and duplicate entity ID errors in logs.

The ValueError is caused by

NbActiveDeviceForBoilerSensor(and its power counterpart) registering anasync_on_removecallback that tries to remove a listener that isalsomanually removed when the sensor updates its list of monitored entities. This double removal crashes the unload/update process, leading to « zombie » entities and duplicate ID errors, and likely causes existing VTherms to differ from what the sensor sees.

User Review Required

NOTE

This fix addresses the internal listener management in

sensor.py. No configuration changes are required from the user.

Proposed Changes

custom_components/versatile_thermostat/sensor.py

[MODIFY]

sensor.py

Update

NbActiveDeviceForBoilerSensor and TotalPowerActiveDeviceForBoilerSensor classes.

• Method

  listen_vtherms_entities:

  • Capture the return value of self.async_on_remove(...). This is the « remove the cleaner » function.

  • Store it in a new attribute (e.g., self._cancel_on_remove_listener_nb_active).

• Method

  cancel_listening_nb_active:

  • When handling manual cancellation:

    1. Call self._cancel_listener_nb_active() (the listener remover).

    2. Call self._cancel_on_remove_listener_nb_active() (the cleanup remover) if it exists, to prevent HA from calling it again on entity unload.

    3. Clear both attributes.

Repeat the same pattern for

TotalPowerActiveDeviceForBoilerSensorwith_cancel_listener_power.

[Jean-Marc_Collin]

C’est bien ça. Chatgpt m’a dit pareil. C’est fixé ici :

Release 8.3.1 · jmcollin78/versatile_thermostat

[Bensmens]

Franchement @Jean-Marc_Collin et @KipK

Bravo pour cette réactivité !

Merci sincèrement de nous mettre à disposition un tel niveau de travail. Grâce à vous, de nombreux utilisateurs tel que moi peuvent pleinement tirer parti de leur chauffage avec cette intégration custom.

[foudepc83]

Bonjour,

Déjà, bravo pour le travail réalisé sur Versatile Thermostat, c’est vraiment une intégration de grande qualité

Je me permets de remonter un comportement que je constate avec une PAC air-air Mitsubishi d’entrée de gamme (via MELCloud), peut-être lié aux spécificités des PAC.

Contexte

Sur ce type de PAC, la sonde de température interne est située dans le caisson de l’unité intérieure, et non dans la pièce.
Cela provoque un biais bien connu : lorsque la ventilation est faible, l’air chaud reste dans le caisson, la sonde interne monte rapidement, et la PAC considère que la consigne est atteinte… alors que la température ambiante réelle ne l’est pas.

De mon côté :

• j’utilise Versatile Thermostat avec une sonde Sonoff déportée → fonctionnement excellent
• pour éviter ce biais de sonde interne, j’utilise une ventilation fixe à vitesse 2, ce qui permet d’évacuer la chaleur du caisson et d’avoir une régulation beaucoup plus juste

Comportement observé depuis la mise à jour (au passage bravo pour les évolutions)

• Versatile gère maintenant le mode de ventilation, ce qui est très intéressant (notamment en cas de gros écart de température, le mode “turbo” fonctionne très bien)
• En revanche, en fonctionnement normal :
  • si je règle manuellement la ventilation à vitesse 2, Versatile la force à repasser en AUTO
  • pour conserver une ventilation fixe, je suis obligé de désactiver complètement la gestion de la ventilation dans Versatile

Question

Est-ce qu’il existe :

• un réglage (peut-être avancé) permettant de ne pas forcer le mode AUTO
• ou une option pour autoriser une vitesse de ventilation fixe de base, tout en conservant la logique de boost en cas de gros écart de température ?

Dans mon cas, le mode AUTO constructeur est peu efficace à cause de la sonde interne, et la ventilation fixe donne de bien meilleurs résultats en confort et en stabilité.

Merci encore pour le travail réalisé, et désolé si la question a déjà été abordée

[frankb]

Bonjour à tous !

Petit truc étrange que je rencontre et je voulais savoir si le comportement est normal ou pas.
Je voulais mettre en TPI Seuil bas une valeur, par exemple 1. Si je finalise mes réglages, j’ai l’impression qu’il n’est pas pris en compte :
tpi_threshold_low: 0
tpi_threshold_high: 0

Par contre, si je met un chiffre autre que 0 pour le seuil haut, par exemple 1 egalement, la c’est bien pris en compte :
tpi_threshold_low: 1
tpi_threshold_high: 1

Est ce le comportement normal ? il me semble que j’avais réussi à n’utiliser qu’un seul des 2…

Merci par avance !
Ps : je suis en 8.3.1. J’ai essayé de rétrograder mais c’est pareil

[Jean-Marc_Collin]

Hello @foudepc83 ,

@foudepc83

ou une option pour autoriser une vitesse de ventilation fixe de base, tout en conservant la logique de boost en cas de gros écart de température ?

L’ajout de la ventilsation pour MelCloud a été faite par un contributeur donc je vais avoir du mal à te répondre. Peut être que tu peux le contacter ici : Improve auto fan mode to work with any fan_modes values. by Gamso · Pull Request #1378 · jmcollin78/versatile_thermostat · GitHub

Il répond vite (et remerciez le au passage pour avoir rendu le mode auto-fan plus universel que ce que j’avais fait).

[Jean-Marc_Collin]

Hello @frankb

Oui ca me dit quelque-chose, pour être pris en compte il faut que les 2 seuils soient renseignés.

Tiens regarde c’est écrit en toutes lettres: versatile_thermostat/documentation/fr/algorithms.md at main · jmcollin78/versatile_thermostat · GitHub

[foudepc83]

Merci pour le retour
Effectivement mon besoin serait :

une vitesse de ventilation fixe par défaut

tout en conservant le boost automatique uniquement en cas de gros écart de température

Je vais contacter @Gamso comme suggéré, merci pour le lien — et bravo pour l’amélioration de l’auto-fan

[Black_Dragon34]

Salut @Jean-Marc_Collin,

Je te joint l’état du Chauffage

hvac_modes:
  - heat
  - "off"
min_temp: 7
max_temp: 28
target_temp_step: 0.1
preset_modes:
  - none
  - frost
  - eco
  - comfort
  - boost
current_temperature: 19.5
temperature: 21
hvac_action: idle
preset_mode: safety
hvac_mode: heat
ema_temp: 19.81
specific_states:
  is_on: true
  last_central_mode: null
  last_update_datetime: "2025-12-17T14:48:11.658292+01:00"
  ext_current_temperature: 14.7
  last_temperature_datetime: "2025-12-17T12:18:53.755889+01:00"
  last_ext_temperature_datetime: "2025-12-17T14:16:19.971003+01:00"
  is_device_active: false
  device_actives: []
  nb_device_actives: 0
  ema_temp: 19.81
  temperature_slope: 0
  hvac_off_reason: null
  total_energy: 1.3
  last_change_time_from_vtherm: "2025-12-17T14:33:07.804306+01:00"
  messages:
    - safety_detected
  is_sleeping: false
  is_locked: false
  is_recalculate_scheduled: false
configuration:
  ac_mode: false
  type: over_switch
  is_controlled_by_central_mode: false
  target_temperature_step: 0.1
  minimal_activation_delay_sec: 60
  minimal_deactivation_delay_sec: 0
  timezone: Europe/Paris
  temperature_unit: °C
  is_used_by_central_boiler: false
  max_on_percent: null
  have_valve_regulation: false
  cycle_min: 10
preset_temperatures:
  frost_temp: 7
  eco_temp: 17.1
  boost_temp: 22
  comfort_temp: 21
  frost_away_temp: 0
  eco_away_temp: 0
  boost_away_temp: 0
  comfort_away_temp: 0
current_state:
  hvac_mode: heat
  target_temperature: 21
  preset: safety
requested_state:
  hvac_mode: heat
  target_temperature: 21
  preset: comfort
is_presence_configured: false
is_power_configured: false
power_manager:
  device_power: 0.8
  mean_cycle_power: 0.3
is_motion_configured: false
is_window_configured: true
is_window_auto_configured: true
window_manager:
  window_state: unknown
  window_auto_state: unknown
  window_action: window_eco_temp
  is_window_bypass: false
  window_sensor_entity_id: null
  window_delay_sec: 30
  window_off_delay_sec: 30
  window_auto_open_threshold: 3
  window_auto_close_threshold: 0.5
  window_auto_max_duration: 30
is_safety_configured: true
safety_manager:
  safety_state: "on"
  safety_delay_min: 120
  safety_min_on_percent: 0.7
  safety_default_on_percent: 0.4
is_lock_configured: true
lock_manager:
  is_locked: false
  lock_users: true
  lock_automations: false
  lock_code: true
is_over_switch: true
on_percent: 0.4
power_percent: 40
vtherm_over_switch:
  is_inversed: false
  keep_alive_sec: 0
  underlying_entities:
    - climate.ecosy_sdb
  on_percent: 0.4
  power_percent: 40
  on_time_sec: 240
  off_time_sec: 360
  function: tpi
  tpi_coef_int: 0.8
  tpi_coef_ext: 0.03
  tpi_threshold_low: 0
  tpi_threshold_high: 0
  minimal_activation_delay: 60
  minimal_deactivation_delay: 0
  calculated_on_percent: 1
  vswitch_on_commands:
    - set_hvac_mode/hvac_mode:heat
  vswitch_off_commands:
    - set_hvac_mode/hvac_mode:cool
friendly_name: Chauffage SDB
supported_features: 401

Et ici l’état du safety state

device_class: safety
icon: mdi:shield-check-outline
friendly_name: Chauffage SDB Safety state

qui ne ressemble en rien à ce que tu montre dans le gihub

safety_state: true
last_temperature_datetime: "2023-12-06T18:43:28.346010+01:00"
last_ext_temperature_datetime: "2023-12-06T13:04:35.164367+01:00"
last_update_datetime: "2023-12-06T18:43:28.351103+01:00"
...
safety_delay_min: 60

Si tu vois quelque chose ?

[Jean-Marc_Collin]

Hello @Black_Dragon34 ,

@Black_Dragon34

last_update_datetime: "2025-12-17T14:48:11.658292+01:00"
  ext_current_temperature: 14.7
  last_temperature_datetime: "2025-12-17T12:18:53.755889+01:00"
  last_ext_temperature_datetime: "2025-12-17T14:16:19.971003+01:00"

Ca me parait très clair. Il est 2025-12-17T14:48 et ta dernière mise à jour du capteur de température de ta pièce est de : 2025-12-17T12:18:53 soit 2h30 de retard. Comme le délai pour la mise en sécurité est de safety_delay_min: 120 (2h), le thermostat se met en sécurité. Ca sert exactement à ça.

Il faut donc que tu vérifies pourquoi ton capteur de temp n’a rien remonté pendant 2h. Si c’est un Zigbee, tu peux configurer le LastSeen comme expliqué dans la doc que je t’ai donné au-dessus.

Pareil dans le deuxième cas que tu me donnes:

last_temperature_datetime: "2023-12-06T18:43:28.346010+01:00"
last_ext_temperature_datetime: "2023-12-06T13:04:35.164367+01:00"
last_update_datetime: "2023-12-06T18:43:28.351103+01:00"

Là c’est carrément 5h40 de retard sur le capteur extérieur. Si tu lis l’article dont je t’ai donné le lien, tu peux désactiver la mise en sécurité sur le capteur extérieur.

@Black_Dragon34

Si tu vois quelque chose ?

Moi oui mais toi est-ce que tu l’as vu ?

Je te remets le lien : versatile_thermostat/documentation/fr/troubleshooting.md at 8.3.1 · jmcollin78/versatile_thermostat · GitHub

[Black_Dragon34]

Salut @Jean-Marc_Collin

@Jean-Marc_Collin

Pareil dans le deuxième cas que tu me donnes:

last_temperature_datetime: "2023-12-06T18:43:28.346010+01:00"
last_ext_temperature_datetime: "2023-12-06T13:04:35.164367+01:00"
last_update_datetime: "2023-12-06T18:43:28.351103+01:00"

Là c’est carrément 5h40 de retard sur le capteur extérieur. Si tu lis l’article dont je t’ai donné le lien, tu peux désactiver la mise en sécurité sur le capteur extérieur.

@Black_Dragon34

Si tu vois quelque chose ?

Moi oui mais toi est-ce que tu l’as vu ?

Le Deuxième cas est issu du Github, regardes la date 2023, alors oui je l’ai vu .

@Jean-Marc_Collin

Ca me parait très clair. Il est 2025-12-17T14:48 et ta dernière mise à jour du capteur de température de ta pièce est de : 2025-12-17T12:18:53 soit 2h30 de retard. Comme le délai pour la mise en sécurité est de safety_delay_min: 120 (2h), le thermostat se met en sécurité. Ca sert exactement à ça.

Pour ça OK, mais le soucis c’est pendant une période de non chauffe, et du coup lorsque le scheluder est censé mettre le radiateur en chauffe, il ne peux pas plus que les paramètre du safety mode.

Comme c’est la SDB avec un sèche serviette à bain d’huile, l’inertie est très longue, du coup entre la fin d’une chauffe, la température peut rester stable un bon moment.

Le conseil serait d’augmenter le safety_delay_min:, ou d’augmenter le safety_min_on_percent:et le safety_default_on_percent: pour que la SDB remonte en température, que le thermostat détecte un changement de température pour supprimer le safety mode.

Tu confirmes ?

Pour info, pas en Zigbee c’est en wifi.

[Bensmens]

Hello

J ai justement été confronté à la mise en sécurité d’ un radiateur et ça a fonctionné sans problème. Le soir j ai changé la pile du capteur de température et c’est reparti.

@Black_Dragon34

Le conseil serait d’augmenter le safety_delay_min:, ou d’augmenter le safety_min_on_percent:et le safety_default_on_percent: pour que la SDB remonte en température, que le thermostat détecte un changement de température pour supprimer le safety mode.

Si tu ne veux pas de mise en sécurité il faut passer a 1 le safety_min_on_percent (cf. doc)

Si tu veux retarder la mise en sécurité, il faut augmenter le délai safety_delay_min

Si tu veux arrêter la mise en sécurité en cours, il faut que le capteur de température revienne à la vie.

La question est donc, comme l a dit Jean-Marc, de savoir pourquoi le capteur n’ est pas remonté ?

[Black_Dragon34]

@Bensmens

Merci pour ta participation, je sais pourquoi le capteur ne remonte pas d’info.
Le capteur sur pile (neuves) n’envoie des informations que si la température change
de +/- 0.5°. Du coup comme la pièce est plutôt bien isolée et que le chauffage (Sèche serviette
bain d’huile) à une bonne inertie, la température peu ne pas évoluer pendant plusieurs heures.