Loxone · Config
Loxone Config — ingénierie, logique et application opérateur
Comment un bâtiment Loxone est configuré : l’environnement d’ingénierie, la logique de commande, l’application opérateur, l’accès distant, les sauvegardes et la documentation remise.
Réponse rapide
Loxone Config est l’environnement d’ingénierie dans lequel les appareils, entrées, sorties et la logique de commande du bâtiment sont configurés. Il produit les horaires, interverrouillages, alarmes et vues opérateur exécutés sur les contrôleurs locaux, et il s’appuie sur des sauvegardes documentées, des enregistrements de version et un dossier de réception que l’équipe du bâtiment peut maintenir.
L’environnement d’ingénierie
Config est l’endroit où le bâtiment est assemblé en logiciel. Les appareils sont adressés, les entrées et sorties sont mappées, et chaque fonction reçoit un nom qui a du sens pour l’opérateur plutôt que pour l’installateur. L’environnement se connecte au contrôleur local, de sorte que les modifications sont apportées sur l’installation réelle et testées sur place. Un projet bien structuré se lit comme un bâtiment : local technique, étages, gaines verticales, zones de locataires, zones extérieures. Cette structure n’est pas cosmétique ; elle détermine la rapidité avec laquelle une panne peut être trouvée à deux heures du matin. Le même environnement produit la logique qui s’exécute localement et les vues qu’utilisent les opérateurs, ce qui fait de la rigueur de configuration un enjeu d’exploitation, et non un détail informatique. Un projet doit être lisible par quelqu’un qui ne l’a pas écrit. Le test est simple : remettre l’arborescence à un nouvel ingénieur et lui demander de trouver une panne.
- Adressage des appareils et mappage des E/S
- Une nomenclature qui correspond au bâtiment, pas au tableau
- Connexion locale pour tester sur l’équipement réel
Structure et nomenclature du projet
Un projet qui grandit par copier-coller devient impossible à maintenir. Nous définissons une hiérarchie avant de programmer : bâtiment, étage, zone, système, appareil. Les équipements techniques, les capteurs de pièce et les zones de locataires figurent dans cette arborescence, et chaque objet porte un repère correspondant aux plans et à la liste de points. L’arborescence reflète aussi la topologie physique des tableaux, des gaines verticales et des pièces, afin qu’une adresse du logiciel puisse être retrouvée dans le bâtiment. Des modèles sont utilisés pour les types de pièces répétés : une chambre d’hôtel ou un bureau standard est configuré une fois et instancié, seuls l’adresse et le nom de la pièce changeant. La nomenclature suit une seule convention : localisation, service, appareil, et un suffixe lorsque le point en a besoin. Nous évitons que des noms comme « spare » ou « test2 » survivent jusqu’à la réception. La structure est revue avec l’équipe du bâtiment, car c’est elle qui la parcourra sous pression. Renommer après la mise en service coûte cher, car chaque plan, étiquette et rapport renvoie à l’ancien nom.
- Hiérarchie du bâtiment à l’appareil
- Modèles pour les types de pièces répétés
- Une convention de nomenclature commune aux plans, aux points et au logiciel
Logique, séquences et alarmes
L’essentiel du travail d’ingénierie porte sur la logique. Les horaires déterminent quand une zone est censée être occupée ; les interverrouillages déterminent ce qui doit se produire avant le démarrage d’une pompe ou le déplacement d’un registre ; les séquences ordonnancent les équipements de production et les unités terminales dans le bon ordre ; la logique d’alarme décide de ce qui est urgent, de ce qui est informatif et de ce qui doit être supprimé pendant un événement connu. Nous gardons la logique modulaire, afin qu’un étage ou un système puisse être copié, testé et maintenu sans démonter tout le projet. Des blocs fonctionnels partagés sont utilisés pour les séquences répétées, avec des paramètres plutôt qu’une logique dupliquée. Chaque décision non évidente est consignée dans le descriptif de commande, y compris la raison d’une temporisation, d’une zone morte ou d’un interverrouillage. Un index de logique associe chaque bloc à la séquence et à la page du descriptif. Une logique qui ne peut pas être expliquée en un paragraphe est généralement une logique qui s’est développée par accident.
- Logique modulaire par étage, système et équipement
- Blocs partagés avec paramètres, sans duplication de logique
- Priorité des alarmes et suppression documentée
L’application et les vues opérateur
L’application n’est pas une télécommande grand public. C’est l’interface opérateur : des vues par rôle pour les services généraux, les ingénieurs et la direction, avec les alarmes, tendances et commandes dont chaque rôle a besoin. Un technicien peut voir un équipement, ses tendances et ses interverrouillages ; un responsable peut consulter des synthèses d’énergie et de confort sans accès aux commandes de vannes. Les graphiques sont construits autour des décisions que prend l’opérateur, et non autour de la liste des équipements. La page d’alarmes est la vue par défaut, car c’est là que l’attention est nécessaire en premier. Le même modèle sert un écran mural dans le hall, un poste de travail au bureau des services généraux et un appareil mobile sur le terrain. Toute vue qui n’existe que sur l’ordinateur portable de l’ingénieur ne fait pas partie des livrables de réception. La vue par défaut doit répondre à la question « de quoi faut-il s’occuper maintenant » avant « qu’est-ce qui existe ».
- Vues par rôle et autorisations de commande
- Vue par défaut centrée sur les alarmes
- Même modèle sur poste de travail, écran mural et mobile
Accès distant et sécurité
L’accès distant est une commodité assortie d’une limite de sécurité. Les connexions doivent être explicites, authentifiées et journalisées, avec une authentification à deux facteurs pour toute personne extérieure au réseau du bâtiment. Le réseau de commande est séparé des réseaux des locataires et des invités ; les flux entrants sont relayés par un médiateur plutôt qu’exposés. L’exploitation locale d’abord signifie que le bâtiment n’a pas besoin du chemin distant pour fonctionner. L’accès peut être révoqué lorsqu’un prestataire quitte le site, et la piste d’audit doit montrer qui s’est connecté, quand et ce qui a changé. Les comptes sont individuels, non partagés, et les comptes de service sont documentés avec un responsable. Ce sont des décisions de configuration autant que des décisions réseau, et elles sont revues avec l’informatique avant la mise en service du système, pas après le premier incident. Une connexion distante toujours ouverte est une porte laissée déverrouillée ; elle doit être ouverte pour une tâche puis refermée.
- Authentification à deux facteurs pour les utilisateurs distants
- Réseau de commande segmenté et accès médiatisé
- Comptes individuels, révocation et piste d’audit
Sauvegardes, gestion des versions et contrôle des changements
Un bâtiment configuré est à la fois une propriété intellectuelle et une infrastructure d’exploitation. Le fichier projet, la sauvegarde du contrôleur, la liste de points, le schéma réseau et le descriptif de commande font partie du dossier de réception. Les sauvegardes s’exécutent selon un calendrier défini et sont testées par restauration sur un contrôleur de réserve, et non simplement en vérifiant qu’un fichier existe. Les enregistrements de version indiquent la modification, la date et la personne responsable, afin qu’une régression puisse être rattachée à une version. Les modifications après réception suivent un chemin simple de contrôle des changements : demande, impact, approbation, mise en œuvre, enregistrement. Cette discipline est ce qui maintient un bâtiment en fonctionnement après le départ de l’ingénieur d’origine, et c’est la différence entre un système maintenu et une collection de modifications non documentées. Une sauvegarde qui n’a jamais été restaurée est un espoir, pas une sauvegarde. Les noms de version doivent avoir du sens pour l’équipe du bâtiment, et pas seulement pour le développeur.
- Fichier projet, sauvegarde du contrôleur et liste de points
- Test de restauration sur un contrôleur de réserve
- Enregistrement de version et traçabilité des demandes de changement
Appui à la mise en service, documentation et formation des opérateurs
La configuration est prouvée pendant la mise en service, et non par le fait qu’elle compile. Nous accompagnons les essais point par point, les essais de séquences et la simulation de défauts, et nous consignons les valeurs de paramètres réellement réglées : limites de consigne, temporisations, zones mortes et seuils d’alarme. La documentation de fin de travaux comprend le fichier projet, l’index de logique, la liste de points, la liste des alarmes, l’index des graphiques et le schéma réseau. La formation est organisée par rôle : les opérateurs apprennent les alarmes, les horaires et les dérogations autorisées ; les techniciens apprennent les tendances, les sauvegardes et le diagnostic de premier niveau ; les responsables apprennent les rapports et les vues d’énergie. La compétence est enregistrée, non supposée. L’objectif est une équipe du bâtiment capable d’effectuer des modifications courantes en sécurité et de savoir quand appeler de l’aide. La formation se termine par un exercice pratique : modifier un horaire, acquitter une alarme, restaurer une sauvegarde sur un contrôleur de réserve. La réception est complète lorsque l’équipe du bâtiment peut répéter ces tâches sans l’ingénieur présent.
- Valeurs de paramètres consignées telles que mises en service
- Jeu de fichiers de fin de travaux et index de logique
- Formation par rôle avec compétence enregistrée
Domaines de travail de configuration et livrables
15 rows| Domaine de travail | Ce qui est configuré | Livrable | Responsable après réception |
|---|---|---|---|
| Hiérarchie du projet | Arborescence bâtiment, étage, zone, système et appareil | Schéma de structure du projet | Équipe du bâtiment |
| Nomenclature et repérage | Suffixes de localisation, service, appareil et point | Convention de nomenclature et registre des repères | Équipe du bâtiment |
| Modèles | Pièces, étages et groupes d’équipements standard | Bibliothèque de modèles et guide d’instanciation | Équipe du bâtiment |
| Adressage des appareils | Contrôleurs, extensions, appareils Tree et Air | Liste des adresses et des appareils | Équipe du bâtiment |
| Mappage des E/S | Entrées, sorties, capteurs et actionneurs | Liste de points avec noms et plages | Équipe du bâtiment |
| Horaires | Périodes d’occupation, de réduit, de nettoyage et saisonnières | Matrice des horaires par zone | Équipe du bâtiment |
| Logique de contrôle | Interverrouillages, séquences, boucles PID et basculement | Descriptif de commande et index de logique | Équipe du bâtiment |
| Alarmes | Priorités, acheminement, suppression et escalade | Liste des alarmes et matrice d’escalade | Équipe du bâtiment |
| Tendances et journaux | Points, intervalles, conservation et export | Programme de tendances et procédure d’export | Équipe du bâtiment |
| Vues opérateur | Tableaux de bord, plans d’étage, tendances et commandes | Jeu de graphiques et matrice des rôles | Équipe du bâtiment |
| Rôles utilisateur | Comptes, autorisations et limites de commande | Registre des rôles et matrice des autorisations | Équipe du bâtiment |
| Accès à distance | Comptes, double facteur, politique de connexion | Registre des accès et politique | Équipe du bâtiment avec l’informatique |
| Sauvegarde et restauration | Calendrier, conservation et test de restauration | Enregistrement des sauvegardes et procédure de restauration | Équipe du bâtiment |
| Gestion des versions | Noms de version, dates et historique des changements | Registre des versions et journal des changements | Équipe du bâtiment |
| Documentation et formation | Plans de fin de travaux, descriptifs et supports de formation | Dossier de réception et enregistrement de la formation | Équipe du bâtiment |
Images du projet
3 images
Questions fréquentes
01Loxone Config est-il un langage de programmation ?
C’est un environnement d’ingénierie graphique construit à partir de blocs fonctionnels et d’objets de configuration. Une logique complexe peut être structurée, nommée et documentée sans écrire de code généraliste.
02Pouvons-nous modifier le système nous-mêmes ?
L’équipe du bâtiment peut être formée pour modifier les horaires, les consignes et les comptes utilisateur dans les limites d’autorisations définies. Les modifications structurelles de logique doivent suivre le contrôle des changements et, le cas échéant, être accompagnées par l’intégrateur.
03L’application nécessite-t-elle un compte cloud ?
L’exploitation locale ne dépend pas d’un compte cloud. L’accès distant peut être fourni via une connexion médiatisée avec authentification à deux facteurs.
04Comment les sauvegardes sont-elles gérées ?
Le fichier projet et la configuration du contrôleur sont sauvegardés selon un calendrier défini, et une restauration est testée sur un contrôleur de réserve avant la réception.
05Différents utilisateurs peuvent-ils voir des choses différentes ?
Oui. Les vues par rôle et les autorisations de commande sont configurées pour les opérateurs, les ingénieurs, la direction et, le cas échéant, les locataires ou les résidents.
06Quelle documentation est remise ?
La liste de points, le descriptif de commande, la liste des alarmes, le schéma réseau, l’index des graphiques, l’enregistrement des sauvegardes et les notes de formation.
07Comment les modifications sont-elles suivies après la réception ?
Au moyen d’un chemin de contrôle des changements : demande, évaluation de l’impact, approbation, mise en œuvre et enregistrement dans la piste d’audit.
Étape suivante
Apportez-nous le bâtiment.
Indiquez le type de bâtiment, les systèmes concernés et le résultat dont vous avez besoin. Nous tracerons le chemin le plus court vers un système opérationnel.