Loxone Config
Programmation Loxone Config — structure, logique et remise
Comment Loxone Config est structuré, comment garder une logique lisible et testable, et ce qu’il faut remettre pour qu’un autre ingénieur puisse maintenir le projet.
Réponse rapide
Config est l’environnement d’ingénierie dans lequel le projet Miniserver est construit : pièces, fonctions, entrées, sorties, logique, horaires et interfaces utilisateur. Une bonne programmation est structurée, nommée et documentée, afin qu’un autre ingénieur puisse la lire. Il ne s’agit pas d’écrire des blocs astucieux, mais de rendre le comportement du bâtiment visible, testable et modifiable en toute sécurité.
Le projet est un modèle du bâtiment
Config organise le travail par pièce et par fonction, et non selon une liste plate de bornes. Une pièce contient ses luminaires, sa protection solaire, son climat et ses capteurs ; une fonction décrit ce que fait la pièce. Cette structure fait la différence entre un projet maintenable et un empilement de blocs qui fonctionne par hasard. Nommez les points du point de vue du bâtiment, utilisez des préfixes cohérents et alignez la hiérarchie des pièces et des fonctions sur la liste de points. Lorsque le nommage dérive, chaque tâche ultérieure ralentit : alarmes, tendances, synoptiques, remise et recherche de défauts dépendent tous des mêmes noms. Un contrôle utile consiste à confier l’arborescence du projet à une personne n’ayant jamais vu le site et à lui demander de trouver la salle de réunion du troisième étage sans utiliser la recherche.
- Reproduisez le plan des pièces dans l’arborescence du projet
- Adoptez une convention de nommage unique dès le premier jour
- Conservez les mêmes noms pour les synoptiques et les alarmes
Une logique en couches
Placez les comportements simples au plus près de l’équipement : un luminaire suit son interrupteur, une vanne suit sa consigne de pièce. Placez les comportements inter-pièces et inter-systèmes dans une couche bâtiment clairement identifiée. Placez les rapports et l’optimisation au-dessus. Cette stratification évite qu’une petite modification de pièce ne se propage à tout le projet et permet de tester par tranches. Utilisez des machines à états pour les séquences à états distincts, plutôt qu’un empilement de conditions que seul son auteur comprend. Documentez chaque bloc non évident par une note courte : ce qu’il fait, ce qui le déclenche et ce qui se passe en cas de défaillance d’un capteur. Si un bloc nécessite un paragraphe d’explication, ce paragraphe doit figurer dans les notes du projet à côté du bloc, et non dans un document séparé que personne n’ouvre.
- Les logiques équipement, pièce et bâtiment restent séparées
- Utilisez des machines à états pour les séquences à plusieurs étapes
- Commentez chaque bloc non évident
Des preuves de test, pas de la confiance
Un projet n’est pas terminé quand l’application paraît correcte. Testez les entrées une par une, provoquez des défauts de capteur, vérifiez le routage des alarmes, contrôlez les horaires selon les types de jour et confirmez l’expiration des forçages. Consignez le résultat en regard de la liste de points, et non dans la mémoire de quelqu’un. Testez le chemin de défaillance : que se passe-t-il lorsqu’un appareil de bus disparaît, qu’un compteur cesse de répondre ou que le réseau tombe ? Une courte fiche de test écrite vaut mieux qu’une longue démonstration, car elle survit aux changements de personnel et rend la prochaine visite de maintenance moins coûteuse. Incluez aussi le volet humain : l’exploitant sait-il quoi faire lorsqu’une alarme survient à 02:00, et cette consigne figure-t-elle dans le dossier de remise plutôt que dans la tête de l’installateur ?
- Testez chaque entrée et sortie par rapport à la liste de points
- Provoquez des défauts et consignez l’état résultant
- Vérifiez les horaires, les forçages et le routage des alarmes
Remise et gestion des modifications
Remettez le fichier projet, la version logicielle, la sauvegarde, le schéma réseau, la liste de points et un journal des modifications. Protégez le projet par des identifiants contrôlés par le maître d’ouvrage, et non par des identifiants qui partent avec l’installateur. Convenez de la manière dont les modifications seront demandées, testées et consignées. Une petite modification d’horaire ne devrait pas nécessiter une visite sur site si l’accès à distance et les permissions sont correctement conçus. La qualité d’une configuration ne se mesure pas au volume de logique écrite, mais à la confiance avec laquelle l’équipe du maître d’ouvrage peut exploiter et modifier le bâtiment après le départ des ingénieurs. Un projet qui ne peut être restauré, expliqué et modifié par quelqu’un d’autre n’est pas réellement remis : il est seulement mis sous tension.
- Identifiants et licences contrôlés par le maître d’ouvrage
- Un processus écrit de demande et de test des modifications
- Un test de restauration avant la remise finale
Couches de programmation
5 rows| Couche | Contenu | Preuve de test |
|---|---|---|
| Équipement | Entrées, sorties et comportement local de sécurité | Test des entrées et sorties point par point |
| Pièce | Éclairage, protection solaire, climat et scènes de pièce | Test des scènes de pièce et des consignes |
| Bâtiment | Horaires, interverrouillages, alarmes et logique énergétique | Test des séquences, des alarmes et du basculement |
| Interface utilisateur | Pages d’application, commandes tactiles et vues par rôle | Contrôle des accès par rôle et de l’ergonomie |
| Réception | Sauvegardes, versions, notes et journal des modifications | Test de restauration et revue du dossier de récolement |
Images du projet
3 images
Questions fréquentes
01Config relève-t-il de la programmation ou de la configuration ?
Des deux. C’est un environnement graphique, mais le travail relève de l’ingénierie : structure, logique, nommage et tests. La distinction importe moins que la lisibilité et la maintenabilité du résultat.
02Faut-il écrire du code ?
La plupart des projets sont construits à partir de blocs fonctionnels natifs. Une logique personnalisée est disponible pour des séquences particulières, mais elle doit être documentée et justifiée, car elle augmente le niveau de compétence requis pour maintenir le site.
03Un autre intégrateur peut-il maintenir le projet ?
Oui, si le fichier projet, la convention de nommage, les notes et les identifiants sont correctement remis. Cela devrait être une exigence contractuelle, et non une faveur accordée après l’achèvement.
04À quelle fréquence faut-il réaliser les sauvegardes ?
Avant et après chaque modification, ainsi qu’à la remise. Conservez une copie hors du contrôleur et testez sa restauration. Une sauvegarde non testée n’est qu’un espoir.
05L’application peut-elle être personnalisée par utilisateur ?
Oui. Les pages utilisateur et les permissions peuvent être structurées par rôle, afin que les exploitants, les techniciens et les résidents voient des niveaux de détail et des commandes différents.
É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.