J’avais eu un problème similaire et c’était mon capteur de température extérieur qui n’avait pas renvoyé l’information depuis plus d’une heure. Le capteur intérieur était OK.
Le plus troublant pour moi c’était que seul un des deux VTherms se mettait en sécurité : cela était dû au fait que seul un des 2 était au-dessus du « Pourcentage minimal de puissance »
Tu peux désactiver la prise en compte du capteur de température extérieur (Voir readme)
Par contre, il reste un dernier point que je n’ai pas compris, c’est la valeur de la dernière fois où la valeur de la température a été mis à jour qui passe à une valeur plus ancienne.
Merci de ton retour, j’ai activé les logs et j’ai ça :
2024-11-16 09:40:18.984 ERROR (MainThread) [homeassistant.core] Error executing service: <ServiceCall climate.set_temperature (c:01JCT22M980BPTPRMCZGY7H3PN): entity_id=['climate.clim_loucian'], target_temp_high=17.5, target_temp_low=17.5, temperature=17.5>
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/core.py", line 2822, in _run_service_call_catch_exceptions
await coro_or_task
File "/usr/src/homeassistant/homeassistant/core.py", line 2845, in _execute_service
return await target(service_call)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1007, in entity_service_call
single_response = await _handle_entity_call(
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1079, in _handle_entity_call
result = await task
^^^^^^^^^^
File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 968, in async_service_temperature_set
raise ServiceValidationError(
homeassistant.exceptions.ServiceValidationError: Set temperature action was used with the target temperature parameter but the entity does not support it
Il ne semble pas réussir à changer la consigne, c’est un climate sous zigbee2mqtt
Y a un mode sécurité en over_climate, j’ai corrigé la doc.
Tout est régulé par la température donc forcément, on en a besoin. C’est moins grave en mode over_climate car l’équipement régule de lui même mais tu risques une surchauffe ou une sous-chauffe si ton thermomètre est en panne.
Donc tu as suivi le readme et donc quel est le thermomètre en cause ? L’interieur ou l’extérieur ? Quels sont tes paramètres ?
Tu peux me donner les attributs comme expliqué ici :
Vous pouvez aussi vérifier dans les attributs du VTherm les dates de réception des différentes dates. Les attributs sont disponibles dans les Outils de développement / Etats.
Exemple :
homeassistant.exceptions.ServiceValidationError: Set temperature action was used with the target temperature parameter but the entity does not support it
Ton climate ne supporte pas qu’on lui donne une température de consigne. Il ne marche certainement qu’en mode plage de fonctionnement. Du coup, ça me parait pas très compatible avec un VTherm qui ne fait que ça de fixer des température de consigne.
C’est la poisse pour toi.
Ca n’explique pas le mode sécurité pour moi mais clairement ca ne va pas bien marcher.
occupied_heating_setpoint : Temperature setpoint. To control publish a message to topic zigbee2mqtt/FRIENDLY_NAME/set with payload {"occupied_heating_setpoint": VALUE} where VALUE is the °C between 16 and 30
Et via l’interface web de zigbee2mqtt, je peux bien entrer une valeur.
oui effectivement, il y a une petite prise en main, il faut bien comprendre qu’avec node red, l’information est envoyé uns seule fois en tant que message pouvant contenir plusieurs infos traitables, un peu comme un puls en automatisme. on ne peu donc pas travailler comme un automate avec des entrées à 1 ou à 0 et des portes logiques. C’est ce qui m’a pris le plus de temps à apprivoiser. Apres, comme pour HA, il y a une communauté et pas mal de doc pour avancer.
Le visuel est plus simple a comprendre et surtout à modifier ou a débugger. Après j’ai encore à apprendre, mais les fonctionnalités étant plus nombreuses et plus puissantes, ca évite de créer des templates intermédiaires dans HA et de se perdre avec entités. La les liens sont visuels
J’ai reprogrammé mon NSPanel et installé l’appli qui tourne en permanence. J’ai pas mal galéré a cause d’une forte latence, il faut un Dashboard light (dans mon cas). De plus je passe par une liaison extérieur (duckdns), je dois faire le nécessaire pour repasser sur une liaison locale, mais nécessite de revoir ma config HA.
Un sujet que je reporte, je me concentre sur mes automatismes, et principalement ma gestion de chauffage
J’ai réussi tant bien que mal a intégrer 3 thermostats avec module nodon fil pilote, capteur de température pour chaque chambre.
J’ai réussi a créé les 3 virtual Switch comme indiqué dans la doc en ligne.
Par contre je remarque 2 comportements bizarres pour moi:
mon radiateur en mode prog (fil pilote) peut continuer à chauffer si je touche la molette du radiateur (alors que consigne fil pilote en éco par vtherm)
le radiateur continue à chauffer régulièrement (chaud au toucher et consommation élec qui remonte par le module nodon), alors que le mode dans le vtherm est éteint.
Mes 3 vtherm sont identiques en terme de programmation, les 3 radiateurs sont identiques, les 3 capteurs de température aussi, mais ces 2 comportements bizarres n’arrivent pas à la même fréquence sur les 3 vtherm
Je n’ai pas encore attaqué la partie agenda pour programmer les plages horaires
Merci d’avance pour votre aide
PS: en faisant pas mal de test, je me suis aperçu qu’en agissant sur les « commandes » de mes vtherm sur le dashboard, il n’y a aucune action sur le fil pilote correspondant.
Ex: j’éteins le vtherm, celui-ci se grise (au lieu d’être en rouge), mais la conso élec se remet (preuve du fonctionnement du radiateur).
Hell, je ne suis malheureusement pas le roi du fil pilote et du Nodon car j’en ai pas moi meme. Le seul conseil, sépare bien les soucis en activant directement les switchs virtuels via le menu action des outils de dev. Ne les mets dans le Vtherm qu’ensuite quand tout est clair.
Donne nous aussi le code de ton switch virtuel.
La puissance affichée n’est pas la puissance réelle, mais estimée : puissance_max configurée x % de temps on.
Pour la question de la puissance, je me suis posé a côté des convecteurs, lorsque le vtherm affiche une puissance, la diode rouge est allumée et le radiateur chauffe réellement
Pour les outils de dev, je viens de tester la fonction allumer un commutateur, j’ai exécuté l’action, coche verte, mais dan d’historique de l’entité rien du tout
Ce que je voudrais surtout, c’est que le module réagisse aux ordres du Switch virtuel, mais j’ai l’impression que celui-ci reste désactivé, même si j’essaie de le bascule manuellement
Par contre quand j’agis directement sur le module fp, ça fonctionne
Donc mon problème vient sûrement du Switch, mais je ne comprends pas où est mon erreur
Effectivement ! Je trouve cela très surprenant. C’est pour moi un défaut important de l’équipement. Je considère ça comme un vrai point négatif pour un fonctionnement sans domotique. ça ne devrait jamais arriver dans mon cas, mais tout de même.
NodeRed m’a aussi fait de l’oeil. Mais j’avais lu qu’il était plus fiable d’utiliser les automatismes HA intégrés. Moins visuels, moins pratiques, mais plus fiables.
J’ai vu beaucoup de personnes qui ont passé tous leurs automatismes de NodeRed vers HA
Malin Mais c’est quand même rajouter de la complexité, que de modifier la modification pour récupérer la valeur avant la 1ere modification
Petit retour d’expérience avec mon thermostat Netatmo et les vannes SONOFF TRVZB que j’ai reçues. Ça fonctionne !
Comment j’ai fait : Côté TRV et capteurs:
Toutes les TRV Sonoff ont été configurées de manière à pouvoir piloter l’ouverture directement à l’aide du opening_degree (voir dans le fil de ce topic)
ajout de capteurs de T°C déportés à 1.5m de hauteur et 2 à 3 mètre du radiateur
ajout de capteurs d’ouverture à chaque fenêtre pour désactiver la chauffe en cas d’ouverture (>30 secondes).
Côté Versatile Thermostat:
création d’une configuration centrale, uniquement pour ajouter la chaudière et paramétrer les commandes ON/OFF.
création d’un Vtherm pour chaque pièce avec réglages indépendants de la configuration centrale. Chaque Vther est autorisé à démarrer la chaudière.
Côté Netatmo
dans l’appli dédiée, création d’un planning identique pour chaque jour de la semaine, avec une température de consigne de 15°C (ça me laisse un garde-fou au cas où). Cela permet d’éviter d’interférer avec les commandes envoyées par le Vtherm.
Pour Netatmo, l’entité climate de l’intégration de permet pas de recevoir des commandes ON/OFF pour la chaudière. En revanche, elle accepte le set_temperature
C’est donc cette commande que j’exploite dans la configuration centrale du Vtherm pour démarrer et arrêter la chaudière (sachant que la T°C de mon salon oscille entre 17 et 20°C max) :
climate.ma_piece/climate.set_temperature/temperature:15 pour l’arrêter
climate.ma_piece/climate.set_temperature/temperature:22 pour la démarrer
Et ça fonctionne très bien. Lorsque qu’un Vther s’active, on entend la vanne s’ouvrir légèrement, puis la chaudière démarrer.
Voici le résultat :
Consigne à 18°C. T°C obtenure = 18°C ±0.2°C, sans rien toucher aux réglages de base de l’algorithme.
Enfin, pour la gestion des planning, je confie cette tâche à Scheduler (intégration).
J’utilise également le Blueprint de Basanites (discussion sur le Github de Vtherm) qui me permet de modifier les consignes depuis les molettes des vannes et vice-versa, d’afficher les T°C de consigne des Vtherm.
Par rapport à l’investissement, le gain en termes de confort et de convivialité est inégalable.
Mais c’est quand même rajouter de la complexité, que de modifier la modification pour récupérer la valeur avant la 1ere modification 
