Optimisation CVC par IA : consignes et horaires plus intelligents avec les données MQTT

L'optimisation CVC par IA utilise les données du système de chauffage, ventilation et climatisation d'un bâtiment pour apprendre comment chaque zone se comporte réellement, puis choisit des heures de démarrage, des consignes et des horaires qui garantissent le confort des occupants avec moins d'énergie. Dans ce cas d'usage, vous verrez quelles données collecter via MQTT, comment apprendre la réponse thermique d'une zone à partir de ces données, comment calculer une heure de démarrage optimale et comment renvoyer les recommandations vers le bâtiment en toute sécurité.

Là où la régulation CVC classique gaspille de l'énergie

La plupart des systèmes de gestion technique du bâtiment fonctionnent avec des horaires et des consignes fixes, configurés lors de la mise en service. La centrale de traitement d'air démarre à 06:00 chaque jour ouvré parce que quelqu'un a décidé un jour que c'était assez tôt, que la nuit ait été douce ou froide. Les consignes restent identiques pendant un vendredi après-midi à moitié vide. Le chauffage et la climatisation simultanés dans des zones voisines passent inaperçus pendant des mois.

Rien de tout cela n'est imputable aux régulateurs, qui maintiennent correctement leur consigne. Le manque se situe au niveau de la supervision : décider quelles doivent être les consignes et les horaires en fonction de la météo, de l'occupation et du comportement thermique du bâtiment. C'est là que les modèles fondés sur les données sont utiles, et c'est pourquoi l'optimisation CVC par IA se place généralement au-dessus de la GTB existante au lieu de la remplacer.

Les données à collecter pour l'optimisation CVC par IA

Les systèmes de gestion technique du bâtiment parlent généralement BACnet ou Modbus. Une passerelle lit les points pertinents et les publie vers un broker MQTT selon une hiérarchie cohérente, afin que le service d'optimisation n'ait jamais à connaître les noms de points propres aux fabricants :

connectmq/hq/floor3/zone-east/temperature     {"ts":..., "value": 23.8, "unit":"degC"}
connectmq/hq/floor3/zone-east/setpoint        {"ts":..., "value": 22.0, "unit":"degC"}
connectmq/hq/floor3/ahu2/supply_temp          {"ts":..., "value": 14.2, "unit":"degC"}
connectmq/hq/weather/outdoor_temp             {"ts":..., "value": 31.5, "unit":"degC"}
connectmq/hq/floor3/zone-east/recommendation  {"ts":..., "start_at":"06:40", "reason":"..."}

Si vous hésitez entre les protocoles du bâtiment au niveau de la passerelle, l'article BACnet ou Modbus les compare.

Trois opportunités d'optimisation

1. Optimum de démarrage et d'arrêt. Démarrer le conditionnement de chaque zone juste assez tôt pour atteindre la plage de confort au début de l'occupation, et arrêter plus tôt lorsque l'inertie thermique du bâtiment maintiendra la température jusqu'au départ des occupants.
2. Optimisation des consignes. Assouplir les consignes dans la plage de confort lorsque les zones sont inoccupées ou peu occupées, et pré-refroidir ou préchauffer pendant les heures de faible demande ou de prix bas.
3. Détection des défauts et du gaspillage. Repérer les zones qui chauffent et refroidissent simultanément, les vannes qui ne se ferment jamais ou les capteurs qui dérivent. Ce sont souvent les économies les plus rapides.

L'optimum de démarrage est le meilleur premier projet : il est facile à expliquer, ses économies sont mesurables et son mode de défaillance (une zone un peu trop chaude à l'ouverture) reste bénin.

Apprendre la réponse thermique d'une zone

Sur de courts horizons, de nombreux bâtiments se comportent raisonnablement comme un système thermique du premier ordre. La variation de température de la zone à chaque pas de temps dépend de l'écart avec la température extérieure (apports à travers l'enveloppe) et du froid ou du chaud fourni par le CVC :

T[k+1] - T[k] = a * (T_out[k] - T[k]) + b * u[k] + c

Ici, u est la sortie CVC (par exemple climatisation en marche ou à l'arrêt, ou position de vanne), et c représente les apports internes et solaires moyens. Ajuster a, b et c pour chaque zone par régression linéaire sur quelques semaines de données donne un modèle « boîte grise » : assez simple pour être digne de confiance, et assez fondé sur les données pour refléter le comportement réel de chaque zone. Les projets plus avancés utilisent le gradient boosting ou des réseaux de neurones avec des variables d'occupation et d'ensoleillement, mais le modèle boîte grise est un point de départ solide et explicable. Ces modèles par zone constituent déjà un jumeau numérique simple du bâtiment, que l'article sur le jumeau numérique CVC approfondit.

Exemple : optimum de démarrage à partir de données MQTT

Le script ci-dessous ajuste le modèle thermique d'une zone, puis cherche l'heure de démarrage de la climatisation la plus tardive qui permet encore d'amener la zone dans la plage de confort au début de l'occupation. Il utilise un historique simulé pour pouvoir s'exécuter n'importe où, et publie la recommandation sur le serveur MQTT public gratuit. Dans un déploiement réel, l'historique proviendrait de votre abonné historian et la prévision météo d'un service météo.

import json
import random
import time
import uuid

import numpy as np
import paho.mqtt.client as mqtt
from sklearn.linear_model import LinearRegression

STEP_MIN = 5
COMFORT_MAX = 24.0
OCCUPANCY_START = "08:00"

# --- 1. Historique simulé (à remplacer par les données de l'historian) -----
rng = np.random.default_rng(1)
true_a, true_b, true_c = 0.004, -0.06, 0.004
T, rows = 25.0, []
for k in range(14 * 24 * 12):  # deux semaines au pas de 5 minutes
    hour = (k * STEP_MIN / 60) % 24
    t_out = 24 + 7 * np.sin((hour - 9) / 24 * 2 * np.pi)
    u = 1.0 if 7 <= hour < 18 else 0.0
    T_next = T + true_a * (t_out - T) + true_b * u + true_c + rng.normal(0, 0.03)
    rows.append((T, t_out, u, T_next - T))
    T = T_next

data = np.array(rows)
X = np.column_stack([data[:, 1] - data[:, 0], data[:, 2]])
model = LinearRegression().fit(X, data[:, 3])
a, b = model.coef_
c = model.intercept_
print(f"learned a={a:.4f} b={b:.4f} c={c:.4f}")

# --- 2. Recherche de l'optimum de démarrage --------------------------------
def simulate(start_index, T0, t_out_forecast, occ_index):
    T = T0
    for k in range(occ_index):
        u = 1.0 if k >= start_index else 0.0
        T = T + a * (t_out_forecast[k] - T) + b * u + c
    return T

T_now = 25.2                                     # température de la zone à 05:00
steps_until_occ = (8 - 5) * 60 // STEP_MIN       # 05:00 -> 08:00
t_out_fc = [22 + 0.08 * k for k in range(steps_until_occ)]  # prévision d'une matinée qui se réchauffe

best = 0
for start in range(steps_until_occ, -1, -1):     # démarrage le plus tardif d'abord
    if simulate(start, T_now, t_out_fc, steps_until_occ) <= COMFORT_MAX - 0.3:  # petite marge de sécurité
        best = start
        break
start_minutes = 5 * 60 + best * STEP_MIN
start_at = f"{start_minutes // 60:02d}:{start_minutes % 60:02d}"
print("recommended cooling start:", start_at)

# --- 3. Publication de la recommandation -----------------------------------
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/hq/floor3/zone-east"
rec = {
    "ts": int(time.time() * 1000),
    "start_at": start_at,
    "occupancy_start": OCCUPANCY_START,
    "comfort_max": COMFORT_MAX,
    "model": {"a": round(a, 5), "b": round(b, 5), "c": round(c, 5)},
    "reason": "latest start meeting comfort band with forecast outdoor temperature",
}
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="hvac-opt-" + uuid.uuid4().hex[:8])
client.connect("broker.connectmq.com", 1883, keepalive=60)
client.loop_start()
client.publish(f"{BASE}/recommendation", json.dumps(rec), qos=1, retain=True).wait_for_publish()
client.loop_stop()
client.disconnect()
print("published to", f"{BASE}/recommendation")

Installez les dépendances avec pip install paho-mqtt numpy scikit-learn. Les coefficients ajustés sont proches des valeurs simulées, et la recommandation est nettement plus tardive qu'un démarrage fixe anticipé. Dans un bâtiment réel, comparez l'heure recommandée à l'horaire fixe pendant plusieurs semaines avant de la laisser agir ; la différence de durée de fonctionnement de la CTA correspond à l'économie attendue.

Appliquer les recommandations en toute sécurité

Envoyer des consignes à de vrais équipements demande plus de précautions que publier un graphique. Une progression pragmatique :

1. Mode conseil. Publiez uniquement des recommandations ; l'équipe d'exploitation les examine sur un tableau de bord à côté des résultats réels.
2. Automatisation bornée. Une passerelle ou une intégration GTB n'accepte les recommandations que dans des limites strictes, par exemple pas de démarrage avant 05:00 et des consignes uniquement entre 21 et 25 degC, et ignore les messages datant de plus de quelques minutes. L'expiration des messages de MQTT 5 est utile ici, car le broker supprime les commandes périmées.
3. Repli. Si les recommandations cessent d'arriver, la GTB revient automatiquement à son horaire normal.
4. Dérogation humaine. Les dérogations locales l'emportent toujours, et chaque dérogation est enregistrée comme un événement pour que le modèle puisse en tirer des enseignements.

Ces limites doivent se trouver dans l'intégration côté équipement, et pas seulement dans le service d'IA, afin qu'un bug du modèle ne puisse pas pousser les équipements hors des plages sûres. L'article sur le pilotage sûr des objets IoT par l'IA détaille ces garde-fous.

Mesurer les résultats

Il est facile d'annoncer des économies et difficile de les prouver. Comparez ce qui est comparable : des jours ouvrés avec une température extérieure et une occupation similaires, avant et après, ou une alternance de jours entre l'ancien et le nouvel horaire. Suivez le confort aussi soigneusement que l'énergie, en mesurant les minutes hors de la plage de confort par zone. Publiez les deux sous forme de topics pour qu'ils apparaissent à côté des données d'exploitation. Un modèle de prévision de charge énergétique sert ici de référence : l'écart entre la demande prévue selon l'ancienne stratégie et la demande mesurée avec la nouvelle est une estimation honnête de l'effet.

La couche de données sur ConnectMQ

ConnectMQ fournit le broker MQTT managé qui achemine les points de la GTB, les données météo, les recommandations et les résultats entre votre passerelle et votre service d'optimisation. L'explorateur de topics en direct affiche les recommandations à côté des températures de zone qu'elles influencent, et des règles d'alerte à seuil peuvent signaler les zones qui sortent de la plage de confort. Les modèles eux-mêmes s'exécutent dans vos propres clients, par exemple un service Python ou un flux Node-RED. Pour une vue d'ensemble de l'IA appliquée aux objets connectés, consultez le guide IA et IoT, et pour des techniques de prévision réutilisables, la prévision de séries temporelles IoT.

Démarrer avec ConnectMQ

Créez gratuitement un broker Serverless sur app.connectmq.com, sans carte bancaire. Connectez votre passerelle GTB avec les identifiants générés YOUR_USERNAME, YOUR_PASSWORD et YOUR_CLIENT_ID, collectez quelques semaines de données de zone et exécutez l'exemple d'optimum de démarrage sur votre propre bâtiment. Quand vous ajoutez d'autres bâtiments, une offre de broker MQTT cloud augmente le nombre de connexions sans modifier vos topics.

Questions fréquentes

Qu'est-ce que l'optimisation CVC par IA ?

L'optimisation CVC par IA utilise les données et des modèles du bâtiment pour choisir des heures de démarrage, des consignes et des horaires CVC meilleurs que des configurations fixes, réduisant la consommation d'énergie tout en maintenant les zones dans la plage de confort.

L'optimisation CVC par IA remplace-t-elle la gestion technique du bâtiment ?

Non. Elle agit généralement comme une couche de supervision qui recommande ou envoie des consignes et des horaires, tandis que les régulateurs de la GTB existante continuent de piloter les équipements et d'assurer la sécurité locale.

De combien de données a-t-on besoin pour commencer ?

Quelques semaines de température de zone, d'état CVC et de température extérieure à des intervalles de 5 à 15 minutes suffisent pour ajuster un modèle thermique simple d'optimum de démarrage. Les effets saisonniers nécessitent un historique plus long.

Comment sécuriser les modifications automatiques de consignes ?

Imposez des limites strictes et des contrôles d'âge des messages dans l'intégration côté équipement, revenez à l'horaire normal lorsque les recommandations cessent, et laissez toujours les dérogations locales prévaloir.