external and internal last temperature date use same value,

[KipK]

Just noticed the last time update for external and internal temperature sometime are the same. This doesn't always happened and can't reproduce for now. I'll try to track it

If you look at the log on the right you will see they're always updating at the same time, and have the same value on the entities column/

It seems it used only external temperature last update for booth.

I've noticed this while trying to test the T° failure mode, and was wondering why it didn't failed when I've removed the related sensor battery.

Config:

hvac_modes:
  - heat
  - "off"
min_temp: 7
max_temp: 23
target_temp_step: 0.5
friendly_name: Thermostat SdB
supported_features: 401
current_temperature: 19.6
temperature: 7
hvac_action: heating
preset_modes:
  - none
  - frost
  - eco
  - comfort
  - boost
preset_mode: frost
is_on: true
hvac_mode: heat
type: null
is_controlled_by_central_mode: true
last_central_mode: null
frost_temp: 7
eco_temp: 18
boost_temp: 21
comfort_temp: 19
frost_away_temp: 0
eco_away_temp: 0
boost_away_temp: 0
comfort_away_temp: 0
power_temp: 15
target_temperature_step: 0.5
ext_current_temperature: 16.05
ac_mode: false
current_power: 400
current_power_max: 9000
saved_preset_mode: frost
saved_target_temp: 7
saved_hvac_mode: null
motion_sensor_entity_id: null
motion_state: null
power_sensor_entity_id: sensor.linky_puissance_inst_no_evse
max_power_sensor_entity_id: sensor.linky_pcoup_marge_evse
overpowering_state: false
presence_sensor_entity_id: null
presence_state: null
window_state: "off"
window_auto_state: "off"
window_bypass_state: false
window_sensor_entity_id: binary_sensor.ouverture_sdb
window_delay_sec: 30
window_auto_enabled: false
window_auto_open_threshold: 3
window_auto_close_threshold: 0
window_auto_max_duration: 30
window_action: window_frost_temp
security_delay_min: 30
security_min_on_percent: 0.1
security_default_on_percent: 0
last_temperature_datetime: "2024-10-11T14:44:19.356048+02:00"
last_ext_temperature_datetime: "2024-10-11T14:35:32.771625+02:00"
security_state: false
minimal_activation_delay_sec: 60
device_power: 560
mean_cycle_power: 0
total_energy: 71.86
last_update_datetime: "2024-10-11T14:49:12.189119+02:00"
timezone: Europe/Paris
temperature_unit: °C
is_device_active: true
ema_temp: 19.58
is_used_by_central_boiler: false
is_over_switch: true
is_inversed: false
keep_alive_sec: 0
underlying_switch_0: switch.switch_rad_sdb
underlying_switch_1: null
underlying_switch_2: null
underlying_switch_3: null
on_percent: 0
power_percent: 0
on_time_sec: 0
off_time_sec: 420
cycle_min: 7
function: tpi
tpi_coef_int: 0.6
tpi_coef_ext: 0.02
'''

[jmcollin78]

Hello @KipK ,

This is not the same on my home.

Are you sure you have configured 2 different thermometer for internal and external temperature sensor ?

I've noticed this while trying to test the T° failure mode, and was wondering why it didn't failed when I've removed the related sensor battery.

Not understood. What do you call the T° failure mode ? (is it the safety mode ?).
There is some parameters to avoid safety mode. Are you sure this parameters are correctly set ?

You don't follow the issue template and then I don't have access to your parameters... So sad.

[KipK]

Are you sure you have configured 2 different thermometer for internal and external temperature sensor ?

Yes and it works ok 99% of the time. But today I got this when testing the fault mode to check if my script is ok.
Don't know if it's related to the other issue I've posted. But after restarting HASS it got back to normal.

I don't know what I can do to track down deeper the issue, as it's a lunatic behavior hard to reproduce ( for now )

Sorry for the issue template, it thought I had posted it here too, but those are the same setting than the other issue posted today. I've updated the first post with the yaml.

Here is the central conf

and the T° sensor set on Thermostat SdB

On the first post screenshot, I had removed the battery from the room T° sensor like 30mn ago, but it still display it received update.

[KipK]

Sorry I've modified the initial post if you've rode it from your email notification. It only happend today, but it's not always like this. My english translation was misleading first, i've reformulated it.

[jmcollin78]

Passons en français du coup, mon Anglais n'est pas non plus une tuerie et j'ai du mal à comprendre ce que tu cherches à faire. Dis moi si je me trompe :

1. tu essayes de tester le mode securité (the failure mode ?),
2. tu as débranché la batterie d'un thermometre (lequel ?),
3. lorsque le VTherm se met en mode sécurité, tu constates que les last_temperature_datetime et last_ext_temperature_datetime sont identiques

Est-ce que je jusque là j'ai bon ?

Si oui, je voudrais que tu me fasses une copie des attributs de ton VTherm (comme dans le post initial) lorsque le VTherm passe en mode sécurité. (donc avec security_state: true

Remarque: tes paramètres de sécurité sont pour moi trop forts et tu risques d'avoir des déclenchements intempestifs et de retrouver ton logement à 10° lorsque cela va se produire :

security_delay_min: 30
security_min_on_percent: 0.1
security_default_on_percent: 0

Si la température est stable il est tout à fait possible d'avoir 30 min sans remontée de température et c'est normal.
Le déclenchement va se faire même si le radiateur chauffait très peu (10%) et il ne chauffera plus du tout (0).

Si c'est juste pour les tests pas de soucis, mais je te conseille de ne pas rester comme ça en usage normal.

[jmcollin78]

Info complémentaire:

J'ai été voir un peu le code, et dans certaines conditions les 2 températures sont réinitialisées avec la date et heure courante:

def reset_last_temperature_time(self, old_preset_mode: str | None = None):
        """Reset to now the last temperature time if conditions are satisfied"""
        if (
            self._attr_preset_mode not in HIDDEN_PRESETS
            and old_preset_mode not in HIDDEN_PRESETS
        ):
            self._last_temperature_measure = self._last_ext_temperature_measure = (
                datetime.now(tz=self._current_tz)
            )

J'appelle cette méthode lorsqu'il y a eu un changement de conditions (allumage / extinction du Vtherm) ou changement de preset. Il n'est pas impossible que ce soit ça que tu ais vu. Auquel cas, c'est normal.

Juste après un changement de preset:

[KipK]

1/ exactement
2/ la batterie du capteur Salle de bain, mais la sécurité ne se declenchait pas car il affichait t quand même des updates synchronisés avec ceux du capteur exterieur ( ca a duré plus de 30mn avant que je coupe tout et que je relance hass )
3/ Du coup pas vraiment car il s'est pas mis en sécurité mais oui il affichait bien les updates identiques pendant un long laps de temps

Si oui, je voudrais que tu me fasses une copie des attributs de ton VTherm (comme dans le post initial) lorsque le VTherm passe en mode sécurité. (donc avec security_state: true

Je ferais ça demain ou plutôt début de semaine prochaine, ca peut prendre un peu de temps pour arriver à reproduire. De toute façon il va bien falloir que j'arrive à reproduire en détail pour pouvoir tracer ce qui déconne.

Remarque: tes paramètres de sécurité sont pour moi trop forts et tu risques d'avoir des déclenchements intempestifs et de retrouver ton logement à 10° lorsque cela va se produire :

En fait l'idée de mon script en test, c'est de pouvoir forcer le radiateur sur Eco quand le thermostat se met en mode failsafe, pour que ce soit le thermostat du radiateur qui reprenne le lead.
Du coup je ne veux pas que le thermostat Versatile continue d'envoyer des ordres, d'ou la valeur à 0 pour le couper ( sauf que pour l'instant pas le choix que de recevoir le off quand il se met en sécurité ). Il va falloir peut etre que je temporise mon script pour être sûr qu'il demarre après cet ordre ( en esperant que le thermostat ne controle pas l'état et ne renvoie pas un off derrière ). J'ai pas pu tester encore ça du coup comme j'ai eu le bug rencontré hier.

Si la température est stable il est tout à fait possible d'avoir 30 min sans remontée de température et c'est normal.
Le déclenchement va se faire même si le radiateur chauffait très peu (10%) et il ne chauffera plus du tout (0).

Le capteur de la salle de bain renvoie une info toutes les 5mn grand max. C'est un custom firmware de @pvxx dans le module.
Celui dehors c'est 15mn je crois bien la valeur max.

D'ailleurs chose rencontrée qui ressemble au bug de l'autre poste. Pour tester j'avais mis la valeur de délai max entre 2 relevé de t° à 3mn juste pour le thermostat SdB ( sinon c'est la conf centrale qui paramètre les thermostas ).
Et ca n'en avait pas tenu compte il continuait de garder la valeur de 30mn que j'avais configuré sur le Central.

Et c'est après ça que j'ai pu aussi constater le problème énoncé dans l'autre post. Je pense qu'il y a un lien entre les 2.

J'ai été voir un peu le code, et dans certaines conditions les 2 températures sont réinitialisées avec la date et heure courante:

Ok ca commence à avoir du sens, et ca vient sûrement de là. Sauf que c'est resté bloqué 30 mn dans cet état là jusqu'à ce que je coupe et relance HASS.

Merci pour ta patience en tout cas :)

[jmcollin78]

Je vais transformer cet issue en discussion puisqu'on est plus sur une discussion du coup. Si on trouve un bug je ferai le chemin inverse.

[jmcollin78]

En fait l'idée de mon script en test, c'est de pouvoir forcer le radiateur sur Eco quand le thermostat se met en mode failsafe, pour que ce soit le thermostat du radiateur qui reprenne le lead.

Ca ne peut pas marcher car pour avoir un mode Eco, tu as besoin d'un thermometre qui donne des valeurs. Tout l'algo est basé sur la différence entre les températures donc pas de températures, pas d'algo. Tu as plus d'infos ici au besoin : https://www.hacf.fr/optimisation-versatile-thermostat/

Tout ce qu'on peut faire (et c'est comme ça que c'est prévu), c'est d'avoir un pourcentage d'ouverture par défaut lorsqu'on ne peut pas le calculer. C'est à ça que sert le security_default_on_percent. Tu mets 30% de dedans (ou 20 ou 10) et du coup ca va chauffer 30% de temps, sans prendre le risque de mettre le feu à la maison et sans avoir un igloo non plus. Ca correspond peu ou prou au mode Eco que tu veux faire.

On parle de sécurité là : si le radiateur il reste bloqué à 100% tout le temps, ca peut être dangereux en plus de transformer ta maison en four

[KipK]

Je parle du mode Eco du radiateur pas de ton thermostat :) avec le fil pilote je peux regler le radiateur sur le mode que je veux ( HG, Eco , Confort, Confrt -1, confrt +1.. etc )
Justement plus de thermometre dans la pièce, plutot que de piloter à 10-20% à l'aveugle, c'est le thermostat hardware du radiateur qui prendrait le relai en Eco. ( le mode Confort n'est pas exploitable car volontairement reglé sur une valeur haute pour que Versatile puisse avoir le controle complet )

Ca me parait plus safe en cas d'absence prolongée et permet de maintenir une T° correcte dans la pièce.

[jmcollin78]

ah ok. Tu as des evenements qui sont envoyés par VTherm lorsqu'il passe en Securite. Ca peut être utile pour ton automatisation.

[KipK]

oui c'est ce que j'utilise déjà. :)

[jmcollin78]

On est sur 2 threads en //. Je reste sur HACF du coup.

[KipK]

oui là on a fait une elipse

[KipK]

Mise à jours faite en 6.3.4, et je n'arrive plus à reproduire ce soucis pour l'instant.

Je constate que je n'ai plus d'erreur de configuration qui apparaissait de manière un peu aléatoire non plus.