Chauffage radiateurs — AppDaemon et C6

L'app radiator_heating expose climate.radiator_heating par MQTT Discovery. La version MQTT directe utilise le plugin MQTT d'AppDaemon pour les publications et les abonnements. Le plugin Home Assistant sert à lire les thermomètres. Les commandes du climate et les retours C6 restent sur les mêmes topics.

Configuration MQTT

Le plugin MQTT est configuré dans appdaemon.yaml, namespace mqtt. Les identifiants du broker sont dans secrets.yaml (exclu de Git) et référencés par !secret. Ils doivent être sauvegardés séparément pour une réinstallation. Un redémarrage complet du conteneur/service AppDaemon est nécessaire pour charger un nouveau plugin ; le rechargement des apps ne suffit pas.

Le climate et son watchdog exigent ce plugin. Les deux anciennes automatisations Home Assistant ont été supprimées après vérification des commandes et de la télémétrie en MQTT direct. Aucun relais MQTT dans Home Assistant n'est nécessaire.

Fichiers

apps/boilerclimate.py : MQTT Discovery, consigne, mode, mesures et commandes.
apps/boilerwatchdog.py : surveillance indépendante du heartbeat.
apps/boilerregulator.py : calcul indépendant de la température d'eau.
apps/global/heating.yaml, blocs radiator_heating et radiator_heating_watchdog : paramètres actifs des deux apps.
appdaemon.yaml, plugin MQTT : connexion broker, abonnements et Last Will.

Régulation

Le bloc facultatif smart_conditions contrôle le mode heat/off avec le même évaluateur que les autres apps : Succeeded passe en heat, Failed passe en off. L'évaluation initiale est appliquée au démarrage, puis chaque changement de résultat. Un résultat Disabled suspend l'automatisme et conserve le mode. Les commandes manuelles restent possibles ; elles restent en vigueur jusqu'au prochain changement de résultat de la condition ou redémarrage de l'app. Le changement de mode envoie immédiatement la commande chaudière et est persisté. La consigne ambiante n'est pas modifiée et les sécurités capteurs restent actives. Sans ce bloc, le mode reste entièrement manuel comme auparavant. Exemple :

smart_conditions:
  trigger_conditions:
    - binary_sensor.heatpump_winter_mode

Les options standard (blocking_conditions, disable_conditions, callback_delay, constantes locales) sont prises en charge.

La règle active demande heat uniquement si quelqu'un est à la maison, si le minimum extérieur est inférieur à la consigne ambiante (self.temperature), et si toutes les fenêtres et portes-fenêtres surveillées sont fermées. binary_sensor.group_windows couvre bureau, salon, chambre d'amis et dressing ; les portes-fenêtres cuisine, salon et chambre sont ajoutées séparément. La règle utilise les états booléens de présence et d'ouverture. Le mode est recalculé au démarrage et lors des changements de résultat de la règle, sans temporisation ajoutée. Après un changement de consigne, la règle est réévaluée lorsque Home Assistant actualise l'attribut temperature du climate. self désigne l'entité configurée par entity: climate.radiator_heating. Toutes les expressions lisent les états Home Assistant normalement. Au premier démarrage, le chauffage reste en off pendant l'attente de l'entité et de sa consigne, avant de créer l'évaluateur. Celui-ci est ensuite conservé pendant toute la durée de vie de l'app, y compris lors des changements de consigne.

Avec S la consigne ambiante, Ti la température du couloir et Te la plus basse des températures extérieures (sensor.ext_front_temperature et sensor.ext_back_temperature, configurées dans outdoor_sensors) :

courbe = S + pente × (S − Te) + décalage
correction P = kp × (S − Ti)
correction I += ki × (S − Ti) × durée_en_heures
demande = courbe + correction bornée(P + I)

La sortie est arrondie au demi-degré et limitée entre 30 et 50 °C initialement. ki est exprimé en degrés d'eau par degré d'écart intérieur et par heure. Les bornes de sortie et de correction disposent d'une protection anti-windup. L'intégrale est remise à zéro à l'arrêt, en cas de mesure invalide, au changement manuel de consigne et au redémarrage. Consigne et mode sont persistés dans apps/data/appdaemon_radiator_heating.json, exclu de Git. Une sauvegarde absente au premier lancement utilise la configuration initiale. Une sauvegarde illisible ou invalide impose le mode off avec un avertissement. Une erreur d'écriture est journalisée sans bloquer la commande chaudière, notamment l'arrêt demandé par l'utilisateur ou l'arrêt ordonné de l'app.

À l'équilibre, la chauffe peut rester demandée même lorsque Ti = S. L'app inhibe le chauffage si Ti >= S + 0,5 °C, ou si la demande calculée descend sous la température minimale utile (avec une hystérésis de 1 °C d'eau). Après arrêt, le redémarrage exige Ti <= S + 0,1 °C et une demande suffisante. Les gains sont des valeurs initiales à ajuster après les essais de circulation, pas des coefficients identifiés pour cette maison.

Le capteur intérieur et les deux capteurs extérieurs doivent fournir des valeurs finies en °C, entre −40 et 60 °C. Le minimum extérieur est recalculé à chaque mise à jour de l'un des capteurs et à chaque cycle. L'attribut outdoor_sensors liste les sondes utilisées et outdoor_sensor identifie celle sélectionnée. Si l'une des sondes est invalide, le chauffage reste inhibé comme auparavant. La configuration historique outdoor_sensor reste acceptée pour une seule sonde. Une température inchangée, même ancienne, reste valide : ces sondes peuvent ne publier qu'en cas de changement. Aucun délai sur l'âge de la mesure n'est appliqué. Les états indisponibles/inconnus, les valeurs invalides et les unités incorrectes provoquent toujours l'inhibition. Une sonde déconnectée conservant une valeur plausible n'est donc pas détectée par ce contrôle.

Un défaut publie un log ERROR avec l'identifiant, le nom du capteur et sa cause (état invalide, unité ou valeur incohérente). Le log est émis à l'apparition du défaut ou au changement des capteurs concernés, sans répétition chaque minute. Le détail actualisé reste disponible dans l'attribut sensor_error du capteur « État de la régulation », même quand le climate est indisponible. Un log INFO signale le rétablissement. L'app utilise le pipeline standard LoggerInterface (log_info, log_warning, log_error) ; les erreurs sont également envoyées dans error_log. L'option ascii_encode=False, propre à cette app, conserve les accents et le symbole °C.

MQTT et disponibilité

Configuration : homeassistant/climate/appdaemon_radiator_heating/config.
Commandes utilisateur : appdaemon/radiator_heating/command/mode (heat/off) et /command/temperature (consigne ambiante entre 10 et 23 °C).
État et diagnostics : appdaemon/radiator_heating/state et /attributes.
Chaudière : themaplus-condens/bai/SetMode/set.

Le plugin transmet les commandes MQTT et les retours chaudière à l'événement MQTT_MESSAGE du namespace mqtt, écouté directement par l'app. Le watchdog AppDaemon marque le climate indisponible après trois minutes sans heartbeat (vérification toutes les dix secondes). Il ne commande PAS la chaudière. Il utilise un worker distinct du climate. Il publie offline au démarrage et après reconnexion tant qu'aucun heartbeat récent n'est arrivé. Seul le climate publie online, selon la validité de ses mesures.

La disponibilité MQTT Discovery exige simultanément la disponibilité de l'app (/availability) et celle de la connexion MQTT (/connection). Le plugin publie online sur /connection à la connexion, et le broker publie offline via le Last Will si cette connexion est perdue. Ce mécanisme ne garantit pas une détection immédiate et ne coupe pas le chauffage. Configuration et états sont retenus ; les commandes utilisateur et chaudière ne doivent jamais l'être. Une reconnexion MQTT republie la découverte et renouvelle la commande.

SetMode est renouvelé chaque minute et lors d'un changement de demande. Les retours de télémétrie ne renouvellent pas la commande. Un arrêt ordonné publie une inhibition du chauffage ; un crash repose sur l'expiration observée de la commande chaudière. Les champs de consigne ECS sont null et les bits d'inhibition sanitaire restent à zéro.

heating_requested désigne la demande de l'app. L'action heating du climate n'est annoncée qu'avec un état chaudière S.04 récent et est actualisée dès réception du statut, sans recalcul ni renouvellement de commande ; une chauffe sanitaire n'est pas comptée comme chauffage des radiateurs. Sans télémétrie récente, idle ne constitue pas une preuve d'absence de flamme : consulter aussi la chaudière. L'écho SetMode confirme une transmission C6, pas la consigne effective.

Essais actuels

Les écritures sont autorisées (send_commands: true), pont thermostat fermé. Le climate démarre en mode heat, consigne 18 °C, sauf état utilisateur persisté. Un couloir plus chaud que la consigne entraîne normalement une inhibition. Le retour au réglage local de 10 °C après environ 15 minutes sans renouvellement a été observé pont ouvert. L'arrêt réel après perte de communication reste à vérifier avec circulation autorisée ; ce délai n'est pas une coupure immédiate.

Un premier essai pont fermé avec une consigne ambiante de 23 °C a produit une demande d'eau à 46 °C et un démarrage de la chauffe. Les réglages restent à ajuster selon l'évolution réelle des températures. Ne pas modifier les mesures réelles pour simuler la chauffe. send_commands: false permet de conserver l'interface et les calculs sans écrire SetMode. Les lectures de télémétrie continuent.

Vérification

python -m unittest discover -s tests -p test_boilerclimate.py -v

9.8 KiB Raw Blame History Unescape Escape