Category "Énergie et CVC"

8Juin

Domotique : comment mesurer les économies réelles de vos automatismes ?

by Domocasa
Énergie et CVC Guides techniques Smart Home et KNX

Illustration générée par IA — visuel conceptuel.

Une domotique bien conçue peut réduire des heures de fonctionnement inutiles (climatisation, éclairage, pompes, veilles…), mais il y a un piège : les “économies” ne se mesurent pas directement. Elles se déduisent d’une comparaison entre une période après et une référence (baseline), en tenant compte de ce qui change naturellement (météo, occupation, habitudes).

Ce guide propose une méthode résidentielle et “légère” : assez rigoureuse pour décider (garder / ajuster / abandonner un scénario), sans transformer la villa en laboratoire. L’objectif n’est pas de prouver un ROI “garanti”, mais de rendre vos décisions techniques vérifiables.

Ce que vous cherchez à prouver (et ce que vous ne devez pas promettre)

Objectif réaliste : isoler un effet, pas “geler le réel”

  • Vérifier si un scénario (Absence, stores automatiques, planning CVC…) diminue la consommation ou le temps de marche dans des conditions comparables.
  • Distinguer un effet scénario d’un effet météo (chaleur), d’un effet occupation (invités), ou d’un changement d’usage (nouvel équipement, nouvelles habitudes).

Limites à annoncer dès le départ (pour éviter les mauvaises conclusions)

  • Si l’effet attendu est faible, il peut se perdre dans le “bruit” du quotidien (variations d’occupation, météo, réglages manuels).
  • Un compteur général peut suffire… si l’effet est visible à l’échelle de toute la maison. Sinon, il faut souvent mesurer un poste précis (ex. CVC) plutôt que “tout”.
  • Un scénario peut réduire des kWh ou réduire des heures de marche sans réduire les kWh de manière évidente (cas typique : changement de confort, dérive de consigne, ou conditions climatiques différentes).

Pour replacer la mesure dans une démarche globale (confort + énergie + réglages), vous pouvez lire : domotique et économies d’énergie (dont KNX).

Étape 1 — Choisir le bon périmètre : quel scénario, quel poste, quelle question

Avant de mesurer, écrivez votre question en une phrase. Exemple :

  • « Le Mode Absence réduit-il la consommation quand la maison est vide ? »
  • « L’automatisation des stores réduit-elle le fonctionnement inutile de la climatisation l’après-midi ? »
  • « Le planning CVC évite-t-il des démarrages trop tôt / trop longtemps ? »

Ensuite, choisissez le poste énergétique le plus proche de l’effet attendu :

  • CVC (climatisation / chauffage) : souvent le levier principal en villa.
  • Pompes (piscine, surpression, circulation) : fonctionnement long et parfois invisible.
  • ECS (chauffe-eau) : intéressant si vous avez une stratégie d’absence / relance.
  • Éclairage : gains possibles, mais souvent “dilués” dans la consommation totale si la maison a beaucoup d’autres charges.

Étape 2 — Choisir un niveau de mesure (sans sur-instrumenter)

Attention sécurité : dès que vous ajoutez un compteur, un tore (TC) ou que vous intervenez sur un tableau/sous-tableau, vous êtes potentiellement au contact de tensions dangereuses (risque d’électrocution et d’incendie). Pour tout câblage ou pose au tableau, faites intervenir un électricien qualifié, avec mise hors tension/consignation, et selon les règles en vigueur. Ce guide décrit une méthode de comparaison avant/après, pas une procédure de câblage.

Niveau A : relevé simple (sans matériel supplémentaire)

Quand c’est pertinent : vous cherchez un résultat “macro” (maison secondaire, longues absences, changements visibles).

  • Relevez le compteur à heure fixe (quotidien ou hebdomadaire).
  • Tenez un mini-journal : présence/absence, invités, pannes, événements inhabituels.

Niveau B : un point de mesure dédié (souvent le meilleur compromis)

Quand c’est pertinent : vous voulez vérifier un scénario qui cible un poste (CVC, ECS, pompes).

  • Mesurez un seul circuit (ou un sous-tableau) : celui qui porte l’économie attendue.
  • Exigez un historique exploitable (pour comparer des périodes) et une mesure cohérente.

Niveau C : sous-comptage ciblé (si vous avez une vraie question d’arbitrage)

Quand c’est pertinent : vous comparez plusieurs scénarios ou plusieurs postes, et le compteur général est trop “bruité”.

Dans ce cas, la logique est la même que le sous-comptage en bâtiment : mesurer ce qui permet ensuite une décision, pas “tout mesurer”. Pour la démarche (transposable au résidentiel), voir : sous-comptage énergétique.

Étape 3 — Définir la baseline : votre “contrat de comparaison”

Une baseline n’est pas “un mois de facture”. C’est un état de référence documenté, suffisamment clair pour qu’un technicien (ou vous-même, plus tard) puisse comprendre ce qui a été comparé.

Baseline minimale (une page suffit)

  • Périmètre : compteur général ou circuit(s) mesuré(s).
  • Scénario testé : règles exactes (horaires, conditions, consignes, temporisations).
  • Conditions d’usage : occupation, pièces utilisées, consignes de confort (notamment CVC).
  • Variables externes : météo (au moins une indication simple), période (vacances, événements).

Point clé : les méthodologies de mesure & vérification rappellent que des variables indépendantes typiques sont la météo et l’occupation. Si vous ne les tracez pas, vous risquez d’attribuer au scénario un effet qui vient d’ailleurs.

Modèle de fiche baseline / journal (copier-coller)

Objectif : avoir une trace courte mais exploitable (et comparable) d’une période témoin et d’une période test.

Champ À renseigner Pourquoi c’est utile
Période Date début / date fin Évite les comparaisons “floues” (et facilite un re-test plus tard).
Périmètre mesuré Compteur général / circuit(s) mesuré(s) Permet de savoir si l’effet visé peut réellement apparaître dans la mesure.
Scénario ON/OFF + version des paramètres (horaires, consignes, temporisations…) Sans version, on ne sait pas ce qui a été “validé”.
Occupation Présence/absence, invités, zones utilisées Le “bruit” principal en résidentiel vient souvent des usages.
Météo (simple) Chaud / doux / frais (ou T° max/min) + ensoleillement perçu Indispensable dès que le CVC et/ou les stores sont concernés.
Événements atypiques Panne, travaux, maintenance, changement d’équipement Explique les jours “hors courbe” au lieu de les masquer.

Étape 4 — Choisir un design de test simple (et plus robuste qu’un “avant/après” brut)

Option 1 : avant / après (simple, mais fragile)

  • Une période témoin (baseline), puis une période après activation du scénario.
  • À réserver aux cas où les conditions sont proches (même type de météo et d’occupation).

Option 2 : alternance A/B (souvent la meilleure en résidentiel)

Pour éviter que la météo “dérive” entre deux périodes :

  • A : scénario désactivé (conditions nominales)
  • B : scénario activé
  • Alternez plusieurs fois, puis comparez A vs B.

Cette méthode est généralement plus lisible pour des scénarios comme : planning CVC, “absence courte”, ou ajustement de stores.

Option 3 : journées comparables (“journées jumelles”)

Particulièrement utile pour les stores (effet solaire) : comparez des journées qui se ressemblent (occupation + météo), plutôt que des semaines éloignées.

Étape 5 — Définir des indicateurs (KPI) actionnables

Ne cherchez pas “le KPI parfait”. Cherchez un KPI qui permet de décider.

KPI possibles (selon vos moyens de mesure)

  • Énergie par jour (kWh/jour) : simple, universel.
  • Heures de marche (runtime) : très utile en CVC si l’énergie est difficile à isoler.
  • Pointe de puissance : utile si vous cherchez à réduire des pics (démarrages simultanés).

N’oubliez pas le confort (sinon votre conclusion est incomplète)

Un scénario peut “économiser” parce qu’il dégrade le confort (consigne plus large, extinction trop rapide, etc.). Ajoutez un indicateur minimal de confort, par exemple :

  • retour au confort jugé acceptable / non acceptable,
  • plaintes d’usage (trop froid, trop chaud, stores qui gênent),
  • écarts visibles entre consigne et ressenti.

Étape 6 — Recetter la mesure (avant d’analyser les économies)

Une analyse propre commence par des données fiables. Une erreur classique est d’analyser des semaines… avec une mesure fausse (mauvais sens de tore, phase, référence tension, circuit mesuré non conforme au plan, etc.).

Checklist de recette “mesure”

  • Le circuit mesuré correspond-il réellement au poste (ex. CVC) ?
  • Les valeurs instantanées sont-elles plausibles quand l’équipement démarre / s’arrête ?
  • Le compteur/historique conserve-t-il des données sur la durée (et à une résolution utile) ?
  • Existe-t-il un seuil bas sous lequel l’équipement mesure de la puissance mais n’additionne pas l’énergie ? (Ce point varie selon les compteurs : à vérifier sur la documentation du modèle utilisé.)

Étape 7 — Analyser “prêt à décider” (sans faire une thèse)

Nettoyer (sans tricher)

  • Identifiez les jours “anormaux” (invités, travaux, panne, absence inhabituelle).
  • Ne les supprimez pas en silence : notez la raison.

Comparer de façon robuste

  • Comparez A vs B avec un indicateur stable (kWh/jour ou runtime).
  • Si la série est très variable, la bonne conclusion n’est pas “ça marche / ça ne marche pas”, mais : “on n’a pas assez de signal”. Dans ce cas, mesurez plus ciblé (poste) ou améliorez le design A/B.

Décider

  • Effet clair : on garde le scénario, puis on documente la version (paramètres) validée.
  • Effet incertain : on ajuste (temporisations, seuils, consignes), puis on reteste.
  • Effet nul : soit le scénario n’a pas de levier réel, soit il vise le mauvais poste, soit la mesure est trop large.

Checklists par scénario : quoi mesurer, quoi surveiller

Scénario “Mode Absence” (villa principale ou secondaire)

  • Mesure recommandée : compteur général + (si possible) mesure CVC.
  • Journal : heures d’absence, ouverture/fermeture maison, exceptions (ménage, gardiennage, invités).
  • Point de vigilance : distinguer “absence courte” et “absence longue” (les règles et le confort attendu ne sont pas les mêmes).

Si vous cherchez aussi une liste “projet” (quoi couper / quoi laisser, comment éviter les risques), voir : Mode Absence et maison secondaire : checklist domotique.

Stores automatiques (objectif : réduire des apports solaires inutiles)

  • Mesure recommandée : poste CVC (énergie ou runtime) + note simple sur l’ensoleillement perçu.
  • Design recommandé : alternance A/B ou journées comparables.
  • Point de vigilance : l’utilisateur doit pouvoir reprendre la main (sinon le scénario finit désactivé).

Optimisation CVC (plannings, consignes, présence)

  • Mesure recommandée : runtime ou énergie du poste CVC.
  • Journal : consignes, modes, ouvertures de fenêtres (si pertinentes), usage réel des pièces.
  • Point de vigilance : ne pas conclure uniquement sur kWh si la météo change fortement ; la comparaison A/B aide justement à limiter ce biais.

Le livrable final : une page qui “tient” dans le temps

À la fin, vous devez pouvoir produire un document court, partageable avec un intégrateur, un BET, ou un exploitant :

  • Scénario testé (paramètres exacts)
  • Période(s) et méthode (avant/après ou A/B)
  • Données utilisées (kWh/jour, runtime, notes météo/occupation)
  • Résultat (tendance + niveau de confiance)
  • Décision (garder / ajuster / abandonner / mesurer plus finement)

Si vous êtes en phase projet (ou réception), cette logique “mesure + recette” se prolonge naturellement dans une démarche de tests plus large : réception d’une installation domotique.

Et ensuite : passer de la mesure à une démarche d’optimisation

Une fois votre protocole en place, vous pouvez décider sereinement :

  • où le sous-comptage apporte de la valeur,
  • quels scénarios méritent d’être raffinés,
  • quels automatismes sont “jolis” mais peu utiles.

Si vous souhaitez structurer un projet Smart Home orienté confort et énergie (villa neuve ou rénovation), découvrez notre page Domotique / Smart Home et notre approche Économie d’énergie. Une prise de contact en amont permet souvent d’éviter des scénarios difficiles à mesurer, ou des mesures impossibles à recetter une fois les finitions terminées.

Sources et documentation

4Juin

Location saisonnière et Airbnb : quelle domotique pour simplifier les séjours ?

by Domocasa
Énergie et CVC Smart Home et KNX Sûreté et Sécurité

Illustration générée par IA — visuel conceptuel.

Pourquoi la domotique “locatif / Airbnb” est un cas d’usage à part

En location courte durée, la question n’est pas seulement « quelles fonctions domotiques installer ? ». L’enjeu est d’obtenir un logement exploitable par des invités (sans formation, sans support permanent) et réversible entre deux séjours (check-in / check-out), avec des modes dégradés prévus (Internet indisponible, smartphone déchargé, coupure électrique, etc.).

Ce mini-guide reste volontairement centré sur l’architecture d’usage et d’exploitation (pas sur le juridique locatif). Il s’appuie sur des briques courantes au Maroc : contrôle d’accès, vidéophonie IP, réseau Wi‑Fi, CVC, scénarios et segmentation.

Le principe directeur : simplicité pour l’invité, contrôle pour le propriétaire

Une installation “facile à vivre” en locatif se reconnaît à trois choix structurants :

  • Commandes locales (boutons, thermostat, clavier) prioritaires sur l’app : l’invité ne doit pas dépendre d’un compte ou d’une application.
  • Droits temporaires (accès, Wi‑Fi, éventuellement zones techniques) gérés simplement et révocables.
  • Fonctions essentielles locales (au moins en “dégradé”) : un problème Internet ne doit pas rendre l’accès ou le confort impossibles.

Pour replacer ces choix dans une approche Smart Home globale (architecture avant gadgets), voir aussi : Domotique au Maroc : définition, fonctionnement, usages et budget.

Brique n°1 : contrôle d’accès avec droits temporaires (et plan B)

En locatif, le contrôle d’accès doit répondre à une question simple : qui peut entrer, où, et à quel moment ? Les moyens (code, badge, smartphone, clé mobile…) viennent ensuite.

Pour les fondamentaux et les arbitrages (code vs badge vs mobile), vous pouvez vous appuyer sur notre article : Contrôle d’accès : badge, smartphone, biométrie ou code ?

Ce que vous devez exiger pour un usage “Airbnb-ready”

  • Accès temporaires (fenêtre de validité) faciles à créer et à révoquer.
  • Un plan B “invité” si le smartphone ne marche pas (clavier à code, badge, ou autre solution de secours selon le projet).
  • Un plan B “propriétaire / ménage” distinct des invités (droits séparés, horaires séparés).
  • Comportement en perte Internet explicite et testé (ce point dépend de l’architecture de la serrure et/ou du contrôleur).

Attention au piège du “code permanent partagé”

Un code unique partagé et permanent est simple… mais difficile à gouverner en exploitation. En locatif, privilégiez des mécanismes qui permettent des accès individualisés et/ou limités dans le temps, afin de garder une exploitation propre (rotation des accès, révocation, etc.).

Brique n°2 : vidéophone IP pour gérer les imprévus (invité perdu, livreur, prestataire)

Un vidéophone IP bien intégré peut devenir votre “filet de sécurité” exploitation : vérifier un visiteur, dialoguer, et ouvrir un accès selon les règles du projet. Une mise en œuvre fiable suppose une architecture “système d’accès”, pas une simple sonnette connectée.

Pour cadrer correctement l’architecture, voir : Vidéophone IP : gérer ses visiteurs et ses accès à distance.

Bonnes pratiques d’architecture (usage locatif)

  • Séparer interphonie et logique d’ouverture (éviter de concentrer le déverrouillage dans un équipement exposé).
  • Clarifier qui peut ouvrir à distance (propriétaire, conciergerie, personne de confiance) et comment vous révoquez ces accès.
  • Prévoir un mode dégradé : si l’appel smartphone ne fonctionne plus, comment l’invité fait-il sonner et comment ouvre-t-on ?

À noter (point “ingénierie”) : certains fabricants documentent des interfaces (API) permettant de piloter ou superviser des fonctions d’interphonie IP et de relais d’ouverture ; c’est une bonne piste quand vous voulez éviter le bricolage et rendre l’ensemble maintenable.

Brique n°3 : réseau Wi‑Fi exploitable (invités vs objets connectés vs administration)

En locatif, le Wi‑Fi n’est pas un bonus. C’est une dépendance fonctionnelle (TV, streaming, interphonie, parfois accès) et un sujet de sécurité (équipements invités qui ne doivent pas voir vos équipements techniques).

Segmentation minimale recommandée

  • Wi‑Fi Invités : Internet uniquement (et idéalement isolation entre clients).
  • Réseau “IoT / technique” : équipements domotiques, interphonie, éventuellement caméras (selon projet), passerelles.
  • Réseau “Admin” : interfaces d’administration (accès restreint, mots de passe, maintenance).

Cette logique se formalise généralement via VLAN + règles de filtrage. Pour comprendre le principe (et éviter les erreurs classiques), voir : VLAN : pourquoi séparer domotique, caméras, invités et équipements professionnels ?.

Isolation des clients : un détail qui change l’exploitation

Dans beaucoup de contrôleurs Wi‑Fi, il existe une option d’isolation des clients pour bloquer la communication entre deux appareils invités sur un même SSID/AP. C’est particulièrement pertinent en hébergement court séjour, sous réserve de tester les exceptions utiles (casting, imprimantes, etc. si vous les autorisez).

Scénarios check-in / check-out : deux scènes qui suffisent souvent

En location saisonnière, on cherche rarement “plus de scénarios”. On cherche surtout deux états robustes qui évitent les oublis et stabilisent l’exploitation.

Scénario “ARRIVÉE / CHECK-IN” (objectif : accueil simple, zéro support)

  • Accès : activation du droit invité sur la fenêtre prévue (et vérification que le plan B est disponible).
  • Éclairage : une scène d’accueil lisible (pas dix boutons).
  • CVC : passage en mode Confort (ou pré‑conditionnement si vous le décidez), avec limites de fonctionnement adaptées au projet.
  • Wi‑Fi : SSID invité actif, informations d’accès claires (idéalement un seul message “mode d’emploi”).

Scénario “VACANT / CHECK-OUT” (objectif : sobriété + tranquillité)

  • Accès : expiration automatique du droit invité + maintien (séparé) d’un droit ménage/maintenance.
  • Éclairage : extinction générale (avec exceptions maîtrisées).
  • CVC : bascule vers un mode plus sobre (Standby / Nuit / Protection selon stratégie), sans promesse de gain chiffré a priori.
  • Réseau : optionnel selon projet (vous pouvez laisser le Wi‑Fi invité actif, ou le limiter si cela sert vraiment votre exploitation).

Pour éviter une maison “qui se contredit” (automatique vs manuel), il est utile de formaliser les priorités et la reprise en main. À lire : Priorités et “reprise en main” : concevoir une maison qui n’énerve pas.

Sobriété énergétique entre deux séjours : où sont les gains réalistes

En locatif, la sobriété se joue surtout quand le logement est vide. L’objectif n’est pas de “punir” l’invité, mais de reprendre la main sur les dérives (climatisation laissée trop longtemps, éclairages oubliés, fonctionnement inutile hors occupation).

CVC : raisonner en modes plutôt qu’en ON/OFF

La logique la plus exploitable consiste à utiliser des modes (Confort / Standby / Nuit / Protection) plutôt que des coupures brutales. C’est cohérent avec les pratiques documentées côté KNX chauffage/clim (modes standardisés), tout en restant adaptable à d’autres architectures.

Pour la méthode CVC (occupation, fenêtres, pré‑conditionnement, temporisations), voir : Réduire la consommation de climatisation grâce à l’automatisation du bâtiment.

Éclairage et prises : attention aux “exceptions”

Une extinction générale ne doit pas couper n’importe quoi. En conception, vous devez lister les exceptions : box Internet, contrôleurs techniques, réfrigérateur, équipements indispensables au fonctionnement (selon votre architecture). Une scène VACANT réussie est une scène documentée.

Modes dégradés : la checklist qui évite les urgences

Le locatif sans support exige de définir à l’avance ce qui se passe “quand ça tombe”. Voici une grille simple à traiter en conception, puis à recetter.

Tableau — incidents typiques et réponse attendue

Incident Ce que l’invité doit pouvoir faire Ce que le propriétaire doit pouvoir faire Limites à accepter / à tester
Internet indisponible Entrer + commander les fonctions essentielles localement Garder un plan de diagnostic (réseau / opérateur) sans bloquer l’usage Selon les produits, certaines fonctions “smartphone” peuvent tomber : c’est normal si un fallback existe
Smartphone invité déchargé / perdu Entrer via solution alternative (code, badge, etc.) Révoquer / re‑délivrer un accès temporaire Ne pas dépendre d’un seul moyen d’accès
Coupure électrique Accès et sécurité selon stratégie du site Décider ce qui doit être secouru (routeur, Wi‑Fi, contrôle d’accès…) Un onduleur ne rend pas “tout” autonome : dimensionnement à faire par services
Batterie faible serrure / contrôleur Entrer sans blocage (plan B) Recevoir une alerte exploitable + procédure de remplacement Le process d’exploitation compte autant que le produit

Cahier des charges (prêt à copier) : ce qu’il faut demander à l’intégrateur

Pour un projet locatif, l’objectif n’est pas d’exiger “la meilleure marque”, mais de verrouiller des comportements mesurables.

Contrôle d’accès

  • Droits temporaires (fenêtre horaire) + révocation immédiate.
  • Plan B sans Internet / sans smartphone.
  • Procédure batteries (alerte, stock, délai, test).

Vidéophonie / accueil

  • Architecture relais/commande d’ouverture côté protégé.
  • Gestion des comptes (propriétaire, conciergerie, prestataires) et révocation.
  • Tests jour/nuit (audio/vidéo/ergonomie).

Réseau

  • Segmentation (Invités / IoT / Admin) et règles inter‑réseaux minimales.
  • Isolation clients sur Wi‑Fi invités (si compatible) + tests des exceptions (casting, etc.).

Exploitation

  • Deux scènes documentées : ARRIVÉE / VACANT (actions + exceptions).
  • Une page “mode d’emploi invité” (très courte) + un runbook propriétaire (procédures de secours).

Conclusion : viser une maison “robuste”, pas une maison “spectaculaire”

Pour un logement loué, la meilleure domotique est celle qui réduit les sollicitations, limite les incidents et revient à un état propre entre deux séjours. Si vous souhaitez aller plus loin sur l’optimisation, nos équipes peuvent vous aider à cadrer une architecture (accès, réseau, CVC, scénarios) proportionnée à votre bien et à votre mode d’exploitation.

Si vous envisagez un projet Smart Home au Maroc, préparez vos plans et une liste d’usages (check-in, check-out, ménage, maintenance) avant consultation : c’est le moyen le plus simple d’obtenir des offres comparables et une installation maintenable.

Sources et documentation

1Juin

Maison secondaire : quels réglages domotiques prévoir pendant votre absence ?

by Domocasa
Énergie et CVC Smart Home et KNX Sûreté et Sécurité

Illustration générée par IA — visuel conceptuel.

Une maison secondaire laissée vide (week-ends, vacances, parfois plus longtemps — très courant au Maroc) a deux ennemis : les consommations inutiles (CVC, ballons, veilles, pompes, réseaux) et les incidents non détectés (fuite d’eau, coupure électrique, surchauffe locale, intrusion).

Un bon « mode Absence / Vacances » n’est donc pas un bouton Tout couper. C’est une mise en régime : on coupe ce qui peut l’être, sans perdre ce qui permet de surveiller, protéger et remettre en service proprement.

Ce guide est volontairement agnostique marques. Quand votre projet repose sur KNX, les mêmes principes s’appliquent, avec l’avantage d’un socle local et durable (voir notre page Domotique / Smart Home).

1) Point de départ : classer vos équipements en 3 familles (avant d’automatiser)

Avant de programmer un scénario, faites l’inventaire de vos circuits et équipements, puis classez-les. C’est cette étape qui évite les « modes Absence » dangereux (coupure d’un équipement technique) ou inefficaces (tout reste alimenté).

Famille Objectif Exemples typiques Risque si mal géré
A — Doit rester ON Continuité + sécurité technique + alertes Alarme, réseau minimal, caméras/NVR (si utilisés), capteurs critiques (fuite, T° local technique) Plus d’alertes, perte d’accès distant, incident découvert tard
B — Peut être coupé Supprimer les veilles et consommations « confort » AV/home cinema, TV/box, prises non essentielles, éclairages intérieurs Faible (inconfort au retour si mal anticipé)
C — Dépend (à valider) Optimiser sans casser une fonction technique Ballon ECS, surpresseur, pompes piscine/forage, CVC, arrosage Élevé : dégâts, pannes, remise en route compliquée

Conseil projet : la catégorie C se traite avec les intervenants concernés (CVC, plomberie, piscine), parce qu’elle dépend des équipements et de leur logique (protection, antigel, cycles, alarmes, contraintes constructeur).

2) Concevoir le “Mode Absence” comme un état central + des exceptions documentées

La méthode la plus robuste consiste à créer un état central (ex. ABSENCE) et à faire réagir chaque lot (eau, CVC, éclairage, réseau) selon ses règles. Cela évite d’empiler des ordres ponctuels difficiles à maintenir.

2.1 Trois variantes utiles (même si vous commencez simple)

  • Absence courte : sobriété immédiate, retour simple.
  • Vacances : économies plus fortes, protection du bâtiment, alerting renforcé.
  • Longue absence : supervision “industrielle” (accès distant maîtrisé, procédures, tests réguliers).

2.2 Les exceptions à écrire noir sur blanc (sinon le scénario se retourne contre vous)

  • Ce qui ne doit jamais être coupé : équipements techniques listés (ex. frigo, équipements réseau/sécurité, contrôleurs nécessaires).
  • Ce qui peut être coupé mais pas en permanence : pré-conditionnement CVC avant retour, ECS à relancer avant arrivée, etc.
  • Ce qui doit rester pilotable localement : commandes de base, fonctionnement sans Internet quand c’est possible (principe de résilience).

3) Checklist “quoi couper / quoi laisser” par lots

3.1 Électricité : d’abord couper “logiquement”, puis (si prévu) couper “électriquement”

Deux leviers existent :

  • Coupure logique : vous mettez à l’arrêt par commande (scènes, ordres, délestage).
  • Coupure électrique : vous retirez l’alimentation de certains circuits pour éliminer les veilles (plus efficace, mais plus exigeant en conception).

À couper (typique)

  • Audio/vidéo, amplis, box, équipements loisirs.
  • Prises “confort” : chargeurs, lampadaires décoratifs, équipements non critiques.
  • Éclairage intérieur : extinction générale + inhibition des automatismes de confort.

À laisser ON (typique)

  • Alimentations et contrôleurs nécessaires au fonctionnement local (selon architecture).
  • Équipements de sécurité technique : alarme, caméras/NVR si votre stratégie les inclut.
  • Équipements réseau minimaux si vous voulez de la supervision/alertes.

À traiter au cas par cas

  • Éclairage extérieur : sécurité et cheminements (plutôt horaires / crépuscule / présence).
  • Local technique : ventilation, extracteurs, équipements de traitement d’eau, etc.

Pour aller plus loin sur la logique “sobriété sans promesses”, vous pouvez compléter avec Comment la domotique — et KNX en particulier — permet d’économiser de l’énergie.

3.2 Eau : fermer + détecter + définir le scénario “fuite” (avec un vrai mode dégradé)

En maison secondaire, la stratégie la plus robuste est souvent :

  • Vanne générale motorisée (positionnée au bon endroit, accessible).
  • Détection de fuite dans les zones à risque (cuisine, buanderie, local technique).
  • Scénario fuite : alerte + mise en sécurité (fermeture vanne, arrêt surpresseur si présent) si l’architecture l’autorise.

Sur ce sujet, notre guide détaillé Détection de fuite d’eau en villa : où la poser, quoi faire déclencher, et comment éviter les fausses alertes complète la logique Absence/Vacances.

Exception fréquente : piscine/arrosage. Dans ce cas, évitez le “tout ou rien” : il peut être plus pertinent d’isoler par zones (plusieurs vannes) et de ne laisser ouvert que ce qui est réellement nécessaire, avec une surveillance plus stricte (anomalies, temps de marche, etc.).

3.3 CVC : éviter le OFF total « aveugle » ; préférer des modes Éco / Protection

Couper brutalement le CVC peut sembler logique… mais selon votre villa, cela peut aussi créer :

  • un retour au confort trop lent,
  • une dérive d’humidité (selon bâtiment/usage),
  • des conflits de commande (thermostats locaux vs supervision),
  • des comportements “surprenants” au redémarrage.

Approche recommandée : raisonner en modes plutôt qu’en ON/OFF. Dans l’écosystème KNX, le concept HVAC normalise notamment un mode HVAC et des niveaux de consigne structurés (Confort / Standby / Économique / Protection). Cela se prête bien à un Mode Absence qui élargit les consignes sans abandonner totalement la protection du bâtiment.

Si votre projet inclut une climatisation multi-zones (VRV/VRF, gainable, etc.), l’enjeu est d’éviter les promesses d’intégration “génériques” : les fonctions réellement pilotables dépendent de l’interface constructeur. Voir KNX et climatisation VRV/VRF : comment intégrer correctement le CVC ? et, côté sobriété, Réduire la consommation de climatisation grâce à l’automatisation du bâtiment.

Bon réflexe (maison secondaire) : si vous autorisez un maintien minimal, documentez clairement :

  • qui est “maître” du mode (thermostat local, superviseur, calendrier),
  • quand l’utilisateur peut reprendre la main,
  • ce qui se passe si Internet est indisponible (fonctionnement local).

3.4 Éclairage & stores : sobriété + dissuasion, sans se trahir

  • Intérieur : extinction générale, automatismes confort inhibés.
  • Extérieurs : limiter aux zones utiles (accès, cheminements), avec une logique simple et compréhensible (horaires / crépuscule / présence).
  • Simulation de présence (si souhaitée) : privilégier une simulation “crédible” plutôt qu’un scénario parfait et répétitif. Et prévoir une règle claire : intrusion confirmée → éclairage extérieur + alerte.

Dans tous les cas, pensez “priorités et reprise en main” : une automatisation trop rigide finit désactivée. Voir Priorités et “reprise en main” : concevoir une maison qui n’énerve pas.

3.5 Réseau & accès distant : réduire au strict nécessaire, sans casser la supervision

Le réseau est souvent la condition des alertes (caméras, sécurité technique, accès distant). L’objectif n’est pas de “tout garder”, mais de garder un socle minimal exploitable.

  • À conserver : routeur/firewall, switch(s) nécessaires, accès Internet si vous en dépendez pour les alertes.
  • À durcir : mots de passe, comptes, accès distant, exposition Internet.
  • À clarifier : ce qui fonctionne sans Internet (local) vs ce qui dépend d’un service externe.

Deux points reviennent systématiquement en villa :

3.6 Sûreté : intégrer sans mélanger les responsabilités

Un Mode Absence est souvent déclenché en même temps que l’armement. Gardez un principe : la domotique peut orchestrer (éclairage extérieur, notifications, scénarios), mais l’alarme intrusion doit conserver son architecture et ses fonctions essentielles.

Pour approfondir : Alarme intrusion : comment concevoir la sécurité d’une villa haut de gamme ? et Domotique & Sécurité : comment KNX renforce vos systèmes d’alarme.

Si votre stratégie inclut la vidéo, pensez aussi au “mode absence” côté exploitation (droits, accès, stockage, réseau) : Vidéosurveillance IP : comment concevoir un système réellement efficace ?.

4) Deux scénarios à écrire (et à tester) avant de partir

4.1 Scénario “Activation Absence” (étapes simples et vérifiables)

  1. Pré-check : ouvrants critiques (selon projet) + état réseau/sécurité.
  2. Eau : fermeture vanne (si stratégie retenue) + confirmation d’état.
  3. CVC : bascule en mode Éco/Protection (selon durée).
  4. Électricité : arrêt des charges B (confort) + maintien des charges A (sécurité/supervision).
  5. Éclairage : tout OFF intérieur + stratégie extérieurs.
  6. Notification : un résumé (mode activé + exceptions actives).

4.2 Scénario “Retour / Arrivée” (éviter la remise en route “dans le désordre”)

  1. Conserver sécurité et réseau en fonctionnement.
  2. Remettre l’eau (selon votre procédure : visuelle/présence sur site si nécessaire).
  3. Relancer ECS/CVC selon la stratégie choisie (pré-conditionnement plutôt que “plein confort permanent”).
  4. Réactiver les automatismes confort (scènes, routines, etc.).

5) Recette : tests réalistes (et leurs limites) avant la « vraie » absence

Un Mode Absence se valide à vide, sur une courte période, avant un départ long. L’objectif est de découvrir les exceptions (équipements oubliés, dépendances réseau, faux positifs) dans un contexte maîtrisé.

  • Test réseau : accès distant OK, caméra(s) OK, notifications OK.
  • Test eau : fermeture/ouverture vanne, détection fuite (test contrôlé), procédure de remise en eau.
  • Test CVC : bascule en mode Éco/Protection, puis retour en confort ; vérifier qu’il n’y a pas de conflit de commande.
  • Test “coupure” : si vous avez un onduleur/UPS, vérifier le comportement en micro-coupure et au retour secteur.

Si vous souhaitez dimensionner correctement la continuité électrique (réseau, caméras, passerelles), voir UPS/onduleur pour réseaux, caméras et domotique : que peut-on réellement maintenir en cas de coupure ?.

6) Les erreurs classiques en maison secondaire (et comment les éviter)

  • Couper le routeur : vous perdez alertes et diagnostic à distance.
  • Couper une pompe “au hasard” : certaines fonctions techniques doivent être comprises avant d’être stoppées.
  • Avoir deux maîtres de consigne CVC : thermostat local + supervision + calendrier → incohérences.
  • Simulation de présence trop parfaite : peu crédible et parfois contre-productive.
  • Accès distant exposé : pas de redirections improvisées ; accès maîtrisé et documenté.
  • Absence de tests : le scénario “marche sur plan” mais échoue en conditions réelles.

7) Quand demander une étude / mise en service (et quoi exiger)

Vous avez intérêt à formaliser ce Mode Absence dans votre cahier des charges ou votre DOE : la valeur est dans la maintenabilité (et pas seulement dans “ça marche aujourd’hui”).

Besoin d’un Mode Absence conçu pour votre villa (neuf ou rénovation) ? Vous pouvez passer par notre équipe Domotique / Smart Home pour cadrer l’architecture, les scénarios et la recette, en gardant une logique sobre et robuste.

Sources et documentation

30Avr

Hôtel et bureaux : centraliser les relevés d’eau et d’énergie avec M-Bus et OMS

by Domocasa
Énergie et CVC Hôtellerie Smart Building et GTB

Illustration générée par IA — visuel conceptuel.

Pourquoi OMS / M‑Bus devient un “bon réflexe” en sous-comptage multi-fluides

Dans un hôtel ou un bâtiment tertiaire, le sous-comptage ne concerne rarement une seule énergie. On veut souvent suivre plusieurs fluides (eau, énergie thermique, électricité, parfois gaz selon site) et plusieurs périmètres (chambres, étages, cuisines, buanderie, CVC, espaces communs). Le risque classique n’est pas d’installer “trop peu” de compteurs, mais d’obtenir des données incohérentes et difficiles à exploiter : unités mélangées, noms instables, trous de collecte, difficultés de maintenance, et intégration GTB/BMS fragile.

Dans ce contexte, OMS (Open Metering System) est intéressant parce qu’il vise à structurer l’interopérabilité et la lecture automatique des compteurs (AMR). L’OMS-Group présente OMS comme basé sur M‑Bus et orienté vers des applications multi-fluides (eau, chaleur, gaz, etc.). Source OMS-Group.

Point essentiel : OMS n’est pas une promesse de compatibilité universelle avec “tous les compteurs M‑Bus”. Une approche de projet robuste consiste plutôt à cadrer une chaîne cohérente : compteurs explicitement OMS (idéalement listés/certifiés), collecte (filaire ou radio), puis passerelle(s) IP et intégration GTB validées par recette.

Rappels utiles : M‑Bus filaire, wM‑Bus et OMS — qui fait quoi ?

M‑Bus filaire : un bus de comptage (polling / “pull”)

Le M‑Bus filaire (Meter‑Bus) est un bus historiquement utilisé pour la télérelève de compteurs. En Europe, il s’appuie notamment sur la série EN 13757 ; la partie EN 13757‑2 décrit des éléments liés à la communication M‑Bus filaire (couches physique et liaison) pour des systèmes de comptage (notamment eau, gaz, chaleur). Référence (fiche DIN).

En pratique projet, le M‑Bus filaire se prête bien à une collecte de type passerelle qui interroge (pull/polling) : la passerelle questionne les compteurs selon une fréquence de lecture choisie.

wM‑Bus / OMS : radio (télégrammes “push”) et contraintes de bâtiment

OMS décrit aussi des modes de collecte radio via wM‑Bus. Dans la spécification OMS Gen 5 (Vol.2 Primary Communication), la logique est explicitement décrite comme :

  • M‑Bus filaire (2 fils) en mode “pull” (interrogation par la passerelle),
  • wM‑Bus en mode “push” (télégrammes radio émis périodiquement par les compteurs), avec des cas particuliers selon équipements.

Référence : OMS Spec Vol.2 Primary Communication (PDF).

La même spécification rappelle également un point de dimensionnement important : la capacité (nombre de périphériques) gérable côté M‑Bus dépend de la passerelle et doit être donnée par le fabricant. Autrement dit : on ne “déduit” pas cette limite d’un texte OMS ; on l’exige sur la fiche technique, et on la valide en recette. (OMS Spec Vol.2, PDF).

Choisir l’architecture de collecte : ce que vous décidez vraiment

Pour “faire remonter des compteurs dans une GTB”, il faut séparer deux couches :

  • Couche terrain (compteurs ↔ collecte) : M‑Bus / wM‑Bus / OMS, topologie, accès aux locaux, contraintes radio, alimentation, maintenance.
  • Couche IP/GTB (collecte ↔ supervision) : passerelles IP, mapping des points, protocole vers la GTB/BMS, cybersécurité, supervision et DOE.

Option A — M‑Bus filaire : stabilité et diagnostic, au prix du câblage

En neuf (ou rénovation lourde), le M‑Bus filaire est souvent apprécié pour sa prévisibilité : câblage identifié, lecture par polling, troubleshooting plus direct. C’est aussi cohérent avec une démarche “bâtiment” : infrastructure d’abord, services ensuite.

Points de vigilance typiques :

  • accès aux gaines et passages (ne pas découvrir les impossibilités de cheminement en fin de chantier) ;
  • localisation des passerelles et des départs ;
  • stratégie de maintenance : qui intervient sur un compteur, sur une passerelle, sur le réseau IP ?

Option B — wM‑Bus / OMS : utile quand le câblage est difficile, mais à traiter comme un vrai lot radio

Le wM‑Bus peut devenir pertinent lorsque tirer un bus est disproportionné (bâtiment existant, zones compliquées, phasage d’hôtel). Mais il introduit des variables qui doivent être anticipées : propagation radio réelle dans le bâtiment, implantation des collecteurs, et contraintes locales (cadre radio et agrément des équipements à vérifier au Maroc selon modèles/variantes).

La spécification OMS Gen 5 (Vol.2) précise notamment le périmètre des modes supportés (dans ce document : support de modes spécifiques, et absence de multi-hop relaying). La conséquence pratique est simple : on ne compte pas sur un “maillage” automatique ; on conçoit l’implantation et on la recète. Référence : OMS Spec Vol.2 (PDF).

Intégration vers IP / GTB : la passerelle fait (souvent) la différence

OMS structure l’échange entre compteurs et collecte. Mais dès que vous voulez exploiter ces données dans une GTB/BMS, le sujet devient : qu’est-ce que la passerelle expose sur IP, et comment les points sont nommés et maintenus ?

Dans les projets, on rencontre typiquement des passerelles/serveurs M‑Bus qui remontent vers :

  • BACnet/IP (courant en GTB),
  • Modbus TCP (très utilisé pour l’énergie et certaines supervisions),
  • et parfois des approches “IT/IoT” selon stratégie (à cadrer au cas par cas).

À titre d’exemples documentés par des fabricants :

  • HMS Networks (Intesis) présente une passerelle “M‑Bus Meters to BACnet/IP server” : fiche produit, et son manuel “M‑Bus to BACnet/IP Server Gateway” : manuel (PDF).
  • Le même fabricant documente une passerelle “M‑Bus to Modbus TCP Server Gateway” et décrit le rôle serveur côté Modbus et le polling côté M‑Bus : manuel (PDF).

Dans tous les cas : ne spécifiez pas “compatible GTB” ; spécifiez les points, les unités, le sens, la périodicité, et la preuve par recette.

Pour replacer la collecte dans une logique GTB (qui supervise quoi, et jusqu’où), voir aussi GTB, GTC et BMS : quelles différences ?.

Industrialiser : nomenclature, registre, mapping — la partie la plus rentable

Un sous-comptage “réussi” n’est pas celui qui lit un compteur en démonstration. C’est celui qui reste exploitable après des remplacements, des extensions et des changements d’équipe.

Règle simple : séparer identité terrain et identité exploitation

Évitez que “l’adresse M‑Bus” devienne le seul identifiant. En exploitation, vous avez besoin d’identifiants stables, lisibles et durables.

  • Identité exploitation (stable) : un identifiant métier qui décrit périmètre et usage (bâtiment / zone / utilité).
  • Identité protocolaire (technique) : adresse(s) M‑Bus, identifiant radio, etc.
  • Identité GTB : objet(s) BACnet / registre(s) Modbus, tags supervision, etc.

Livrables à prévoir (DOE exploitation) :

  • un registre des compteurs (localisation, usage mesuré, numéro de série, protocole, passerelle associée) ;
  • une table de correspondance (ID exploitation ↔ identifiants terrain ↔ points GTB) ;
  • une convention claire sur unités, sens, index cumulés, fréquence de lecture.

Sur la logique “données exploitables vs données brutes”, notre article Sous-comptage énergétique : savoir précisément où part l’énergie d’un bâtiment complète cette approche côté plan de comptage (arborescence, cohérence, recette).

Structurer le réseau IP comme une infrastructure de service (pas un “détail IT”)

Une collecte AMR devient vite dépendante de services réseau (adressage, VLAN, accès d’administration). Sans méthode, chaque ajout de passerelle peut devenir une exception.

Deux lectures utiles selon contexte :

Sécurité : ce qu’il faut décider au projet (sans surpromettre)

OMS documente des aspects de sécurité au niveau des spécifications et de documents associés, mais la réalité d’un projet hôtel/tertiaire dépend surtout de vos décisions d’architecture : segmentation réseau, accès d’administration, gestion des identifiants, et procédures (qui fait quoi, et comment on retire un accès).

Mesures “bâtiment” généralement pertinentes

  • Segmenter : isoler le périmètre des passerelles de comptage des réseaux invités et bureautiques, et limiter les flux aux besoins (principe allow-list).
  • Réduire l’exposition : pas d’accès d’administration exposé inutilement ; accès distant via méthode maîtrisée (VPN / bastion selon politique IT).
  • Tracer : comptes nominatifs quand les plateformes le permettent, journalisation des accès, sauvegardes de configuration des passerelles.
  • Documenter : une fiche “cybersécurité exploitation” par passerelle (où, qui administre, comment restaurer, dépendances).

Pour une lecture orientée hôtellerie (IT/OT, segmentation, accès), voir Cybersécurité d’un hôtel connecté et Segmentation OT/IT : isoler GTB/GRMS/CCTV du SI bureautique.

Recette (FAT/SAT) : une checklist qui évite les “données inexploitables”

La recette doit tester la mesure, mais aussi la maintenabilité : redémarrage, perte réseau, remplacement, cohérence des identifiants. Ci-dessous une grille de tests simple (à adapter au site et au protocole GTB choisi).

Test Comment le vérifier (terrain) Limites / points d’attention
Inventaire de collecte Comparer la liste “compteurs vus” par passerelle avec le plan de comptage et les plans (zone/étage) En radio, l’inventaire peut varier selon couverture et périodes ; stabiliser l’implantation avant conclusions
Cohérence unités & sens Vérifier unités, signe, index cumulés (monotones), conversions (si appliquées) Une unité fausse produit des tableaux convaincants… et inutilisables
Latence de donnée Mesurer délai entre un événement (consommation/variation) et sa visibilité GTB Pull filaire et push radio n’ont pas la même latence : l’exploitant doit le savoir
Perte IP (mode dégradé) Couper la liaison IP (contrôlée) : observer stockage tampon, reprise, trous Ne pas supposer le buffering : certains équipements ne tamponnent pas ou peu
Redémarrage passerelle Redémarrer : vérifier retour à l’état nominal, réapparition des points, absence de reset mapping À valider avec la GTB : certains points peuvent rester “en défaut” si la reprise n’est pas gérée
Remplacement d’un compteur Simuler un remplacement (ou un “swap” en atelier) : vérifier procédure et impact sur l’identifiant exploitation Le registre et la nomenclature sont la clé : sans eux, le remplacement casse l’historique
Sécurité d’administration Vérifier où sont les interfaces d’admin, qui peut y accéder, et comment on retire un accès Une bonne recette inclut la gouvernance (pas seulement le “technique”)

Points de vigilance à mettre noir sur blanc dans un CCTP / cahier des charges

  • Compatibilités : exiger références explicitement OMS (et, si possible, vérifier l’existence d’un listing/certificat côté OMS-Group) ; sinon prévoir un lot d’intégration/driver et une recette renforcée. Voir : OMS Certified Products.
  • Capacité et performance de la passerelle : charge de polling, nombre d’esclaves, comportement en cas de perte IP, méthodes de sauvegarde/restauration.
  • Radio (si wM‑Bus) : concevoir l’implantation, tester en conditions réelles, et vérifier le cadre local (bandes, agrément, variantes produits) avant achat/import.
  • Données exploitables : registre, nomenclature, mapping, et PV de recette font partie du livrable, sinon la “télérelève” reste un assemblage de compteurs.

Sources et références (pour aller plus loin)

Conclusion : viser un système de données, pas une collection de compteurs

OMS (basé sur M‑Bus) peut être un excellent socle pour structurer un sous-comptage multi-fluides. Mais la réussite d’un projet hôtel/tertiaire se joue surtout sur l’industrialisation : une architecture de collecte cohérente, des passerelles IP correctement intégrées à la GTB, une nomenclature stable, une sécurité exploitable et une recette orientée exploitation.

Si vous le souhaitez, Domocasa peut vous accompagner sur la conception (plan de comptage, architecture IP/GTB, nomenclature) et la préparation d’une recette “chambre/étage type” avant généralisation.

26Mar

Éclairage à blanc variable : que prévoir pour une installation DALI et KNX ?

by Domocasa
Énergie et CVC Guides techniques Smart Home et KNX

Illustration générée par IA — visuel conceptuel.

Un éclairage « biodynamique » (souvent appelé tunable white ou « circadien ») ne se résume pas à faire varier l’intensité. La valeur d’un projet premium (villa, résidence de standing, hôtel) tient à la capacité de faire évoluer le niveau lumineux et la température de couleur de manière fluide, cohérente d’une zone à l’autre, et surtout maintenable dans le temps.

Ce guide explique, de façon très opérationnelle, ce qu’il faut prévoir quand vous associez KNX (logique bâtiment) et DALI (pilotage fin des luminaires) pour obtenir un tunable white réellement exploitable : choix des drivers (DT8), rôle de la passerelle KNX↔DALI, scénarios, réglages, limites, et recette sur site.

Pour replacer l’éclairage dans une approche globale « confort & bien-être » (sans promesse médicale), vous pouvez aussi lire : Domotique & bien-être : améliorer le confort et la qualité de l’environnement intérieur.

Comprendre le tunable white en DALI/KNX (sans ambiguïté)

Ce qu’on pilote vraiment

Dans la pratique, un éclairage biodynamique pilote deux axes :

  • la variation (dimming) : le niveau lumineux,
  • la CCT (température de couleur corrélée) : un blanc plus « chaud » ou plus « froid ».

Dans une architecture KNX + DALI bien structurée :

  • DALI pilote les drivers/luminaires (adressage, groupes, scènes, variation, couleur si compatible),
  • KNX coordonne l’éclairage avec les usages du bâtiment (scènes, horaires, interfaces murales, présence, modes), comme socle de Smart Home. Voir : KNX : le standard ouvert de la domotique et de l’immotique.

DT6 vs DT8 : le raccourci qui évite la plupart des erreurs

Dans DALI, on distingue notamment :

  • DT6 : variation d’un blanc fixe (dimming « classique »),
  • DT8 : contrôle de couleur normalisé, dont le tunable white fait partie.

Conséquence projet : si l’objectif est bien de faire évoluer la CCT (et pas seulement l’intensité), le couple luminaire/driver doit être compatible DT8 (et le contrôle choisi doit effectivement exposer cette fonction).

Pré-requis côté luminaires et drivers (le point le plus critique)

Exiger « DT8 tunable white (Tc) » — pas une mention marketing

Sur un projet, l’erreur la plus coûteuse est de spécifier « tunable white » sans verrouiller le périmètre technique. En DALI, le tunable white correspond à une méthode normalisée de contrôle de la température de couleur (Tc) en DT8.

À cadrer dès le CCTP / descriptif :

  • référence exacte du driver (et pas seulement du luminaire),
  • compatibilité DALI DT8 avec contrôle Tc (CCT),
  • si votre projet impose l’interopérabilité multi-marques : privilégier des références DALI-2 certifiées quand c’est pertinent (à vérifier sur la base officielle).

Attention : un « luminaire » peut consommer plusieurs adresses DALI

Selon l’architecture du driver (par exemple plusieurs sorties pilotées indépendamment), un seul luminaire peut occuper plus d’une adresse logique. En conception, cela a un impact direct sur :

  • la capacité réelle d’une ligne DALI,
  • le nombre de passerelles/lignes à prévoir,
  • la stratégie de zonage (surtout dans des villas très « multi-ambiances » et dans l’hôtellerie).

Uniformité et rendu : ce qu’il faut accepter (et ce qu’il faut tester)

Le fait d’être « DT8 » ne garantit pas à lui seul un rendu parfait (uniformité de blanc entre références, stabilité à bas dimming, perception des transitions, etc.). Ce sont des points qui dépendent des luminaires, des drivers, des lots, et des réglages.

Recommandation de projet : si le rendu est critique (chambre, suite, salon principal, lobby), prévoyez une zone témoin recettée avec les luminaires définitifs avant de généraliser.

Pré-requis côté DALI : capacité, groupes, scènes, alimentation (et limites)

Limites structurantes à intégrer au zoning

DALI permet d’adresser un ensemble de drivers sur un bus, puis de les organiser en groupes et scènes. Les limites usuelles de DALI (adressage, groupes, scènes) doivent être connues dès la phase étude, car elles conditionnent le nombre de lignes DALI et le choix de passerelles.

Point pratique : le tunable white augmente souvent la complexité perçue (plus de paramètres à recetter), même si la structure DALI reste la même.

Scènes : utiles pour les ambiances, pas pour « stocker » une courbe circadienne fine

Les scènes DALI sont très efficaces pour rappeler des ambiances « instantanées » (Accueil, Lecture, Détente, Nuit…). En DT8, une scène peut mémoriser un niveau et un réglage de couleur/CCT (selon l’implémentation du gear).

En revanche, une « vraie » courbe biodynamique (avec de nombreux points) se pilote généralement via :

  • une logique horaire côté KNX (ou supervision) qui envoie des consignes (niveau + CCT) à intervalles choisis,
  • et des modes (Auto / Manuel / Nettoyage / Nuit) gérés bâtiment.

Alimentation et câblage : à traiter comme une infrastructure (pas un détail)

La ligne DALI doit être alimentée et son câblage doit être dimensionné selon la configuration (drivers, capteurs, passerelles, distances). Les limites exactes dépendent de l’alimentation et de la conception retenue ; l’important côté maîtrise d’ouvrage et BET est de :

  • prévoir une topologie documentée (schéma, repérage),
  • éviter les « zones grises » (qui alimente quoi, où est l’alim, qui maintient),
  • réserver une recette DALI ligne par ligne (voir plus bas).

Pour consolider les bases DALI (adressage, groupes, scènes, DALI-2), voir : DALI : comment fonctionne l’éclairage professionnel intelligent ? et DALI-2, D4i et DALI+ : quelles différences pour l’éclairage intelligent ?.

Passerelle KNX↔DALI : ce qu’il faut vérifier avant de la figer

Le rôle réel de la passerelle

Dans un montage KNX + DALI, la passerelle n’est pas un simple « convertisseur ». Elle devient souvent le contrôleur DALI (au sens pilotage), et elle expose des objets KNX vers ETS et les interfaces utilisateur.

En termes de responsabilité :

  • DALI reste le domaine de l’éclairage adressable,
  • KNX devient la couche qui orchestre l’usage et l’ergonomie (boutons, écrans, scénarios, horaires, modes).

Point de validation n°1 : support DT8 tunable white (Tc)

Toutes les passerelles KNX↔DALI ne gèrent pas le tunable white au même niveau (et certaines gèrent très bien DT6 mais pas DT8 Tc). C’est un point à verrouiller à l’appel d’offres : le support DT8 tunable white doit être explicitement documenté sur la référence retenue.

Point de validation n°2 : ce que l’interface KNX sait réellement faire (et remonter)

Au-delà du « pilotage », la question est : que voulez-vous exploiter ?

  • commande niveau + CCT par groupe ?
  • rappel de scènes ?
  • retours d’état, défauts lamp/gear, diagnostic ?
  • stratégie de reprise après coupure (état au retour secteur) ?

Recommandation : formalisez ces attentes dans le cahier des charges, puis recetez-les (sinon elles restent théoriques). Pour structurer l’expression fonctionnelle côté villa, voir : Cahier des charges KNX pour une villa : que faut-il spécifier avant de consulter un intégrateur ?.

Scénarios et réglages : une méthode simple qui marche en premium

Architecture de scénario recommandée : presets + auto (plutôt qu’une courbe imposée partout)

Sur le terrain, un éclairage circadien est apprécié quand il reste lisible. Une approche robuste consiste à combiner :

  • quelques presets (scènes) compréhensibles (ex. Matin / Journée / Soir / Nuit),
  • un mode Auto (courbe) qui pilote les mêmes zones progressivement,
  • un override manuel (l’utilisateur reprend la main), avec une règle claire de « retour à l’auto ».

Paramètres à figer (pour éviter les débats en mise en service)

Avant ETS et avant les tests, clarifiez :

  • plages de CCT souhaitées par espace (et la réalité des produits choisis),
  • temps de transition (fades) acceptables : un changement trop rapide se perçoit comme « technique »,
  • niveau minimum exploitable : en-dessous d’un certain seuil, certains ensembles luminaire/driver deviennent instables ou visuellement inconfortables (à valider sur site),
  • politique d’override : quelle durée, quel événement remet en Auto (changement d’état, nouvelle tranche horaire, appui long, etc.).

Cas hôtel : le circadien doit respecter l’exploitation

En hôtellerie, un « éclairage bien-être » doit aussi :

  • rester cohérent avec les états (Accueil / Occupée / Nuit / Ménage),
  • éviter les comportements surprenants pendant l’occupation,
  • être recetté sur une chambre témoin avant déploiement.

Sur la démarche chambre témoin : Chambre témoin hôtel : comment valider le GRMS, le CVC et l’éclairage avant le déploiement ?.

Recette sur site : checklist de tests (praticable, et réellement discriminante)

La recette est l’étape qui transforme un « système compatible » en une expérience fiable. L’objectif n’est pas de multiplier les tests, mais de valider ce qui compte : rendu, cohérence, robustesse et maintenabilité.

Avant mise sous tension : la checklist documentaire minimale

  • liste des zones + intention (tunable white requis ou non),
  • références luminaires + drivers (preuve DT8 Tc si requis),
  • schéma des lignes DALI et des passerelles,
  • estimation des adresses réellement consommées (y compris cas multi-adresses),
  • liste des scènes attendues (nom, objectif, zones impactées).

Tests DALI (ligne par ligne)

  1. Scan/adressage : tous les drivers attendus répondent,
  2. Groupes : constitution conforme au zoning (et documentée),
  3. Dimming : montée/descente sur plusieurs points représentatifs (plein niveau, niveau bas, balisage),
  4. CCT : validation de plusieurs points (chaud / neutre / froid) sur chaque groupe tunable white,
  5. Transitions : vérifier que les fades sont perçus comme naturels,
  6. Écarts de rendu : observer les zones « critiques » (alignements, plafonds continus, appliques en vis-à-vis).

Tests scènes (et cohérence KNX)

  • rappel de scènes depuis les commandes KNX (boutons, écrans),
  • priorités : que se passe-t-il si une scène s’exécute alors qu’une zone est en override manuel ?
  • cohérence pièce par pièce : une même action doit produire une logique identique (surtout en villa et en hôtel).

Test « biodynamique » (courbe) : une méthode simple et efficace

Pour valider la logique circadienne sans vous perdre dans une infinité de points, commencez par une courbe « courte » (quelques points) :

  • définissez plusieurs moments (matin / milieu de journée / fin d’après-midi / soirée / nuit),
  • pour chacun : couple niveau + CCT,
  • faites tourner la séquence sur une zone témoin (ou une journée réelle),
  • validez : confort visuel, transitions, cohérence entre zones, et compréhension côté utilisateur.

Livrables à remettre (DOE orienté exploitation)

Un éclairage tunable white devient difficile à maintenir si la documentation est absente. À minima, le dossier doit contenir :

  • tableau d’adressage DALI (drivers), groupes, scènes,
  • correspondance entre objets KNX et fonctions (par zone),
  • règles de reprise (modes, override, comportement après coupure),
  • projet et sauvegardes selon le périmètre retenu (KNX, passerelles, supervision).

Sur la logique de remise documentaire : DOE domotique : quels documents et sauvegardes le client doit-il recevoir ? et, côté réception, Réception d’une installation domotique : que faut-il tester avant de prendre possession d’une villa ?.

Limites et points de vigilance (à annoncer clairement dès l’étude)

Limites « système » : ce que DALI/KNX n’a pas vocation à masquer

  • Les limites de capacité (adressage, groupes, scènes) se traitent par zoning et multiplication de lignes si nécessaire, pas en « bricolant » la logique.
  • Les performances à bas dimming, l’absence de scintillement perceptible, ou l’uniformité parfaite entre références ne sont pas des garanties implicites : elles doivent être validées par choix produit et recette.

Ne pas sur-vendre le « circadien »

Un éclairage biodynamique peut participer à une expérience de confort et d’ambiance, notamment dans des projets haut de gamme. En revanche, il ne doit pas être présenté comme un dispositif médical. Dans un positionnement premium, la différenciation vient surtout de la qualité d’usage : cohérence, fluidité, simplicité, modes dégradés maîtrisés.

Aller plus loin : solutions Domocasa et maillage utile

Si vous souhaitez cadrer un éclairage tunable white (DT8) sur une villa ou un projet hôtelier au Maroc (choix drivers, zoning, passerelle KNX↔DALI, scénarios et recette), vous pouvez consulter nos approches Éclairage domotisé et Domotique / Smart Home.

9Fév

Borne de recharge électrique en villa ou en hôtel : comment choisir et l’intégrer ?

by Domocasa
Énergie et CVC Hôtellerie Réseaux et Wi-Fi

Illustration générée par IA — visuel conceptuel.

Pourquoi la “borne VE” est un sujet bâtiment (pas seulement un achat)

Dans une villa haut de gamme comme dans un hôtel, une borne de recharge ne se limite pas à une prise plus puissante. Elle introduit une charge électrique importante, des enjeux d’exploitation (qui a le droit de charger, comment tracer, comment dépanner) et, très souvent, une dépendance au réseau (supervision, accès distant, mises à jour).

La bonne approche consiste à concevoir une architecture de recharge : puissance disponible, priorités, comptage, délestage, interfaces (OCPP/Modbus) et mode dégradé. Cela évite deux dérives fréquentes : surdimensionner sans raison, ou installer “comme à la maison” un système qui devient ingérable en exploitation.

1) Clarifier le cas d’usage : villa, hôtel… ou parking mixte

Villa : confort, cohérence énergétique, simplicité d’usage

En résidentiel, la recharge VE s’intègre souvent à une logique plus large : confort, gestion d’énergie, et parfois production photovoltaïque ou batterie. L’objectif est généralement une recharge “sans y penser”, avec une limitation automatique quand d’autres usages montent en puissance. Si votre projet comporte déjà PV/batterie, l’article KNX, photovoltaïque, batteries et recharge de véhicule électrique : comment optimiser les flux ? permet de recadrer “qui décide quoi” entre onduleur/EMS, batterie et bâtiment.

Hôtel : service client, pilotage multi-usagers, traçabilité

En hôtellerie, une borne est un service : elle doit être administrable, traçable, et compatible avec des usages variés (clients, navettes, personnel, prestataires). Le projet doit aussi décider si la recharge est :

  • Un service inclus (ex. avantage commercial),
  • Un service piloté (accès contrôlé + journalisation),
  • Un service facturable (si l’établissement choisit de refacturer tout ou partie).

Ce choix influence le niveau d’intégration attendu (identification, comptage, reporting), et surtout le comportement en mode dégradé (si la supervision tombe, que fait-on ?).

2) Puissance disponible : partir de la contrainte amont, pas de la borne

Avant de comparer des bornes, il faut cadrer la puissance réellement disponible au point d’alimentation de la zone (parking, sous-sol, extérieur) et comprendre les autres charges qui peuvent monter en même temps.

En pratique, une architecture robuste clarifie :

  • Le périmètre électrique : quelle armoire alimente la zone, quelles protections, quels départs “non délestables”.
  • Les usages concurrents : cuisines, CVC, pompes, laverie, événements (hôtel), ou gros consommateurs ponctuels (villa).
  • La stratégie de contrainte : limitation, délestage, ou répartition dynamique entre bornes.

Pour la méthode de conception “délestage”, voir aussi Délestage intelligent : comment piloter les charges électriques d’un bâtiment ?.

3) Délestage et priorités : éviter le ON/OFF brutal

Un bon délestage de recharge ne se résume pas à “couper la borne”. On cherche plutôt à moduler (réduire, répartir, prioriser) de manière compréhensible et stable. Deux logiques complémentaires coexistent souvent :

  • Limiter la puissance totale appelée par la recharge (priorité au bâtiment).
  • Partager la puissance entre plusieurs points (priorité à l’équité ou à certains usages).

Prioriser les charges : bâtiment d’abord, confort ensuite, recharge en dernier (souvent)

Dans beaucoup de projets, la recharge VE est une charge très flexible. Cela ne veut pas dire “à sacrifier” : cela veut dire qu’elle peut être pilotée pour éviter les dépassements et préserver les usages critiques.

Recommandation de projet : formaliser une matrice de priorités (charges non délestables, délestables, modulables) et une stratégie de rétablissement (comment on remonte progressivement sans faire osciller le site). Cette logique se conçoit avec le BET électricité et, si la GTB/KNX intervient, avec l’intégrateur.

Ne pas confondre délestage et “smart charging”

Le “smart charging” peut désigner des choses différentes selon les acteurs : répartition entre bornes, consignes venant d’un serveur, optimisation PV, ou contraintes électriques instantanées. Le cahier des charges doit donc préciser : qui calcule la limite (borne, contrôleur local, GTB/KNX, supervision OCPP), et quelles informations sont nécessaires (mesure, états, priorités).

4) Comptage, sous-comptage et “facturation éventuelle” : cadrer le niveau de preuve

Que l’on refacture ou non, la recharge devient rapidement un sujet de mesure : énergie consommée, sessions, période, utilisateur, borne. Le bâtiment gagne à séparer :

  • Le pilotage électrique (éviter les dépassements, délester),
  • La mesure énergétique (comprendre et suivre),
  • La valorisation (refacturer, ou suivre par centre de coût).

Pour structurer la mesure sans multiplier les compteurs inutiles, voir Sous-comptage énergétique : savoir précisément où part l’énergie d’un bâtiment.

Facturer n’est pas juste “lire un kWh”

Si l’hôtel souhaite facturer la recharge, il faut cadrer dès l’étude :

  • Quelle donnée fait foi (compteur interne de la borne, compteur externe dédié, mesure d’armoire, données OCPP, etc.).
  • Le niveau de traçabilité attendu (session, utilisateur, véhicule, chambre, facture interne… selon l’exploitation visée).
  • Les limites acceptables : selon les bornes, les mesures existent mais ne sont pas toujours conçues comme un “outil de facturation” au sens strict. Cela se vérifie sur la documentation du fabricant et en recette.

Au Maroc, les exigences exactes (si vous cherchez une refacturation formelle avec un certain niveau de preuve) doivent être confirmées au cas par cas avec vos conseils et fournisseurs. L’article vise ici à structurer le besoin et les tests, sans imposer un cadre réglementaire qui dépend du contexte.

Hôtel : relier la recharge au “parcours client” (sans surcompliquer)

En exploitation, le sujet n’est pas seulement “combien d’énergie a été consommée”, mais comment le service est opéré :

  • Qui autorise une session : réception, application, badge, QR code, ou règles automatiques par type d’utilisateur.
  • Comment on rattache une session : à une chambre, à un client, à un véhicule de navette, à un centre de coût interne, etc.
  • Ce que l’on fait des exceptions : session interrompue, badge perdu, borne hors service, litige, etc.

Recommandation de projet : exiger une procédure exploitation (qui fait quoi, avec quels accès) et une recette “front desk” (tests côté réception) au même titre que les tests techniques. Cette logique se rapproche de la démarche livrables/exploitation décrite dans DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?.

5) Interfaces : OCPP pour l’exploitation, Modbus pour l’intégration bâtiment (souvent)

Le point clé : “compatible” ne suffit pas. Un protocole définit un langage, mais pas forcément le périmètre réellement supporté par la borne, ni le comportement en cas de panne. Il faut donc concevoir par fonctions (pilotage, comptage, droits, supervision) puis vérifier les interfaces disponibles.

OCPP : utile pour superviser, administrer et tracer

OCPP est un standard ouvert pour la communication entre une borne (Charging Station) et un système de supervision/gestion (CSMS). En conception, cela devient le bon candidat pour :

  • Remonter des états et événements (disponibilité, sessions, alertes selon produit).
  • Administrer des droits d’accès selon l’architecture retenue (badges, listes locales, règles).
  • Appliquer des politiques de charge, lorsque la borne et le CSMS supportent réellement les fonctions attendues.

Point de vigilance : OCPP existe en versions. En pratique, votre cahier des charges doit exiger la version et les profils réellement supportés, pas seulement “OCPP”. Pour une référence de définition et de versions côté Open Charge Alliance, voir OCPP protocols (Open Charge Alliance).

OCPP et “smart charging” : optionnel selon profils

Dans OCPP, toutes les fonctions ne font pas partie d’un socle unique : certains périmètres (comme le Smart Charging) dépendent de profils et de mises en œuvre. Conséquence projet : une borne OCPP peut être parfaitement supervisable sans offrir le pilotage fin attendu pour un délestage dynamique. Il faut donc vérifier la prise en charge réelle, côté borne et côté CSMS.

Pour ancrer ce point (sans le surinterpréter), notez que dans le programme de certification OCPP 2.0.1, le profil Core est obligatoire, tandis que Smart Charging et Advanced Security sont listés comme optionnels : cela rappelle qu’un libellé “OCPP” ne suffit pas à décrire le périmètre. Référence : Certification OCPP 2.0.1 (Open Charge Alliance).

Sécurité OCPP : ne pas confondre “certifié OCPP” et “architecture sécurisée”

Une borne connectée est un équipement réseau. Or, le fait d’être “compatible OCPP” ne décrit pas à lui seul la posture de sécurité réelle : selon les produits et le couple “borne + CSMS”, le périmètre de sécurité mis en œuvre (chiffrement, authentification, gouvernance des identités, durcissement réseau, mise à jour) peut varier.

Conséquence projet (pragmatique) : traitez la sécurité comme une exigence de conception et d’exploitation — et pas comme un slogan. En cahier des charges, cela se traduit généralement par :

  • un chiffrement des communications et une authentification adaptés à l’architecture retenue (à confirmer selon les capacités de la borne et du CSMS) ;
  • une gouvernance des comptes (droits, traçabilité, suppression des accès) ;
  • une gestion de cycle de vie (mises à jour, certificats/identités si utilisés, sauvegardes et procédures de renouvellement) ;
  • des tests de mode dégradé : une sécurité trop “rigide” peut bloquer l’exploitation si elle est mal opérée ; une sécurité trop “laxe” peut exposer le réseau.

Pour une lecture plus opérationnelle (process, journalisation, gestion des certificats, recommandations), vous pouvez aussi vous appuyer sur le guide OCA : OCPP Security Operations Guide (Open Charge Alliance).

Modbus : utile pour interfacer une logique locale (mais registres variables)

Modbus est un protocole ouvert, très utilisé en bâtiment pour la mesure et certaines commandes. Pour la recharge VE, Modbus peut devenir pertinent lorsque vous visez une logique locale : délestage immédiat, intégration GTB, échange avec un contrôleur local, ou lecture de compteurs.

Mais Modbus n’est pas “plug and play” : le mapping des registres (ce que la borne expose, ce que l’on peut écrire, à quelle unité, à quelle granularité) est spécifique au fabricant. Autrement dit : dire “Modbus” ne garantit pas qu’on puisse imposer une consigne de courant, ni remonter une mesure utile au même niveau de détail que votre besoin. C’est un point à valider sur la documentation de la borne candidate.

6) KNX / GTB : comment intégrer la recharge sans fragiliser l’exploitation

Dans une villa, KNX sert souvent de socle pour coordonner énergie, CVC, éclairage, et scénarios. Dans un hôtel, on est plus proche d’une logique immotique/GTB, où la cohérence des responsabilités est essentielle. Pour le cadre général, voir KNX : le standard ouvert de la domotique et de l’immotique et Qu’est-ce que l’immotique ?.

KNX et recharge : passerelles et périmètre

Dans beaucoup de projets, KNX ne parle pas “nativement” à une borne. L’intégration passe donc par une couche d’interface (par exemple Modbus, API, ou supervision). Le projet doit décider si KNX :

  • Lit des informations (état, puissance, énergie) pour un tableau de bord ou une logique énergétique.
  • Écrit des consignes (limites) vers une passerelle/contrôleur, lorsque la borne et l’interface l’autorisent réellement.

Pour la stabilité, il est généralement préférable de concevoir une logique où les fonctions essentielles (sécurité électrique, protections, contraintes critiques) ne dépendent pas d’une supervision “confort”. La philosophie est similaire à celle décrite dans nos guides de conception : prévoir une architecture qui reste compréhensible, maintenable et testable.

Tableau, réseaux et documentation : la recharge touche au “socle”

Si KNX (ou une GTB) intervient, cela implique souvent des passerelles IP, des interfaces Modbus, et une intégration réseau. Il faut donc traiter très tôt :

7) Réseau (hôtel et sites multi-usages) : VLAN, accès et isolation

La recharge connectée (bornes, supervision, passerelles) devient un lot IP. En hôtel, cela doit s’inscrire dans l’architecture réseau globale, au même titre que Wi-Fi, vidéosurveillance, VoIP ou GRMS. Deux lectures complémentaires :

Recommandation d’architecture : isoler la recharge comme un réseau technique

Sans sur-spécifier, un principe robuste consiste à isoler :

  • Le réseau “technique” (bornes, passerelles, supervision),
  • Le réseau “administration” (interfaces de gestion),
  • Le réseau “invités” (qui ne doit pas atteindre les systèmes techniques).

Ce n’est pas une obligation “protocole” : c’est un choix de sécurité et de maintenabilité. L’objectif : limiter les flux, simplifier le diagnostic, et éviter qu’un équipement exposé ne devienne une porte d’entrée vers le reste du bâtiment.

Pour une référence “bonnes pratiques” (OT/IT) sur la segmentation logique, NIST décrit notamment l’usage des VLAN comme un moyen de séparation logique lorsque la séparation physique n’est pas possible : NIST SP 800-82r3 — Guide to Operational Technology (OT) Security.

À cadrer au CCTP : dépendances réseau “minimales” de la recharge

Une borne pilotée via OCPP, une passerelle Modbus et un CSMS (cloud ou local) introduisent des dépendances IT qu’il vaut mieux déclarer plutôt que découvrir en fin de chantier. Recommandation de projet : demander au fournisseur (borne et CSMS) une fiche d’interfaces listant au minimum :

  • les flux nécessaires au fonctionnement (supervision, temps, résolution DNS, mises à jour si utilisées) ;
  • les ports/protocoles requis (à valider sur documentation fabricant, car cela varie) ;
  • les adresses/IP ou FQDN attendus (utile pour filtrage sortant) ;
  • le comportement si ces dépendances tombent (supervision indisponible, DNS indisponible, etc.).

Ce cadrage facilite ensuite une politique réseau propre : pas d’exposition entrante inutile, flux sortants limités, et diagnostics plus rapides en cas d’incident.

8) Mode dégradé : le critère qui révèle la qualité de conception

La recharge est souvent perçue comme non critique… jusqu’au jour où elle fait partie de l’expérience client (hôtel) ou du quotidien (villa). Le mode dégradé doit donc être défini, puis testé.

Offline OCPP : ce que la supervision ne doit pas vous faire oublier

Les documents OCPP décrivent un comportement “offline” typique : une session en cours continue, les messages peuvent être mis en mémoire tampon puis transmis au retour de connexion ; en revanche, l’autorisation de nouvelles sessions dépend des mécanismes locaux (listes locales, règles, choix d’exploitation). Cela signifie concrètement : le projet doit décider à l’avance ce qui est accepté lorsque le lien vers la supervision n’est plus disponible.

Pour une référence explicite sur ce comportement (buffering, autorisations offline et variables associées), voir le whitepaper OCA : Improving Uptime Monitoring with OCPP (Open Charge Alliance).

Point d’attention : autoriser des sessions “offline” pour des identifiants inconnus peut introduire un risque d’exploitation (notamment si une logique de facturation ou d’autorisation dépend de la supervision). C’est donc une décision métier autant que technique.

Ce qu’il faut exiger : une recette “pannes” et pas seulement des tests de charge

Un cahier des charges sérieux prévoit des essais :

  • Perte Internet / perte supervision.
  • Redémarrage de borne et reprise.
  • Conflit de charges (scénario de pointe) et stabilité du délestage.
  • Comportement des droits d’accès en mode offline (selon stratégie retenue).

Dans un hôtel, cette logique s’inscrit dans la démarche de readiness et de passation vers l’exploitation, au même titre que les autres systèmes connectés (voir DOE et maintenance d’un hôtel connecté : que faut-il remettre à l’exploitant ?).

9) Checklists de conception (pratiques) : villa vs hôtel

Checklist villa (projet haut de gamme)

  • Puissance disponible : contraintes au tableau et usages concurrents.
  • Objectif : recharge “simple” ou optimisation énergie (PV/batterie) ? (voir KNX, photovoltaïque, batteries et recharge VE)
  • Délestage : quels circuits sont prioritaires ? (voir Délestage intelligent)
  • Interface : OCPP utile ou pas ? Modbus exploitable ou uniquement mesure ?
  • Intégration KNX : lecture seule vs consigne, et DOE (voir DOE domotique).
  • Mode dégradé : que se passe-t-il si Internet tombe ?

Checklist hôtel (parking clients et exploitation)

  • Politique de service : inclus, contrôlé, ou facturable (et comment).
  • Gestion des droits : clients vs personnel vs prestataires.
  • Comptage : sous-comptage et reporting (voir Sous-comptage énergétique).
  • Architecture réseau : VLAN, filtrage, supervision (voir VLAN et architecture IP hôtel).
  • Mode dégradé : sessions en cours, autorisation offline, procédures de contournement.
  • DOE + passation exploitation : accès, sauvegardes, comptes, runbook (voir DOE & maintenance d’un hôtel connecté).

Conclusion : une borne VE réussie est une architecture testée

Choisir une borne, ce n’est pas seulement choisir une puissance ou un design : c’est définir une architecture capable de tenir la charge (électrique), la réalité d’exploitation (droits, traçabilité), et les pannes (mode dégradé). OCPP, Modbus et KNX/GTB sont des briques utiles, mais leurs fonctions réelles varient selon les modèles et les versions : le projet doit donc exiger des preuves (documentation, profils, essais) et une recette adaptée au site.

Pour cadrer votre projet (villa ou hôtel) et éviter les zones grises entre lots (électricité, réseau, GTB, exploitation), vous pouvez vous appuyer sur un cahier des charges structuré — par exemple en vous inspirant de la méthode décrite dans Cahier des charges KNX pour une villa : que faut-il spécifier avant de consulter un intégrateur ? et en l’adaptant à la recharge.

Si vous souhaitez valider une architecture de recharge (puissance, délestage, interfaces, réseau et exploitation) sur plans avant consultation des fournisseurs, Domocasa peut vous aider à cadrer le périmètre et les tests de recette.

25Août

KNX et climatisation VRV/VRF : comment intégrer correctement le CVC ?

by Domocasa
Énergie et CVC Guides techniques Smart Home et KNX

L’intégration KNX et climatisation VRV/VRF ne consiste pas à ajouter un thermostat KNX devant chaque unité intérieure. Elle demande de définir les fonctions réellement disponibles, l’interface avec le constructeur CVC, les priorités de commande et le comportement en cas de panne. Ainsi, la domotique enrichit l’usage sans perturber la logique native de la climatisation.

1. Séparer clairement les responsabilités de KNX et du CVC

Le système VRV/VRF conserve sa propre régulation, ses protections et ses contraintes constructeur. KNX apporte les commandes utilisateur, les scénarios et la coordination avec les autres fonctions du bâtiment.

Par conséquent, l’intégration doit respecter cette frontière. La domotique ne doit pas essayer de reproduire ou de contourner les séquences internes de la climatisation.

2. Définir les fonctions attendues avant de choisir la passerelle

D’abord, le cahier des charges doit lister les points réellement utiles : marche/arrêt, mode, consigne, vitesse, température et retours d’état. Ensuite, l’équipe vérifie lesquels sont effectivement disponibles sur l’interface du constructeur.

Par ailleurs, certaines plateformes remontent des défauts ou d’autres données techniques. Cependant, leur disponibilité dépend du système et de la passerelle.

Ainsi, les écrans et scénarios sont conçus à partir de fonctions confirmées, pas de suppositions.

3. Choisir une architecture d’interface adaptée

Plusieurs approches peuvent exister : passerelle centralisée, interface par unité intérieure ou intégration via une supervision ou un protocole tiers. Le choix dépend de la topologie du système CVC, du nombre de zones et de la granularité recherchée.

D’abord, l’équipe compare les fonctions disponibles. Ensuite, elle analyse le comportement en cas de perte de communication et les outils de diagnostic.

De ce fait, la passerelle découle du projet plutôt que d’une préférence générique.

4. Définir la priorité entre commandes KNX et commandes natives

Un utilisateur peut agir depuis un thermostat KNX, un écran, une application ou une commande constructeur. Cependant, plusieurs interfaces qui écrivent la même consigne sans coordination peuvent créer des incohérences.

Par conséquent, le projet doit définir qui fait référence et comment les modifications se synchronisent. Par exemple, une commande locale peut remonter vers KNX afin que l’écran affiche la valeur réellement appliquée.

Ainsi, l’utilisateur ne voit pas deux températures ou deux modes contradictoires.

5. Coordonner présence, fenêtres et protections solaires avec prudence

Présence et absence

KNX peut utiliser l’occupation pour adapter le CVC. Toutefois, une absence de mouvement ne signifie pas toujours que la pièce est vide. Des temporisations adaptées évitent donc les changements trop rapides.

Fenêtres

Un contact d’ouverture peut déclencher une réduction temporaire. Cependant, le comportement doit tenir compte de la durée d’ouverture et du type d’équipement.

Stores

Les protections solaires peuvent réduire certains apports thermiques. Ainsi, KNX peut coordonner stores et CVC lorsque le projet le justifie. Voir notre article sur les stores, la lumière naturelle et la climatisation.

6. Construire des modes globaux sans brutaliser la régulation

Confort, Nuit ou Absence peuvent appliquer des stratégies différentes. Par exemple, le mode Absence peut élargir la plage de température plutôt que couper systématiquement toutes les unités.

Ensuite, le retour au mode Confort doit rester suffisamment réactif. Ainsi, l’économie d’énergie ne se traduit pas par une attente excessive au retour de l’occupant.

Notre article sur l’automatisation de la climatisation approfondit cette logique énergétique.

7. Préserver le fonctionnement local et diagnostiquer les pannes

Une fonction de confort essentielle doit continuer à fonctionner sans Internet. Par conséquent, la recette doit distinguer la perte Internet, la perte d’une passerelle et une panne du système CVC lui-même.

D’abord, l’équipe documente les adresses, zones et interfaces. Ensuite, elle conserve les sauvegardes et paramètres utiles. Ainsi, un technicien peut déterminer plus rapidement si le défaut provient du bus KNX, de l’interface ou de la climatisation.

8. Recetter chaque zone avec les scénarios réels

La recette ne doit pas se limiter à modifier une consigne sur un écran. D’abord, l’intégrateur teste marche, arrêt, modes et retours d’état. Ensuite, il vérifie fenêtres, présence et scénarios globaux.

De plus, il simule une perte de communication et contrôle la reprise. Enfin, l’équipe confirme que la commande KNX correspond réellement au comportement de l’équipement CVC.

Checklist d’intégration KNX–VRV/VRF

  • D’abord, identifiez précisément la marque, la gamme et la topologie CVC.
  • Ensuite, listez les commandes et retours réellement nécessaires.
  • Par ailleurs, choisissez l’interface après vérification de ses capacités.
  • De plus, définissez la priorité entre commandes KNX et commandes natives.
  • Puis, formalisez présence, fenêtres, stores et modes globaux.
  • Aussi, prévoyez le comportement en cas de perte de communication.
  • Enfin, documentez et recetez toutes les zones.

Conclusion

Pour conclure, une bonne intégration KNX/VRV‑VRF commence par une frontière claire entre automatisation et régulation constructeur. Ainsi, KNX améliore l’expérience, les scénarios et la coordination sans fragiliser le fonctionnement du CVC.

Étudier l’intégration KNX de votre climatisation avec Domocasa

Copyright © 2025 Domocasa. All rights reserved.