KNX Virtual : valider une logique KNX avant chantier (pré‑commissioning, FAT/SAT, limites et cycles de version)

13/04/2026
by Domocasa
Guides techniques Smart Home et KNX

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

Sur un projet KNX résidentiel (villa, appartement haut de gamme, résidence), beaucoup de difficultés de fin de chantier ne viennent pas d’un « mauvais matériel » mais d’une logique ETS incomplète ou ambiguë : adresses de groupe incohérentes, retours d’état absents, scènes qui se contredisent, priorités mal définies entre commandes locales/centralisations, etc.

Le pré‑commissioning consiste à valider la conception ETS (structure, adresses de groupe, DPT, liens, scénarios, modes) avant d’être dépendant du chantier (accès, finitions, délais, aléas électriques, disponibilité des équipes).

KNX Virtual est un outil officiel de la KNX Association permettant de simuler une installation KNX sur PC et de la commissionner via ETS, sans matériel. L’objectif n’est pas de « remplacer » la recette chantier, mais de réduire le risque en stabilisant l’architecture logique plus tôt.

Pour une mise en perspective plus large du standard, voir aussi : KNX : le standard ouvert de la domotique et de l’immotique.

Ce que KNX Virtual permet de valider (et ce qu’il ne remplace pas)

Ce que vous pouvez valider efficacement

  • Structure d’adresses de groupe : nomenclature, cohérence par zones/fonctions, DPT attendus, regroupements (commande/état), etc.
  • Scénarios ETS : scènes, centralisations, interactions inter‑lots (éclairage + stores + CVC), priorités fonctionnelles.
  • Retours d’état : vérifier que vos « états » existent, sont alimentés et utilisables par une supervision/visu ou par d’autres scénarios.
  • Analyse de télégrammes : observer « qui émet quoi », quand, et avec quelles conséquences (indispensable pour produire une recette FAT objective).
  • Tests de modes dégradés logiques (au sens « appareil qui ne répond plus ») en désactivant temporairement un participant virtuel pour observer l’effet sur les scénarios.

Ce que vous ne devez pas sur‑interpréter

  • Pas de test de câblage : KNX Virtual ne valide pas la topologie physique, l’alimentation bus, la qualité d’exécution, les erreurs de raccordement ou les défauts terrain.
  • Pas un banc fabricant : vous validez surtout une logique ETS. Les participants simulés ne sont pas vos références exactes « multi‑marques » du chantier.
  • Le terrain reste souverain : moteurs de stores, charges d’éclairage, interfaces CVC, contraintes d’exploitation, latence perçue, ergonomie… tout cela doit être recetté sur site.

Cadre d’usage et points de vigilance (licence, versions, support)

Licence : attention à la notion d’usage « non‑commercial »

La KNX Association indique que KNX Virtual est fourni en freeware mais uniquement pour un usage non‑commercial (avec des cas d’usage explicitement mentionnés comme l’éducation, et certaines organisations). Ceci ne constitue pas un avis juridique : en cas de doute, référez‑vous au texte officiel et faites valider l’interprétation contractuelle (MOA/MOE, promoteur, intégrateur, service juridique si nécessaire). Source : KNX Association Support — “Licensing & disclaimer”.

Recommandation de projet : si KNX Virtual est utilisé dans une démarche FAT formelle, mentionnez explicitement dans la documentation interne le contexte d’utilisation et les versions, et faites valider ce cadre par les parties prenantes (sans en faire un point bloquant si vous n’avez pas la certitude).

ETS / OS : des prérequis à traiter comme une contrainte de production

La documentation KNX indique notamment :

Lecture opérationnelle (bureau d’études / intégrateur) : alignez poste ETS, droits IT (installation), stratégie VM (si vous en avez une) et calendrier projet. Un changement de version ETS « tardif » peut vous obliger à requalifier votre FAT.

Comprendre l’architecture KNX Virtual (ce qui impacte vos tests)

Topologie : configuration « physique » fixe

KNX Virtual expose une topologie « physique » fixe (la documentation indique qu’on ne peut pas ajouter/déplacer/supprimer zones, lignes, segments ou appareils). Cela impose de raisonner en jumeau logique : vous validez surtout l’organisation des groupes, des DPT et des scénarios. Source : KNX Association Support — “Topology”.

Interface ETS : tunneling, IP localhost et port par défaut

KNX Virtual fournit une interface KNXnet/IP de type tunneling utilisable par ETS, avec une configuration par défaut centrée sur 127.0.0.1 (localhost) et le port 3671. La documentation mentionne aussi une adresse individuelle fixe côté interface (utile à connaître pour éviter les confusions de zone/ligne côté ETS). Source : KNX Association Support — “Interface: connect to ETS”.

Point important : la documentation KNX précise que la NAT n’est pas supportée pour cette connexion KNX Virtual (à prendre en compte si vous envisagez des scénarios « distants » ou des environnements non standard). Source : KNX Association Support — “Interface: connect to ETS”. Pour replacer ce point dans une architecture IP plus globale (villa/tertiaire), voir aussi : KNX IP, routage, interfaces et exposition Internet : erreurs fréquentes.

Méthode recommandée : FAT puis SAT (une seule logique, deux contextes)

Définitions pragmatiques (projet)

  • FAT (Factory Acceptance Test) : recette « atelier / pré‑chantier ». Dans notre contexte KNX, c’est une recette majoritairement logique ETS (nomenclature, groupes, scénarios, preuves de télégrammes), idéalement reproductible.
  • SAT (Site Acceptance Test) : recette sur site (produits réels, câblage réel, moteurs réels, interfaces CVC réelles, conditions d’exploitation).

KNX Virtual est surtout un accélérateur de FAT logique. La SAT reste indispensable (et doit être prévue contractuellement), comme expliqué dans notre guide : Réception d’une installation domotique : que faut‑il tester avant de prendre possession d’une villa ?

FAT KNX avec KNX Virtual : workflow concret (pas à pas)

Étape A — Verrouiller le « contrat logique » avant la simulation

Avant ETS (ou en tout début ETS), figez un socle minimal :

  • liste des fonctions par zone (éclairage, stores/rideaux, CVC, capteurs, centralisations) ;
  • priorités et arbitrages (commande locale vs centrale, scénarios nuit/absence, sécurité vent/pluie si applicable, etc.) ;
  • où un retour d’état est indispensable (interfaces, scénarios multi‑sources, supervision) ;
  • modes « maison » (Arrivée / Absence / Nuit / Invités) et leur périmètre exact.

Sur une villa neuve, cette étape s’inscrit naturellement dans un cahier des charges fonctionnel. Voir : Cahier des charges KNX pour une villa : que faut‑il spécifier ?

Étape B — Créer un projet ETS « jumeau logique » (orienté adresses de groupe)

Objectif : construire un projet ETS qui représente votre logique, même si les participants simulés ne sont pas les références finales du chantier.

Bonnes pratiques (agnostiques marques) :

  • structurer les adresses de groupe par fonction et par zone (et pas par « modules ») ;
  • distinguer systématiquement commande et état lorsque c’est pertinent (surtout si plusieurs sources pilotent la même fonction) ;
  • documenter les DPT et l’intention (commentaires ETS utiles) ;
  • éviter les « GA poubelles » sans propriétaire clair.

Étape C — Utiliser des appareils simulés compatibles

KNX Virtual s’appuie sur un catalogue et sur des types/versions de programme précis. Si un appareil ETS ne correspond pas à ce que le simulateur attend, vous risquez un comportement incohérent (et donc une FAT moins fiable). L’idée : choisir des participants virtuels qui permettent de tester vos cas d’usage (on/off, variation, stores, CVC…) plutôt que « mimer une marque ».

Étape D — Connecter ETS à KNX Virtual et commissionner

  1. installer ETS et KNX Virtual sur la même machine (selon prérequis KNX) ;
  2. démarrer KNX Virtual ;
  3. ouvrir ETS et sélectionner l’interface KNX Virtual ;
  4. commissionner les participants et vérifier leur état.

En pratique, c’est aussi le moment de documenter votre environnement FAT : version ETS, version KNX Virtual, date, poste utilisé.

Étape E — Tester les scénarios : construire une « bibliothèque de cas de test »

Une FAT utile n’est pas « on clique et ça marche ». C’est une liste de tests reproductibles, avec une preuve.

Exemples de familles de tests (villa)

  • Éclairage : marche/arrêt, variation, scènes principales (Accueil/Soirée/Nuit), extinction générale et exceptions.
  • Stores/rideaux : commandes locales, centralisations, cohérence sens de rotation, scénarios Absence/Nuit.
  • CVC : modes (Confort/Éco/Absence), logique fenêtre ouverte si prévue, cohérence consigne/retour d’état.
  • Scènes transverses : Départ (extinction + stores + bascule CVC), Nuit (balisage + zones privées), Arrivée (accueil raisonné).

Étape F — Prouver et déboguer avec une trace de télégrammes

L’intérêt de KNX Virtual est de vous permettre d’objectiver la FAT par des traces : vous pouvez lier un résultat à des télégrammes réellement observés (et pas à une impression). Cette approche évite beaucoup de malentendus en fin de chantier.

Étape G — Rejouer les tests « à blanc » (réinitialisation) pour fiabiliser la FAT

Si vous pouvez remettre un participant virtuel dans un état « ex‑factory » et rejouer la séquence, vous validez la reproductibilité. C’est particulièrement utile lorsque plusieurs intervenants manipulent le projet (BE, intégrateur, sous‑traitants, etc.).

Structurer un PV de FAT : format simple et actionnable

Pour chaque test FAT, utilisez une fiche minimale :

  • ID (ex. FAT‑LGT‑012) et périmètre ;
  • Préconditions (versions ETS/KNX Virtual, état du simulateur) ;
  • Action (ce que vous faites) ;
  • Résultat attendu (y compris retours d’état) ;
  • Preuve (trace de télégrammes, adresses de groupe sollicitées) ;
  • Statut : OK / KO + correction prévue.

Livrable utile : le PV FAT devient une annexe de recette. Il vous sert ensuite de base en SAT (mêmes tests, contexte réel).

SAT sur chantier : ce que vous ajoutez par rapport à la simulation

La SAT doit couvrir, en plus des tests FAT :

  • adressage individuel réel et téléchargement sur les vrais participants ;
  • tests physiques (stores, moteurs, charges réelles, sens de mouvement, réglages de variation) ;
  • interfaces réelles (CVC : ce qui est vraiment pilotable, retours, défauts) ;
  • ergonomie (cohérence des commandes) et comportement « jour‑2 » (redémarrages, coupures courtes, reprise) ;
  • documentation et remise : projet ETS « as‑built », DOE, sauvegardes.

Pour cadrer les livrables, voir : DOE domotique : quels documents et sauvegardes le client doit‑il recevoir ? et Sauvegarder et archiver un projet ETS : les fichiers à remettre.

Option avancée : connecter KNX Virtual à un environnement physique (prudence)

La documentation KNX décrit une possibilité de connexion « routeur » avec une installation KNXnet/IP physique, via une adresse multicast (à configurer côté coupleur virtuel). C’est une option à manier avec prudence : la KNX Association précise que cette fonctionnalité dépend fortement des politiques réseau (firewall, VPN…) et n’est pas un scénario « supporté » comme un usage standard. Source : KNX Association Support — “Router: connect to a physical installation”.

Recommandation : ne basez pas votre démarche FAT sur ce mode. Considérez‑le comme un outil ponctuel, à intégrer seulement si vous maîtrisez parfaitement le réseau et si vous acceptez un périmètre non garanti.

Cycles de version : pourquoi les dates (release/expiration) comptent dans un processus projet

Sur un projet, une FAT n’a de valeur que si elle est reproductible et traçable. Cela implique de noter les versions (ETS, KNX Virtual) et d’éviter des mises à jour « opportunistes » en fin de chantier.

À titre d’exemple, la release KNX Virtual v2.6.1 est documentée par la KNX Association avec :

  • une date de release (22 décembre 2025) ;
  • une date d’expiration indiquée (31 décembre 2027) ;
  • une signature numérique de l’exécutable, et un hash MD5 publié.

Source : KNX Association Support — “KNX Virtual v2.6.1”.

Implication projet : archivez l’install, conservez l’information de version et intégrez ces éléments dans vos livrables internes d’ingénierie (sans les confondre avec le DOE remis au propriétaire).

Checklist express : démarrer vite, sans dégrader la méthode

Checklist FAT (pré‑commissioning) avec KNX Virtual

  • Poste ETS/KNX Virtual cadré (versions, droits, politique IT).
  • Projet ETS « jumeau logique » (adresses de groupe + scénarios) prêt.
  • Bibliothèque de cas de test FAT (éclairage, stores, CVC, scènes, exceptions).
  • PV FAT : preuves par télégrammes et corrections tracées.
  • Gel de version : pas de mise à jour ETS/KNX Virtual sans fenêtre de requalification.

Checklist SAT (chantier)

  • Reprise des tests FAT + ajouts terrain (charges, moteurs, interfaces réelles).
  • Validation des retours d’état (sur produits réels) et des priorités (commande locale/centrale).
  • Tests de modes dégradés (perte Internet, indisponibilité d’une couche IP si présente, redémarrage).
  • Remise documentaire : ETS « as‑built », sauvegardes, DOE, procédure de mise à jour.

Besoin d’un cadrage projet (villa) ?

Si vous souhaitez intégrer une démarche FAT/SAT dès la conception (cahier des charges, règles de scènes, livrables attendus, recette), Domocasa peut vous aider à structurer la méthode avant chantier, en restant agnostique des marques et centré sur l’exploitabilité.

Découvrir notre approche Domotique / Smart Home

Sources (primaires — KNX Association Support) :

Copyright © 2025 Domocasa. All rights reserved.