01
Définir ce que l’on veut piloter, puis ce que l’on veut savoir.
« Tout centraliser » ne constitue pas encore un brief. Écrivez une fonction avec une zone, un déclencheur, une action et une exception : éteindre l’accueil au départ, mais conserver le bureau encore occupé. Précisez ensuite qui peut agir et comment une commande locale reprend la main. Le même travail sert dans une villa, un bureau ou plusieurs zones d’un bâtiment.
La GTB, ou gestion technique du bâtiment, peut ajouter des besoins d’exploitation : vues par zone, historiques, horaires, droits ou traitement d’anomalies. Faites énumérer les fonctions réellement incluses au lieu de déduire toutes ces possibilités d’un écran tactile. Une consigne envoyée, un état rapporté et une mesure physique répondent à des questions différentes ; le dossier doit les distinguer.
02
De la demande à l’action, puis à son retour.
KNX est un exemple documenté de cette chaîne, pas le protocole supposé de tout le catalogue. Les références choisies doivent partager les fonctions nécessaires, avec leurs interfaces et leur configuration vérifiées.
01 · Entrée
Bouton, horaire ou capteur : nommer l’événement et son origine. Un capteur de présence, une commande manuelle et un programme horaire ne donnent pas la même information.
02 · Logique et priorité
Décrire les conditions, exceptions et durée d’une dérogation. En cas de demandes concurrentes, préciser laquelle prévaut et comment l’utilisateur connaît la règle active.
03 · Échange et interface
Dans KNX, le support et l’association des fonctions sont configurés pour le projet. Pour une passerelle, vérifier sens des échanges, points exposés et versions ; partager un réseau IP ne suffit pas.
04 · Action sur la charge
Commuter, faire varier, déplacer un store ou transmettre une consigne climatique demandent des interfaces adaptées. Faire vérifier charge, commande existante et limites avant de choisir l’actionneur.
05 · Retour et supervision
Documenter la provenance de chaque état affiché. Si une position est estimée ou si la donnée n’est plus disponible, l’interface doit le dire ; un acquittement de commande ne devient pas une mesure.
03
Cinq choix qui déterminent l’exploitation.
Tableau défilant horizontalement : comparez les trois colonnes.
| Décision | Question concrète | Élément à faire confirmer |
|---|---|---|
| Rénovation ou neuf | Quels câbles, tableaux, commandes et équipements sont conservés ? | Architecture réalisable et travaux associés ; ni bus ni radio choisis sans relevé. |
| Fonctions et protocoles | Quelles actions et informations traversent chaque interface ? | Table des points, types, unités, lecture/écriture et restrictions documentées. |
| Commande locale ou distante | Que reste-t-il utilisable sans Internet, serveur ou compte externe ? | Dépendances par fonction et essai de fonctionnement dégradé convenu. |
| Conflits de commandes | Que devient une dérogation manuelle à la prochaine scène ? | Priorité, portée, durée et condition de retour à l’automatique explicites. |
| Remise et évolution | Qui conserve configuration, accès et moyens de modification ? | Sauvegardes remises, rôles, licences et réserves prévues ; aucune extension présumée illimitée. |
04
Exemple : le départ général, avec un bureau encore occupé.
EXEMPLE ILLUSTRATIF
Cas fictif de trois zones : accueil L-01, réunion L-02 et bureau L-03. Les identifiants servent au brief, pas à une installation réelle. La dérogation du bureau est ici maintenue jusqu’à sa levée explicite par l’utilisateur.
Écrire les actions et l’exception
Le bouton « Je pars » demande l’arrêt de L-01 et L-02. L-03 reste dans son état précédent parce qu’une dérogation est active. La scène ne doit ni effacer cette dérogation ni annoncer que tout le bâtiment est éteint.
Séparer demande et état disponible
Le compte rendu distingue les demandes, les retours reçus et les points inconnus. Un store S-01 sans retour de position ne peut pas devenir « fermé confirmé » simplement parce que l’ordre est parti. Les informations anciennes ou estimées sont identifiées comme telles.
Tester la reprise de contrôle
L’utilisateur lève la dérogation de L-03, puis relance volontairement le scénario pour vérifier la règle convenue. Dans un essai encadré, vérifier aussi les fonctions annoncées disponibles lors de la perte d’un service externe. Ne pas déduire ce résultat d’un simple logo de protocole.
Ce scénario ne réarme aucun système incendie, ne désarme aucune alarme et ne valide pas la sécurité d’un moteur. Ces systèmes conservent leurs logiques et responsabilités dédiées ; leurs éventuelles interfaces exigent un périmètre distinct.
05
Six questions pour une liste de fonctions exploitable.
Quelles zones et quelles charges ?
Plan, identifiants, luminaires, moteurs, commandes de climat et équipements conservés. Joindre références et caractéristiques connues ; signaler les inconnues.
Quels déclencheurs et exceptions ?
Pour chaque scénario : événement, zones, résultat, priorité manuelle et retour à l’automatique. Décrire les usages réels, pas seulement le nom de la scène.
Quelles interfaces sont documentées ?
Protocole, versions, points échangés, unités, droits de lecture et d’écriture. Faire confirmer les limites des passerelles et les licences nécessaires.
Quels retours peut-on réellement afficher ?
Pour chaque point, noter capteur, état rapporté ou estimation, ainsi que le comportement si la donnée manque. Prévoir une formulation claire des états incertains.
Quelles dépendances et quels accès ?
Alimentation, réseau, serveur, comptes et service distant éventuel. Distinguer utilisateur quotidien, administrateur et intervenant ; ne pas partager de secrets dans un brief public.
Quels essais et quels fichiers remis ?
Liste de scénarios, critères, exceptions, versions et réserves. Demander configuration exportable lorsque prévue, sauvegardes, droits d’accès et fiche d’usage ; préciser le périmètre de suivi.
06
Une intégration se documente fonction par fonction.
Les sources KNX expliquent l’association de fonctions et les interfaces d’un écosystème ; elles ne certifient pas une liste de références choisies sans vérification. Faites distinguer fourniture Inovexia, programmation, pose, mise en service et suivi dans l’offre. Historisation, alertes, export, accès distant et économie d’énergie ne sont pas acquis par la seule présence d’une supervision : préciser les points, conditions et preuves demandés avant validation.
07
Ce qu’il faut demander au-delà de l’application.
Un écran central signifie-t-il que tout est compatible ?
Non. Faites vérifier les références et les fonctions échangées, ainsi que les limites des interfaces. Voir deux appareils dans la même application ne prouve pas tous les scénarios souhaités.
La commande locale fonctionne-t-elle toujours sans Internet ?
Cela dépend de l’architecture et de la fonction. Demandez une liste des dépendances et un essai convenu. Ne confondez pas perte de l’accès distant et perte de toutes les commandes locales.
Que doit afficher un store sans capteur de position ?
Ce qui est réellement connu : demande envoyée, estimation documentée ou position inconnue. Une estimation peut être utile si elle est annoncée comme telle ; elle ne doit pas être présentée comme une mesure confirmée.
Un scénario peut-il écraser une commande manuelle ?
La règle doit être définie, pas supposée. Indiquez quelles dérogations persistent, leur durée et leur levée. Testez le conflit explicitement pour éviter que l’utilisateur perde une exception sans explication.
Peut-on annoncer des économies dès la sélection du matériel ?
Pas à partir de cette page ou d’un scénario seul. Un résultat chiffré exige une méthode, une situation de référence et des données comparables. Le projet peut viser une meilleure maîtrise sans promettre un pourcentage non mesuré.
Sources techniques
Références de lecture externes. Ces documents expliquent des principes ; ils ne certifient pas les produits du catalogue ni leur association.
- KNX TechnologyKNX Association · Sources consultées le
- KNX IoT: the Summum of InteroperabilityKNX Association · Sources consultées le