01
Commencez par le verbe : lire, demander, constater.
« Compatible domotique » ne dit pas si une interface peut lire une température, modifier une consigne ou recevoir un défaut. Écrivez chaque fonction séparément, avec son propriétaire. Le transport réseau et le sens de la donnée sont deux niveaux différents : partager une liaison IP ne démontre pas que deux appareils comprennent le même échange.
Les documents officiels donnent des repères différents : KNX décrit des fonctions et leur contexte de projet ; BACnet expose des objets et propriétés, avec un document PICS indiquant les capacités du produit ; Modbus demande de rapprocher les données de la table du fabricant. Utilisez ces documents pour préparer les questions ci-dessous, pas pour déclarer tous les produits d’une famille interchangeables.
02
Demander une preuve adaptée à chaque interface.
Tableau défilant horizontalement : comparez les trois colonnes.
| Interface proposée | Document à réunir | Question décisive |
|---|---|---|
| KNX | Application du produit, version et description du projet concerné. | La fonction demandée est-elle prévue et correctement associée dans ce projet ? |
| BACnet | PICS du modèle et liste des objets/propriétés utiles. | Quelles propriétés sont lisibles ou modifiables et quels services sont pris en charge ? |
| Modbus | Table constructeur, version, type de données et conventions de représentation. | À quelle grandeur correspond la donnée, avec quelle unité, échelle et permission ? |
| Passerelle entre systèmes | Liste des points traduits, sens des échanges et limites documentées. | La traduction conserve-t-elle le sens, les états et les informations nécessaires au besoin ? |
03
Une ligne de point doit pouvoir être relue sans deviner.
Identité et sens
Notez repère, pièce, équipement source, version et description métier. Séparez température mesurée, consigne demandée, consigne relue et état de fonctionnement. Une valeur semblable ou un nom abrégé n’en fait pas la même information. Conservez la référence documentaire qui donne ce sens.
Représentation et droits
Documentez unité, type, échelle, limites admises et lecture seule ou écriture autorisée. Lorsque la notice l’exige, précisez l’ordre des éléments qui composent une valeur. Identifiez qui peut envoyer une demande, les validations requises et l’arbitrage avec la commande locale. Ne complétez pas une case inconnue par un réglage supposé standard.
Fraîcheur et perte de communication
Prévoyez comment dater la dernière observation et signaler l’information indisponible. Distinguez dernière valeur connue, valeur actuelle et défaut d’échange. Convenez du comportement de chaque fonction lorsque le lien manque, puis à son retour. Ne traduisez pas automatiquement une absence de réponse en zéro ou en équipement arrêté.
Responsabilités et accès
Nommez les responsables de chaque système, de la passerelle, du réseau et de la sauvegarde. Précisez les accès autorisés et le canal sécurisé de remise. Un schéma pour une demande de devis peut employer des repères anonymes : aucune adresse réelle, clé ou session administrateur n’a besoin d’y figurer.
04
215 ne signifie pas forcément 215 degrés.
EXEMPLE ILLUSTRATIF
Cas fictif : une table inventée décrit T01 comme une température en lecture seule, dont la valeur brute 215 est multipliée par 0,1. Dernière observation : 10:00. À 10:10, la communication est indisponible. Ce n’est ni une table de constructeur ni une adresse utilisable.
Lire avec la bonne unité
Dans cet exemple, 215 × 0,1 = 21,5 °C. Afficher 215 °C serait une erreur de conversion, même si la communication a déjà fonctionné. Le contrôle compare valeur brute, règle documentée et affichage. Cette règle appartient uniquement au cas fictif : elle n’est pas une échelle universelle des capteurs.
Ne pas transformer une mesure en commande
Le projet demande aussi de modifier une consigne, mais T01 est en lecture seule. Ce point ne satisfait pas cette fonction. Il faut identifier une interface de consigne explicitement disponible et autorisée ; ajouter un bouton à l’écran ne crée pas un droit d’écriture. Une consigne relue ne serait pas non plus la preuve que la pièce a atteint cette température.
Garder la dernière valeur sans la faire passer pour actuelle
À 10:10, 21,5 °C peut rester une dernière observation datée de 10:00, accompagnée de l’indisponibilité du lien. La température actuelle n’est pas vérifiée. Ne l’affichez ni comme une mesure fraîche, ni comme 0 °C par défaut. Le critère de fraîcheur doit être convenu selon la fonction ; dix minutes n’est pas ici un seuil recommandé.
Calcul et observations illustratifs, sans lecture ou écriture sur un équipement. La réussite d’un point ne valide pas tous les échanges d’une passerelle, ni une installation complète.
05
Recevoir une fonction, pas seulement une connexion.
Comparer demande et résultat
Le protocole d’essai autorisé précise point, action permise, résultat attendu, observation indépendante et version. Gardez séparés demande envoyée, acceptation de l’interface, retour d’état et effet physique lorsqu’il doit être contrôlé. Une connexion établie ne remplace aucun de ces résultats.
Prévoir refus et reprise
Décrivez les demandes non autorisées, les valeurs hors limites, la priorité manuelle et l’indisponibilité d’un système. Faites valider un essai sûr et une récupération par le responsable, sans imposer de coupure réelle à un service occupé. Remettez liste des points, versions, réserves et sauvegarde exploitable aux personnes désignées.
06
Une liste de fonctions rend le devis comparable.
Pour Inovexia, réunissez références et versions conservées, fonctions demandées, nombre de points par type, documents d’interface et contraintes. Distinguez fourniture d’équipements, éléments à confirmer par le fabricant et travail de l’intégrateur. Une passerelle proposée doit avoir un périmètre précis ; n’acceptez pas « tout sera connecté » à la place d’une liste vérifiable. Les données absentes restent des questions à résoudre avant validation.
07
Les questions à poser avant d’intégrer.
Quel protocole est le meilleur ?
Le choix se fait à partir des fonctions, de l’existant, des documents, des responsabilités et de l’exploitation attendue. Comparez des architectures définies pour votre projet, pas des logos. Un même bâtiment peut contenir plusieurs systèmes sans devoir tous les remplacer.
Une passerelle traduit-elle toutes les fonctions ?
Seulement celles que sa documentation et sa configuration permettent de démontrer. Demandez la liste des points et les limites, notamment pour défauts, états, droits et reprise. Une traduction réussie sur un point ne répond pas pour les autres.
Peut-on piloter une valeur que l’on sait lire ?
Pas nécessairement. Lecture et écriture sont des fonctions distinctes à vérifier. Demandez le point prévu pour la commande, les permissions, limites et priorités. Ne tentez pas une écriture sur une donnée inconnue pour découvrir son rôle.
Un voyant vert prouve-t-il que l’action a eu lieu ?
Il faut connaître sa signification : lien établi, demande acceptée ou retour d’état. Prévoyez une indication honnête pour attente, refus ou absence de donnée. Le contrôle de l’effet physique reste distinct lorsqu’il fait partie de la réception.
Que remettre pour qu’un autre intégrateur puisse reprendre ?
Une liste de points lisible, schémas, références, versions, configuration conservée, responsabilités et procédure de récupération prévue. Les droits d’usage et d’accès doivent être clarifiés avec les parties concernées. Ne promettez pas une reprise indépendante si les éléments nécessaires manquent.
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 IoT: the Summum of InteroperabilityKNX Association · Sources consultées le
- BACnet Glossary — Objects, properties and PICSBACnet International · Sources consultées le
- Introduction to Modbus — Data mapping and representationModbus Organization · Sources consultées le