Review routing multicast KNX
Il video mostra sorgente KNX e candidati Control4 affiancati per verificare routing, feedback e ipotesi gateway prima dell export.
Contesto da rendere visibile prima di Composer
CoduWorks non configura rete o gateway. La piattaforma rende visibili oggetti ETS, DPT, nomi, feedback e candidati Control4 per separare problemi di route da problemi di mapping.
Flusso di lavoro consigliato
Prima del build, verificare router KNX/IP, visibilita multicast, limiti linea, filter table e gruppi feedback. Composer deve creare la struttura dopo questa review.
- Verificare se il progetto usa una vera route KNX/IP routing.
- Controllare gruppi command e feedback attraverso router e filter table.
- Mantenere visibili le ipotesi gateway prima dell export .codu.
Controllo prima dell export .codu
Verificare ruolo router/interface, multicast tra controller e router KNX/IP, regole VLAN, filter table, DPT, read flags e ritorno dei gruppi stato.
Errori evitati con questo approccio
Se il comando funziona ma il feedback non torna, route, filter table o DPT possono essere il problema. Senza preflight sembra un device Control4 sbagliato.
Fonti ufficiali verificate
Le affermazioni tecniche di questa pagina restano vicine alla documentazione ufficiale KNX, Control4 o del produttore.
Strumenti e documentazione correlati
FAQ
CoduWorks configura multicast routing?
No. ETS, router KNX/IP e rete restano responsabilita dell installatore. CoduWorks aiuta la review prima di Composer.
Perche un dispositivo funziona solo in un verso?
Il comando puo passare mentre il feedback e filtrato, tipizzato male o bloccato dalla route KNX/IP.
Va verificato multicast prima dell export .codu?
Il .codu puo essere preparato da ETS, ma ipotesi routing e feedback importanti devono essere note prima del build Composer.
Verifica la route KNX/IP prima della creazione
Importa ETS, controlla command, feedback e contesto gateway, poi esporta .codu quando il build Control4 e pronto.