Climate, thermostat, simple thermostat, besoin d'aide

bonjour,

je suis encore perdu et j’ai besoin de vos lumières.
Lors de mon démarrage sous HA, j’ai installé le ZWAVE et intégré mes vannes thermostatiques qui se retrouvent sous la forme :
image
j’ai installé une PAC Tuya, elle se retrouve sous la même forme :
image
ce matin, j’ai installé smartir pour avoir une pac commandée par Broadlink sous la même forme que les autres :
image

tout fonctionne nickel !
Je souhaite attaquer les calendriers de chauffe et la planification, il me faut donc des température pré réglées (éco, confort, etc)

l’idée est donc d’utiliser GitHub - dadge/awesome_thermostat: An awesome thermostat with preset mode management + windows opening management + activity sensor management
sauf que : Où puis je trouver le code de mes climates actuels pour les modifier ? dois je en recréer ? comment ? dans quel fichier ? que fais je des anciens ?
bref, je ne sais par où commencer. J’aimerais, autant que possible laisser configuration.yaml le plus propre et simple possible

pouvez vous m’aider ?

Ma configuration


System Information

version core-2023.8.1
installation_type Home Assistant OS
dev false
hassio true
docker true
user root
virtualenv false
python_version 3.11.4
os_name Linux
os_version 6.1.39
arch x86_64
timezone Europe/Paris
config_dir /config
Home Assistant Community Store
GitHub API ok
GitHub Content ok
GitHub Web ok
GitHub API Calls Remaining 5000
Installed Version 1.32.1
Stage running
Available Repositories 1270
Downloaded Repositories 11
Home Assistant Cloud
logged_in true
subscription_expiration 4 septembre 2023 à 02:00
relayer_connected true
relayer_region eu-central-1
remote_enabled true
remote_connected true
alexa_enabled false
google_enabled true
remote_server eu-central-1-5.ui.nabu.casa
certificate_status ready
can_reach_cert_server ok
can_reach_cloud_auth ok
can_reach_cloud ok
Home Assistant Supervisor
host_os Home Assistant OS 10.4
update_channel stable
supervisor_version supervisor-2023.07.1
agent_version 1.5.1
docker_version 23.0.6
disk_total 30.8 GB
disk_used 10.6 GB
healthy true
supported true
board ova
supervisor_api ok
version_api ok
installed_addons Terminal & SSH (9.7.1), File editor (5.6.0), Duck DNS (1.15.0), Z-Wave JS (0.1.85), Mosquitto broker (6.2.1), Samba share (10.0.2), Samba Backup (5.2.0), Zigbee2MQTT (1.32.2-1), Node-RED (14.4.3), Studio Code Server (5.10.0), Grafana (9.0.3)
Dashboards
dashboards 3
resources 7
views 8
mode storage
Recorder
oldest_recorder_run 29 juillet 2023 à 07:08
current_recorder_run 6 août 2023 à 12:12
estimated_db_size 465.69 MiB
database_engine sqlite
database_version 3.41.2
___

Bonjour @Bornich , le Dadge Awesome Thermostat n’est plus du tout maintenu.

Je l’ai repris à mon compte en l’améliorant. Tu as un fil complet ici : https://forum.hacf.fr/t/nouveau-thermostat-type-proportionnel-avec-gestion-des-presets-portes-et-fenetres-detection-de-mouvement-gestion-de-presence-et-surconsommation/

Regarde et n’hésites pas si tu as des questions.

bonjour Jean Marc,

Ouh là, oui, ca a l’air complet et gérable en UI plutôt qu’en Yaml, ce qui me convient bien. Je pense me lancer dans ce projet dans la semaine.
Quelques questions pour être sûr que je ne vais pas bloquer après quelques pas et je n’ai pas trop le temps de tout lire pour le moment :

  • Avec Jeedom, je ne faisais qu’envoyer des consignes a mes vannes thermostatiques qui se débrouillaient très bien pour gérer le reste : pourrais je continuer comme ca avec le scheduler ?
  • Les PAC air air ne sont pas les reines pour gérer des consignes, j’avais donc de petits programme qui « rectifiaient » les consignes envoyées par Broadlink toutes les heures. Si t° croissante pendant l’heure et au dessus de consigne+hystérésis, alors baisser la consigne de 1°C. Peut on faire ce genre de chose avec cette intégration ?
  • J’ai cette année, en plus de la migration sous HA, a ajouter le tarif Tempo. Autrement dit, ne pas toucher aux PAC pendant les tarifs rouge et tout passer sur le fioul … possible ?

ma lecture en diagonale m’a permis de déterminer que ce genres de choses est possible mais je suis loin de maitriser.
Pouvez vous me confirmer ? ensuite, ben je poserais des questions au fil de l’avancée …

Merci d’avance de l’aide et merci pour l’intégration qui me parait très bien faite

Oui. Il y a 2 types : un type ou le Versatile Thermostat (VTherm- pilote directement un radiateur (exemple) et un type pour ceux qui ont déjà un Thermostat (une entité climate en fait). VTherm se positionne par dessus et envoi des simples consignes (start, stop, temp cible, …) au thermostat sous-jacent. C’est le type over_climate dans la doc. Je pense que c’est ce type là qui répond à ton cas,

  • Les PAC air air ne sont pas les reines pour gérer des consignes, j’avais donc de petits programme qui « rectifiaient » les consignes envoyées par Broadlink toutes les heures. Si t° croissante pendant l’heure et au dessus de consigne+hystérésis, alors baisser la consigne de 1°C. Peut on faire ce genre de chose avec cette intégration ?

Ca ça va être plus dur. Pareil tu vas utiliser le type over_climate sur le « climate » de ta PAC. Mais du coup tu ne controles pas directement les cycles refroidissement / Arrêt. Y a des services qui permettent de changer la température cible donc avec une automatisation par dessus, y a moyen. Mais tu perds l’intérêt des presets dans ce cas. Modifier la température fait passer en mode Manuel et plus en mode Preset.

  • J’ai cette année, en plus de la migration sous HA, a ajouter le tarif Tempo. Autrement dit, ne pas toucher aux PAC pendant les tarifs rouge et tout passer sur le fioul … possible ?

Je suis aussi sous Tempo. J’ai des Scheduler dédiés aux jours rouges et d’autres pour les autres jours. Tout est possible. C’est un peu de travail de configuration et le scheduler est pas super simple à utiliser pour faire ça. Y a un thread dans ce forum qui explique comment faire : Plusieurs Scheduler sur les mêmes entités car c’est pas évident. Ca devrait aider.

Après faut tester et se lancer… Comme c’est des nouvelles entités / devices, ca casse rien de l’existant.

1 « J'aime »

Aie, c’est bien ce que je craignais :wink:
Si votre intégration envoie la consigne de x°C qui correspond a confort, par exemple, sur un « truc » (là, va falloir m’aider, qui réceptionne la consigne, ensuite, derrière, une automatisation (dont j’ai un modèle fonctionnel sous jeedom, peut contrôler la PAC physique…
ca me parait simple en principe mais pour le mettre en place dans HA, j’ai encore les mauvais reflexes Jeedom…

qu’en dites vous ? il faut prendre en compte que la clim dont je parle va être en confort de 17 à 21h la semaine et le reste en éco … je ne parle pas de changer de consigne toutes les 10 min, juste de la réviser toutes les heures … la baie vitrée par exemple fait monter la température et cette c… de clim continue de chauffer si on ne l’en empeche pas…

Soit le VTherm commande la clim en fonction de la température ambiante (type switch on-off) et donc c’est lui régule, soit il délègue à la clim la régulation et c’est elle qui régule.

Tenter de mélanger les deux c’est assez casse-gueule je pense.

Ce qu’il faut faire c’est de la régulation par la température cible (baisser si il fait trop chaud, monter si il fait froids) mais ca n’existe pas dans le VTherm. Ca me parait tellement spécifique comme besoin que je ne pense pas l’implémenter dans le VTherm.
Par contre, je pense que c’est pas très dur de le faire hors VTherm.

Grosse maille, il faut faire une automatisation comme ça :

  • trigger : toutes les heures,
  • conditions :
    • température cible - température réelle > seuil ou < - seuil
  • actions :
    si > seuil, baisser la temperature cible,
    si < -seuil, monter la temperature cible

Ca se fait très bien en utilisant les attributs du VTherm (température cible et temperature courante) et les services du VTherm pour changer de température.

Je te donne juste les étapes, et je te laisse chercher un peu (c’est comme ça qu’on apprend).
Dis moi si tu as besoin de plus d’aide.

bon j’ai commencé par le plus simple, les vannes de radiateurs fioul. Ne trouvant comment faire en yaml, j’ai fais avec l’interface graphique et ca marche bien.

Où puis je trouver le code yaml de chaque thermostat créé afin de pouvoir entrer les presets par des input.select ? il arrive qu’au fil de la saison, j’en modifie quelques uns … il semble que je ne puisse modifier le code depuis outil de développement puis états ou faut il valider par définir l’état ? je n’ose pas …

On ne peut pas faire. Ca ne marchera pas si ce n’est pas prévu dès le départ et ça ne l’est pas.

Par contre, tu peux modifier les temperature cible via un appel de service.

Outils debug / service / versatile

bon, pour le moment, j’avance sur le reste et j’ai une question :

sur la capture ci dessous, j’ai une pac et une vanne thermo :

je vois que dans le schelduler il est facile de sélectionner la vanne et le préset éco ou autre qui va envoyer une température de consigne et hop.
par contre, pour la pac, il ne suffit pas d’envoyer une consigne en preset mais aussi s’il faut chauffer, refroidir, etc … comment faire ?

Dans le scheduler, après avoir choisi une plage horaire, tu peux soit choisir le mode (ventilation, dry, chauffe, refroidit, eteindre) ou choisir un preset.

Ce que je fais c’est d’allumer la clim dans la période (10 min dans mon cas) puis dans la période suivante, je choisi le preset. C’est les toutes petites barres dans le SCHEMA.

J’ai pas trouvé pour allumer ET choisir un preset en une seule opération.

bonjour,

j’ai presque fini, ca va bien avec le scheduler une fois compris, c’est d’une logique implacable !

un truc dont je doute. Lorqu’on est en tempo rouge, les clim sont sur éteindre, là, c 'est facile.

Si on passe du rouge a une autre couleur, c’est forcément à 6h00 du matin, donc les conditions sont réévaluées a ce moment là … donc pour les planning Bleu ou Blanc, il faut faire le démarrage de 6h à 6h10 pour savoir comment démarrer la journée et cà se passera toujours bien, je dis encore une connerie ou c’est aussi simple ?

Oui le changement doit être après 6h00 (/ 22h00) pour le tempo ait eu le temps de changer. Bonne remarque. Je ne suis pas sur d’avoir pris ça en compte. J’irai vérifier.

pour l’automatisation, visiblement, je ne peux faire par l’UI car je peux tester un attribut mais pas par rapport a un autre attribut … tu me confirme ?
il faut donc que j’attaque directement en yaml et dans mon fichier automatisation.yaml, chacune commence par un id, je mets un chiffre au pif ? :

- id: '1685265739614'
  alias: VMC montée vitesse
  description: ''
  trigger:
  - type: humidity
    platform: device
    device_id: 13c3ce2bc4a48bf16da4353f8c3d12b3
    entity_id: sensor.humidite_sdb_humidity
    domain: sensor
    above: 70
  condition: []
  action:
  - device_id: eeb47405285b23ec47bcd9c309c678a1
    domain: cover
    entity_id: cover.vmc
    type: open
  mode: single
- id: '1685266516437'
  alias: VMC baisse vitesse
  description: ''
  trigger:
  - type: humidity
    platform: device
    device_id: 13c3ce2bc4a48bf16da4353f8c3d12b3
    entity_id: sensor.humidite_sdb_humidity
    domain: sensor
    below: 70
  condition: []
  action:
  - device_id: eeb47405285b23ec47bcd9c309c678a1
    domain: cover
    entity_id: cover.vmc
    type: close
  mode: single

pour l’automatisation, visiblement, je ne peux faire par l’UI car je peux tester un attribut mais pas par rapport a un autre attribut … tu me confirme ?

Oui. Il te faut faire un template qui doit ressembler à ça (exemple dans un trigger) :

trigger:
  - platform: template
    value_template: '{{ state_attr(''sensor.beynes_next_rain'', ''1_hour_forecast'')[''0
      min''] != ''Temps sec'' }}'

Ce template vérifie l’attribut 1_hour_forecast de l’entité sensor.beynes_next_rain est différent de ‹ Temps sec › (en gros, il va pleuvoir dans 1 heure).

Dans une condition la syntaxe est un peu différente et doit ressembler à ça :

condition:
  - condition: template
    value_template: '{{ state_attr(''sensor.beynes_next_rain'', ''1_hour_forecast'')[''0
      min''] != ''Temps sec'' }}'

Regarde la doc des templates Template - Home Assistant et Conditions - Home Assistant pour avoir beaucoup plus de possibilités. Tu n’as pas besoin de passer en mode yaml pour taper des templates. Dès que tu vas taper une valeur qui est en template, l’UI va s’adapter. La je suis dans l’UI, j’ai tapé un template dans un champ état et ça passe automatiquement en mode édition du yaml, que sur la valeur de cet attribut :


Quand tu vas faire des templates assez long, tu risques de galérer avec la syntaxe du yaml (|>, -, …). C’est subtile et casse gueule. Donc reste sur l’UI.

chacune commence par un id, je mets un chiffre au pif ? :

Alors, je te déconseille d’éditer tes automatisations directement dans le fichier automatisation.yaml. Il vaut mieux passer par editer en yaml directement depuis l’interface :
Capture d’écran 2023-08-08 à 21.36.06
Tu choisis ton automation et tu cliques sur le menu en haut à droite pour éditer en tant que yaml. Techniquement, tu n’as même pas besoin de faire ça puisque si tu tapes un début de template, l’éditeur passe tout seul en mode édition de yaml.
L’énorme avantage de passer par l’UI c’est que l’interface refusera de modifier l’automation si des fois tu as des erreurs de syntaxe dedans. Et avec le yaml rien de plus facile que de faire des erreurs d’indentation ou autres.
Je l’ai fait dans des rares cas, pour faire des search/replace global sur tout le fichier mais vraiment faut éviter surtout au début. Tu pourras en plus ajouter des modes simplement.

…dans mon fichier automatisation.yaml , chacune commence par un id, je mets un chiffre au pif ?

« au pif » :grin: ! Non. Edites ton automatisation via l’UI et il va le faire tout seul. Encore une bonne raison de passer par l’interface.

J’espère que ça t’aide.

1 « J'aime »

bon, ben pas moyen de faire un test pour savoir si ma température actuelle est inférieure a la target - 0.5°C par exemple avec l’UI… je ne peux comparer que par rapport a un nombre ou une entité mais pas par rapport a une (entité - 0.5) par exemple, c’est dommage
un moyen de contourner ca ?

je cherche a reproduire ce tableau : (sous jeedom, le 0.5 était appelé hystérésis)

Un exemple de template qui fait ça :

{{ states('sensor.temperature_bureau') | float(0) > states('sensor.meteo_beynes_temperature') | float(0) - 0.5 }}

Le piège c’est que les states(xxx) sont des string et qu’il faut les caster en float pour les comparer et les additionner.

EDIT: le 0 est la valeur par défaut si le state n’est pas disponible.

donc il faut créer un « truc », sensor, template ? a chaque fois qu’on veut faire un calcul ?
c’est lourd, non ?

ok, bon, rien compris aux states, string et 0 mais bref…

par contre, je n’arrive pas a balancer une consigne de (temp cible +2) par exemple dans une clim. Le service climate.set_temperature ne veut que des chiffres …

tout est toujours bloqué comme ca sous HA ? y a un loup, là, faire une addition me parait dans ses capacités, non ?

Ca donne la valeur de l’état du sensor.temperature_bureau

| float(0)

ca le converti en float et si jamais l’état n’était pas dispo ca lui renvoie 0.

tout est toujours bloqué comme ca sous HA ?

Non bien au contraire, mais tout ce qui est un peu puissant demande un peu de temps, de recherche et de lecture de la doc (en Anglais). ChatGTP fournit en général des bonnes réponses, si ça peut aider.

Le langage utilisé pour les templates est du Jinja2. Y a une syntaxe particulière qu’il faut apprendre à maitriser. Un peu de lecture ne fait pas de mal. Tu devrais trouver pas mal de tuto sur internet et la doc HA ( Regarde la doc des templates Template - Home Assistant et Conditions - Home Assistant

par contre, je n’arrive pas a balancer une consigne de (temp cible +2) par exemple dans une clim. Le service climate.set_temperature ne veut que des chiffres …

Et ben il faut lui donner des chiffres. Essayes ça (avec les outils de debug / services) :

service: climate.set_temperature
data: {
  temperature: "{{ states('sensor.temperature_bureau') | float(22) + 0.5 }}"
}
target:
  entity_id: climate.ma_clim_hvac_temperature

EDIT: j’ai essayé avec chatGPT et ça donne ça :

JM: Donne un moi un appel de service qui permet d’additionner une valeur d’un capteur et la valeur 0.5

ChatGPT :

Pour ajouter une valeur d’un capteur à 0.5 en utilisant un appel de service dans Home Assistant, vous pouvez utiliser le service input_number.set_value. Voici comment vous pourriez le faire :

service: input_number.set_value
data:
  entity_id: input_number.your_input_number_entity
  value: "{{ states('sensor.your_sensor_entity') | float + 0.5 }}"

Dans cet exemple, vous devez remplacer your_input_number_entity par l’entité input_number que vous souhaitez mettre à jour et your_sensor_entity par l’entité du capteur dont vous voulez ajouter la valeur. L’expression {{ states('sensor.your_sensor_entity') | float + 0.5 }} récupère la valeur du capteur, la convertit en nombre à virgule flottante et ajoute 0.5.

Assurez-vous que votre capteur et l’entité input_number sont correctement définis dans votre configuration Home Assistant.

Si vous exécutez cet appel de service, il mettra à jour la valeur de l’entité input_number en ajoutant 0.5 à la valeur actuelle du capteur.


C’est pas parfait mais ça donne pas mal de piste.

Bon j’avance toujours … clopi-clopa

mes scheduler sont en place et lancent les clim ou les radiateurs suivant le tarif tempo en vigueur a 6h00 chaque matin.

j’avais le soucis d’allumer la clim puis envoyer un preset mais ce soucis s’est envolé avec mon automation de régulation de température qui fait :
test clim on ou off
test pente de température dans l’heure précédente
test de la température de la pièce par rapport a au preset agrémenté de l’hystérésis
action : allumer ou pas, envoyer la bonne consigne

ca semble fonctionner malgré une usine a gaz …

du coup, lorsque je lance le preset éco par exemple à 17h00, même si la clim n’est pas allumée, sa target va passer a la valeur d’éco. Mon automation, ci dessus, se déclenche toutes les 1eres minutes de chaque heure, elle allumera donc la clim si besoin…

quel est la différence entre les attibuts ‹ temperature › et ‹ target_temp › ?