Revue routing multicast KNX
La video montre source KNX et candidats Control4 cote a cote pour verifier routing, feedback et hypotheses gateway avant export.
Le contexte à rendre visible avant Composer
CoduWorks ne configure pas le reseau ni le gateway. La plateforme rend visibles objets ETS, DPT, noms, feedback et candidats Control4 pour separer probleme de route et probleme de mapping.
Flux de travail recommandé
Avant le build, verifier routeur KNX/IP, visibilite multicast, limites de ligne, filter tables et groupes feedback. Composer doit creer la structure apres cette revue.
- Verifier si le projet utilise une vraie route KNX/IP routing.
- Controler commandes et feedbacks via routeurs et filter tables.
- Garder les hypotheses gateway visibles avant export .codu.
Contrôle avant export .codu
Verifier role router/interface, multicast entre controller et routeur KNX/IP, regles VLAN, filter tables, DPT, read flags et retour des groupes statut.
Erreurs évitées avec cette approche
Si la commande fonctionne mais pas le feedback, la route, la filter table ou le DPT peuvent etre en cause. Sans preflight, cela ressemble a un mauvais appareil Control4.
Références officielles vérifiées
Les affirmations techniques de cette page restent proches de la documentation officielle KNX, Control4 ou fabricant.
Outils et documentation liés
FAQ
CoduWorks configure-t-il le multicast routing?
Non. ETS, routeur KNX/IP et reseau restent sous responsabilite installateur. CoduWorks aide a la revue avant Composer.
Pourquoi un appareil fonctionne-t-il dans un seul sens?
La commande peut passer alors que le feedback est filtre, mal type ou bloque par la route KNX/IP.
Faut-il verifier multicast avant export .codu?
Le .codu peut etre prepare depuis ETS, mais les hypotheses routing et feedback doivent etre connues avant le build Composer.
Verifier la route KNX/IP avant creation
Importez ETS, controlez commandes, feedback et contexte gateway, puis exportez .codu quand le build Control4 est pret.