Système Loxone
Guide du système Loxone : architecture et applications
Comment un système d’automatisation du bâtiment Loxone est structuré : Miniserver, extensions, Tree, Air et 1-Wire, programmation Config, intégration avec KNX, BACnet et Modbus, et livraison de projet.
Réponse rapide
Loxone est une plateforme d’automatisation du bâtiment locale d’abord, construite autour du Miniserver, un automate qui exécute la logique, les horaires et les scènes sans connexion cloud obligatoire. Les extensions ajoutent des entrées et des sorties, Tree, Air et 1-Wire connectent les appareils de terrain, et Config définit le comportement exposé par l’application et les interfaces.
Une architecture locale d’abord
Loxone est conçu autour d’un principe simple : le bâtiment doit continuer de fonctionner lorsque l’internet ne le fait pas. Le Miniserver stocke le programme de contrôle, exécute les horaires et les scènes, et communique avec les appareils de terrain sur des bus locaux. L’accès distant et l’application mobile sont des commodités ajoutées par-dessus, non une dépendance pour l’exploitation quotidienne. Cette conception convient aux bâtiments dont la connectivité est peu fiable, qui ont des exigences strictes de résidence des données ou qui doivent continuer à fonctionner pendant un défaut réseau. Elle change aussi le modèle de support : l’intégrateur peut diagnostiquer la logique localement, et le maître d’ouvrage n’est pas exposé à la fin d’un abonnement. Local d’abord ne signifie pas isolé. Des passerelles et des interfaces connectent les équipements KNX, Modbus, DALI et BACnet, et un superviseur peut lire le système sans en prendre le contrôle. Pour un bâtiment commercial, le même principe s’applique au réseau des automates : autonomie locale d’abord, coordination centrale ensuite. La question pratique est de savoir quelles fonctions doivent survivre à une coupure WAN, et si la conception a testé ce scénario. Une affirmation « local d’abord » qui n’a jamais été testée hors ligne n’est qu’une formule marketing. Le test doit être répété après une mise à jour de micrologiciel, car un changement de comportement de l’automate peut réintroduire discrètement une dépendance que la conception avait supprimée. L’autonomie locale a aussi un coût : chaque automate a besoin de sa propre sauvegarde et de son propre plan de remplacement.
- Logique et horaires stockés sur site
- Application et accès distant comme couches optionnelles
- Bus locaux pour les appareils de terrain
- Passerelles pour les systèmes tiers
Le Miniserver et les extensions
Le Miniserver est l’automate central : il contient le programme, les horaires, les permissions utilisateur et les interfaces. Les entrées et sorties embarquées couvrent directement une petite installation ; les extensions ajoutent de la capacité sur un bus local lorsque le projet grandit. La planification de capacité doit avoir lieu avant la construction du tableau, car le type d’entrée, le type de sortie et la capacité de réserve influent sur l’enveloppe, l’alimentation et le câblage. La conception doit aussi consigner quelles fonctions s’exécutent sur quel automate, afin qu’une défaillance ait un effet limité. Les sauvegardes, les documents de licence et une procédure de restauration testée font partie du système, non d’une réflexion après coup. Le choix du modèle est une décision de projet fondée sur le nombre de points, les besoins d’interface et l’extension future, non un choix par défaut reconduit du projet précédent. Le modèle retenu doit être documenté avec le nombre de points et la liste d’interfaces qui l’ont justifié. Une marge de capacité de réserve coûte moins cher en conception qu’un second tableau après la réception ; elle doit être exprimée en pourcentage de la capacité utilisée plutôt que laissée comme intention vague. La procédure de remplacement doit être rédigée pour quelqu’un qui n’a jamais vu le tableau, et testée une fois pendant que l’ingénieur d’origine est encore disponible. Un second automate pour la résilience est un choix de conception, non un défaut ; il exige un comportement de basculement défini.
- Programme, horaires et permissions
- E/S embarquées et bus d’extension
- Planification de capacité et de réserve
- Sauvegardes et restauration testée
Tree, Air et 1-Wire
Loxone utilise trois technologies de périphérie pour des usages différents. Tree est un bus filaire pour interrupteurs, capteurs, variateurs et actionneurs ; il transporte l’alimentation et les données, et convient aux projets neufs où les tracés de câbles sont planifiés. Air est un protocole sans fil pour les appareils dont le câblage est impraticable, notamment en rénovation et pour certains emplacements de capteurs ; il exige une étude de signal et une stratégie d’alimentation pour les appareils à pile. 1-Wire est un bus simple utilisé principalement pour la mesure de température dans les planchers, les tuyaux et les pièces, avec un adressage qui rend chaque capteur identifiable. Les trois peuvent coexister dans une même installation. Les règles de conception couvrent la topologie, la longueur de câble, la terminaison, le budget de puissance et la séparation vis-à-vis des perturbations du secteur. Le choix ne porte pas sur la technologie la plus récente ; il porte sur le bâtiment, les tracés et le modèle de maintenance. Le sans-fil doit être traité comme une décision de conception assortie d’un plan de maintenance, non comme un raccourci contournant la planification. Documenter les adresses des appareils et la topologie des bus épargne des heures lors de la mise en service et du dépannage ultérieur, et c’est la première chose perdue lorsqu’un projet passe d’un installateur à l’autre. Un appareil sans fil qui nécessite une échelle pour être atteint représente un coût de maintenance même lorsqu’il ne pose pas de problème de contrôle. Étiqueter chaque segment de bus aux deux extrémités est une petite habitude qui épargne un long après-midi.
- Tree : bus filaire avec alimentation et données
- Air : sans fil pour rénovation et capteurs
- 1-Wire : mesure de température
- Topologie, alimentation et adressage documentés
Config : programmer le bâtiment
Config est l’environnement d’ingénierie où le comportement du bâtiment est défini. Des blocs fonctionnels gèrent les entrées, les sorties, la logique, les horaires, les scènes, les alarmes et les droits utilisateur. Un projet bien structuré utilise des conventions de nommage, des blocs réutilisables et des commentaires qu’un autre ingénieur peut suivre. La simulation et les tests en ligne aident à vérifier la logique avant la mise en service, mais ne remplacent pas les contrôles point par point sur site. La gestion des versions compte : un horaire modifié ou un nouvel interverrouillage doit être consigné avec une date et une raison. Le contrôle d’accès au fichier projet compte aussi, car une modification non documentée peut compromettre une séquence testée. Le résultat de Config n’est pas seulement un programme fonctionnel ; c’est une description maintenable du comportement attendu du bâtiment, dont le maître d’ouvrage a besoin à la réception. Une convention de nommage convenue au départ coûte moins cher que de renommer des blocs après la mise en service. Si la seule personne capable de lire le programme a quitté le projet, le bâtiment a perdu une partie de sa documentation. Le programme doit être traité comme un document maîtrisé, non comme un carnet personnel. Un programme qui dépend de variables globales non documentées n’est pas maintenable, quelle que soit l’élégance de la logique à l’écran. Deux ingénieurs doivent pouvoir l’ouvrir et trouver le même bloc pour la même fonction.
- Blocs fonctionnels pour la logique et les séquences
- Conventions de nommage et blocs réutilisables
- Simulation et tests de points sur site
- Gestion des versions et accès maîtrisé
Intégration avec d’autres systèmes
Peu de bâtiments sont mono-fournisseur. Loxone s’intègre via des interfaces natives et des passerelles : KNX pour l’éclairage et les appareils de pièce, Modbus RTU ou TCP pour les compteurs, onduleurs et équipements, DALI pour les luminaires, BACnet via une passerelle pour les installations et les systèmes de supervision, et HTTP ou REST pour les services logiciels. Les contacts secs restent une solution de repli fiable pour l’incendie, les équipements anciens et les signaux d’état simples. Chaque interface nécessite une cartographie de points : adresse source, nom cible, type de données, unité, mise à l’échelle, sens de lecture ou d’écriture et état de défaut. Les passerelles ajoutent un appareil qui doit être alimenté, configuré et documenté. La conception de l’intégration doit préciser ce qui se passe lorsqu’une passerelle passe hors ligne, et si l’automate local peut continuer sans elle. La prise en charge native et la prise en charge par passerelle sont des engagements différents ; la spécification doit indiquer laquelle est requise pour chaque système. Pour chaque interface, consignez qui détient la configuration de la passerelle et qui appeler en cas de défaillance. Une interface qui fonctionne aujourd’hui mais n’a pas de propriétaire échouera discrètement l’année prochaine. L’état de défaut doit être défini pour chaque point, non pour la passerelle dans son ensemble. Le registre d’interfaces est plus utile qu’un schéma de câblage lorsqu’un appareil tiers se comporte mal.
- KNX et DALI pour l’éclairage et le contrôle des pièces
- Modbus pour les compteurs et les équipements
- BACnet via passerelle pour les installations
- Cartographie de points avec mise à l’échelle et états de défaut
Planification et capacité
Planifier un projet Loxone est surtout un exercice de comptage et de frontières. Partez de la liste de points, regroupez les points par emplacement et décidez quel automate dessert quel groupe. Gardez le périmètre de chaque automate assez restreint pour qu’une défaillance affecte une zone ou un équipement, pas tout le bâtiment. Prévoyez des E/S de réserve pour les évolutions futures ; une marge de planification typique est de 10 à 20 pour cent de la capacité utilisée, mais l’anticipation de croissance propre au projet doit décider. Vérifiez le budget de puissance du bus, les longueurs de câble et le nombre d’appareils par ligne dans la documentation du fabricant pour le modèle et le micrologiciel exacts. Réservez de la place dans le tableau pour une extension supplémentaire et étiquetez les bornes de réserve. Consignez la liste des interfaces avec le protocole, le modèle de passerelle et le nombre de points sur chaque liaison. Un plan de capacité non écrit est une supposition, et une supposition faite avant la construction du tableau devient une contrainte pour les dix prochaines années. Le plan doit aussi préciser ce qui se passe lors du remplacement d’un automate, car ce jour viendra. Le fichier programme, la licence et la sauvegarde doivent être conservés là où le maître d’ouvrage en garde le contrôle, et non uniquement sur le serveur de l’intégrateur. Le plan de capacité doit être revu à chaque changement de conception, pas seulement au début.
- Regrouper les points par emplacement et frontière de défaillance
- Marge de réserve typique de 10 à 20 pour cent
- Vérifier la puissance du bus, la longueur de câble et le nombre d’appareils
- Consigner le plan de capacité et la voie de remplacement
Livraison et cycle de vie
Un projet Loxone est livré par étapes : exigences, liste de points, conception du tableau, configuration, essais en usine, mise en service sur site, réception et support. Les essais en usine détectent les erreurs de câblage et de configuration avant que le site ne soit occupé. La mise en service sur site prouve chaque point, chaque séquence et chaque alarme, y compris le comportement lorsqu’un appareil est déconnecté. La réception doit comprendre les sauvegardes, les schémas réseau, les identifiants, un guide utilisateur et la formation des personnes qui exploiteront le bâtiment. Le modèle de support doit être explicite : qui répond, dans quel périmètre et comment les modifications sont approuvées. Un système local d’abord est plus facile à maintenir lorsque le maître d’ouvrage détient le fichier projet et la documentation, au lieu de dépendre de l’ordinateur portable d’un seul ingénieur. La planification du cycle de vie doit aussi couvrir les appareils de rechange, les mises à jour de micrologiciel et le processus d’ajout d’un étage ou d’un locataire. Le maître d’ouvrage doit pouvoir ajouter un appareil ou modifier un horaire sans reconstruire tout le programme. C’est le sens pratique d’un système ouvert et local. Le script de mise en service doit inclure un redémarrage d’automate, une déconnexion d’appareil de bus et une défaillance de passerelle, car ce sont les conditions que le bâtiment finira par rencontrer. La formation doit expliquer comment lire une alarme, pas seulement comment appuyer sur un bouton de scène. La première année d’exploitation doit inclure une revue des modifications réellement effectuées, car cette liste révèle si le système est utilisé comme prévu.
- Exigences et liste de points d’abord
- Essais en usine avant travaux sur site
- Mise en service point par point
- Sauvegardes, formation et conditions de support
Où une autre plateforme convient mieux
Une plateforme locale d’abord n’est pas la bonne réponse pour tous les bâtiments. Une installation très vaste comptant des centaines de boucles de régulation, des exigences de cybersécurité strictes comparables à celles d’un opérateur de réseau ou une spécification imposant un système de supervision particulier peuvent être mieux servies par une autre architecture. Loxone est le plus fort là où le contrôle des pièces, l’autonomie locale, l’intégration d’appareils tiers et un système clairement exploité par le maître d’ouvrage comptent. Il est plus faible là où un projet exige une très grande base de données unique, une ingénierie BACnet native approfondie ou une organisation de support qui ne travaille qu’avec une plateforme d’entreprise. La conversation de conception honnête porte sur l’adéquation, non sur la fidélité à une marque. Un projet peut utiliser Loxone pour le contrôle des pièces et des installations et un superviseur distinct pour les rapports de portefeuille, à condition que la frontière et la propriété des points soient documentées. Le pire résultat est une plateforme choisie par idéologie puis étirée au-delà de son rôle prévu, car le système obtenu n’est ni local d’abord ni de niveau entreprise. Une bonne spécification indique ce que fait chaque plateforme et ce qu’elle ne fait délibérément pas. La frontière doit être revue lorsqu’un nouveau système est ajouté, car les anciennes hypothèses survivent rarement à une nouvelle interface. Une plateforme qu’il faut défendre à chaque réunion est généralement la mauvaise plateforme pour le projet. Les modes de défaillance courants sont un automate étiré au-delà de sa capacité, une passerelle que personne ne détient, un programme avec un seul lecteur et une sauvegarde jamais restaurée. Chacun est un oubli de conception plutôt qu’un défaut produit.
- Très adapté au contrôle des pièces et des installations ainsi qu’à l’intégration de tiers
- Moins adapté aux patrimoines très vastes à base de données unique
- Les architectures séparées fonctionnent lorsque les frontières sont documentées
- Choisir la plateforme pour le rôle, non pour l’étiquette
Éléments du système Loxone et leurs notes de conception
16 rows| Élément | Fonction | Application type | Note de conception |
|---|---|---|---|
| Miniserver | Automate central et moteur de logique | Local technique ou tableau d’étage | Planifier la capacité, la sauvegarde et le remplacement |
| Extension | Entrées et sorties supplémentaires | Zones supplémentaires et signaux d’installation | Compter la capacité de réserve et la puissance du bus |
| Tree | Bus filaire de périphérie | Interrupteurs, capteurs et variateurs | Topologie, terminaison et budget de puissance |
| Air | Périphériques sans fil | Rénovation et capteurs déportés | Étude de couverture radio et plan des piles |
| 1-Wire | Mesure de température | Capteurs de plancher, de tuyau et de pièce | Longueur de câble et adressage |
| Config | Environnement de programmation | Logique, horaires et scènes | Version et document |
| Loxone App | Interface utilisateur | Contrôle par les occupants et l’opérateur | Vues et permissions par rôle |
| Interface KNX | Intégration d’appareils KNX | Éclairage et stores | Mappage des adresses de groupe |
| Modbus | Intégration des compteurs et des équipements | Compteurs, onduleurs et variateurs | Carte de registres et mise à l’échelle |
| Passerelle BACnet | Intégration d’appareils BACnet | Installations et centrales de traitement d’air | Mappage d’objets et charge d’interrogation |
| Passerelle DALI | Commande d’éclairage | Luminaires et drivers | Adressage et groupes |
| Alimentation et sauvegarde | Alimentation et résilience | Tableaux et automates | UPS, protection contre les surtensions et test de restauration |
| Réseau | Connectivité des automates et des passerelles | Réseaux locaux et de site | Segmentation, adressage et source de temps |
| Accès à distance | Support hors site et accès à l’application | Usage par l’opérateur et l’intégrateur | Accès par rôle, journalisation et révocation |
| Capacité de réserve | Points et appareils futurs | Extension et aménagement locataire | Exprimer la marge en pourcentage |
| Documentation et sauvegardes | Réception et reprise | Maître d’ouvrage et équipe de maintenance | Versionné, stocké hors de l’ordinateur d’ingénierie |
Images du projet
3 images
Questions fréquentes
01Qu’est-ce qu’un Loxone Miniserver ?
C’est l’automate central d’un système Loxone. Il stocke le programme, exécute la logique et les horaires, fournit les interfaces et coordonne les extensions et les appareils périphériques. Le contrôle reste local, de sorte que le bâtiment peut fonctionner sans connexion cloud. La capacité, le nombre d’interfaces et les dispositions de sauvegarde doivent être planifiés avant la construction du tableau.
02Loxone nécessite-t-il une connexion Internet ?
Non pour le contrôle local. Le Miniserver exploite le bâtiment sur site. L’accès internet sert à l’accès distant à l’application, aux notifications, aux mises à jour et au support à distance. La conception doit identifier les fonctions qui doivent continuer lorsque la liaison WAN est coupée, et la mise en service doit prouver cette liste plutôt que la supposer.
03Quelle différence entre Tree, Air et 1-Wire ?
Tree est un bus filaire pour les interrupteurs, les capteurs et les actionneurs. Air est sans fil pour les appareils dont le câblage est difficile à réaliser. 1-Wire est un bus simple utilisé principalement pour les capteurs de température. Ils peuvent coexister, et le choix dépend du bâtiment, des chemins de câbles et du plan de maintenance. Les appareils sans fil exigent une étude de couverture radio et un plan de remplacement des piles.
04Loxone peut-il s’intégrer à BACnet ?
Oui, par l’intermédiaire d’une passerelle BACnet. La passerelle met en correspondance les objets BACnet et les points Loxone. Avant d’arrêter la conception, vérifiez la prise en charge des objets, la capacité en points, le comportement d’interrogation et ce qui se passe lorsque la passerelle est hors ligne. Une passerelle non documentée est un point de défaillance unique que personne n’assume.
05Loxone convient-il aux bâtiments tertiaires ?
Il peut l’être lorsque le contrôle local, les interfaces ouvertes et un modèle de support clair correspondent au projet. Les projets tertiaires exigent généralement plus de documentation, un accès fondé sur les rôles, des tests d’intégration et une planification du cycle de vie qu’une résidence. Le périmètre et le support doivent être convenus explicitement. Un bâtiment tertiaire a aussi besoin d’un responsable nommé pour le programme et les sauvegardes.
06Comment un système Loxone est-il programmé ?
Le comportement est construit dans Config à partir de blocs fonctionnels pour les entrées, les sorties, la logique, les horaires, les scènes et les alarmes. Les bons projets appliquent des conventions de nommage, des blocs réutilisables, une gestion des versions et des essais de points sur site avant la réception. Le programme doit être traité comme un document contrôlé qu’un autre ingénieur peut lire et maintenir.
07Que se passe-t-il si le Miniserver tombe en panne ?
Les fonctions de ce contrôleur s’arrêtent jusqu’à sa remise en service ou son remplacement. La conception doit limiter le périmètre de chaque contrôleur, conserver des sauvegardes, détenir du matériel de rechange et documenter la procédure de restauration. Les fonctions critiques ne doivent pas dépendre d’un seul appareil non documenté. Un remplacement doit être possible sans reconstruire le programme de mémoire.
É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.