Comparação
Loxone vs KNX
Uma comparação prática entre Loxone e KNX: onde corre a lógica, como são cablados os dispositivos, como se fazem alterações e quando faz sentido um projeto híbrido.
Duas arquiteturas numa frase
O KNX distribui a inteligência pelos dispositivos. Um detetor de presença, um atuador de regulação de intensidade, um atuador de estore e um botão têm cada um a sua ligação ao barramento e a sua aplicação. Trocam endereços de grupo através de um barramento de par entrançado, e qualquer dispositivo comissionado pode atuar sobre um telegrama sem controlador central. O Loxone centraliza a lógica num controlador. O Miniserver lê as entradas, executa o programa e comanda as saídas; os dispositivos ligam-se através de Tree, Air, KNX, Modbus ou IP. Esta diferença explica a maior parte dos compromissos práticos que se seguem. Explica também por que razão os dois sistemas falham de forma diferente: uma instalação KNX pode continuar a funcionar dispositivo a dispositivo quando se perde um supervisor, enquanto uma instalação Loxone depende do controlador e da sua cópia de segurança. Nenhum dos modelos é uma questão de fé; cada um impõe uma disciplina diferente ao projeto, ao ensaio e à documentação. A questão certa é onde deve residir a lógica durante a vida do edifício.
- KNX: dispositivos distribuídos, telegramas de endereços de grupo
- Loxone: lógica central, controlador local, dispositivos multiprotocolo
- Ambos podem coexistir no mesmo projeto
Cablagem, topologia e limites de dispositivos
Uma instalação KNX é um barramento: os dispositivos ligam-se em cadeia ou em estrela no mesmo par, com uma fonte de alimentação e um acoplador entre linhas e áreas. Referência do protocolo: uma linha suporta até 64 dispositivos de barramento e uma área até 15 linhas, pelo que a topologia e a capacidade de reserva exigem planeamento e não improvisação. É previsível e adequa-se a projetos de construção nova com uma lista de dispositivos clara. O Loxone Tree utiliza um único cabo que transporta alimentação e comunicação até aos dispositivos Tree, o que reduz as tiragens individuais, mas vincula a escolha dos dispositivos ao ecossistema Tree. O Air cobre reabilitações e locais de difícil cablagem. Na prática, um projeto híbrido é comum: KNX para iluminação e sombreamento, Tree ou Air para controlos de sala e um controlador para a lógica entre sistemas. A topologia deve ser desenhada antes de se puxar o primeiro cabo. O comprimento do barramento, a margem da fonte de alimentação, a colocação dos acopladores e os dispositivos de reserva importam mais do que a etiqueta do cabo.
- Barramento KNX: planeamento de linhas, áreas e acopladores
- Tree: um cabo para alimentação e dados
- Air: reabilitação e percursos difíceis
- Híbrido: protocolo escolhido pelo dispositivo, não pela ideologia
Programação, controlo de alterações e versionamento
A engenharia KNX realiza-se no ETS. Cada dispositivo tem um programa de aplicação, parâmetros e endereços de grupo; uma alteração faz-se voltando a descarregar a aplicação para o dispositivo. O modelo é explícito e portável, mas depende do projeto ETS e da disciplina dos endereços de grupo. A engenharia Loxone realiza-se no Loxone Config. A lógica é construída como blocos funcionais e ligações no controlador, o que torna as sequências entre sistemas mais rápidas de ler e alterar, mas a lógica fica vinculada a essa configuração do controlador. Nenhum dos modelos é intrinsecamente melhor; falham de formas diferentes. Um projeto KNX sem o seu ficheiro ETS é difícil de alterar com segurança. Um projeto Loxone sem uma cópia de segurança versionada da Config é igualmente frágil. Ambos necessitam de registos conforme construído, de um registo de alterações e de uma pessoa designada que possa aprovar um download. O teste prático é simples: consegue um terceiro competente compreender a alteração, executá-la e revertê-la?
- KNX: projeto ETS, parâmetros dos dispositivos, endereços de grupo
- Loxone: projeto Config, blocos funcionais, ligações
- Cópias de segurança versionadas para ambos
- Aprovador designado para downloads
Gateways e seleção de interfaces
Os gateways determinam quanto de um sistema o outro consegue ver. Uma interface KNX IP expõe os endereços de grupo a um controlador; um router KNX IP liga linhas e áreas e pode transportar encaminhamento e também tunnelling. A escolha afeta a capacidade, a latência, o diagnóstico e o número de ligações simultâneas. Pergunte quantos endereços de grupo a interface pode exportar, se suporta encaminhamento ou tunnelling, como se comporta após uma interrupção de rede e se o KNX Secure é necessário. Um gateway saturado na entrega não deixa margem para a próxima adaptação do espaço. A mesma lógica aplica-se a outras pontes de protocolo: conte pontos, não dispositivos, e mantenha capacidade de reserva para alterações que chegam sempre. O gateway deve ser tratado como infraestrutura, com um modo de falha, uma unidade de reserva e um procedimento de substituição documentado. Registe o seu endereço IP, a sub-rede, a porta e as credenciais sob controlo de alterações.
- Interface KNX IP vs router IP
- Tunnelling vs encaminhamento e clientes simultâneos
- Capacidade, latência e KNX seguro
- Reserva, endereço fixo e procedimento de substituição
Comissionamento, ensaios e modos de falha
Ensaie primeiro o barramento, depois o gateway e por fim a plataforma. No barramento, confirme a alimentação dos dispositivos, os acopladores de linha, a comunicação por endereços de grupo e a chamada de cenas. No gateway, confirme a descoberta, a exportação de endereços, o comportamento de leitura e escrita e a reconexão após uma interrupção de rede. Na plataforma, confirme que cada ponto mapeado apresenta o valor, a unidade e o estado corretos, e que um comando chega ao dispositivo de campo. Ensaie o caminho de falha: desligue o gateway e verifique se as funções KNX locais continuam a funcionar. Registe o resultado na lista de pontos e não num caderno separado. Um ponto que aparece numa árvore de navegação não está comissionado enquanto não tiver sido lido, escrito e observado no dispositivo de campo. Os ensaios de sequência devem incluir os casos que só acontecem de noite: uma luminária avariada, um estore encravado, um reinício do controlador durante uma cena.
- Saúde do barramento, acopladores e tráfego de endereços de grupo
- Descoberta do gateway, leitura/escrita e reconexão
- Valor, unidade e estado por ponto na plataforma
- Operação local com o gateway offline
- Registos de ensaio assinados face à lista de pontos
Ecossistema, custo do ciclo de vida e dependência do fornecedor
O KNX tem um mercado de dispositivos vasto: muitos fabricantes, muitos formatos e uma base instalada longa, sobretudo na Europa. A concorrência pode manter os preços dos dispositivos visíveis, mas o tempo de engenharia e de comissionamento são custos reais. O Loxone tem um catálogo de dispositivos mais estreito e uma experiência de software mais integrada; o controlador e a sua programação tornam-se o centro do projeto. Em ambos os casos, o primeiro orçamento mais barato não é sempre o ciclo de vida mais barato. Conte horas de engenharia, reservas, formação e alterações futuras, e não apenas hardware. Conte também o custo da fronteira: dois sistemas significam duas competências, dois conjuntos de documentação e um mapeamento que tem de ser mantido. Um projeto híbrido é muitas vezes a resposta certa, mas não é gratuito. A dependência do fornecedor não é apenas uma questão de licença; é também uma questão de competências, e a comparação honesta inclui a pessoa que ainda estará disponível dentro de cinco anos para alterar um endereço de grupo ou um bloco da Config.
- KNX: dispositivos multi-fabricante, competências em ETS necessárias
- Loxone: stack integrada, centrada no controlador
- O custo do ciclo de vida inclui engenharia e alterações
- Dois sistemas significam duas competências e um mapeamento
Qual deles se adequa ao seu edifício
Escolha KNX quando o caderno de encargos exige um barramento independente do fabricante, quando o consultor ou o cliente já possui competências em KNX, ou quando a escolha de dispositivos entre muitos fabricantes é um requisito estrito. Escolha Loxone quando o edifício necessita de uma camada de lógica única para AVAC, iluminação, sombreamento, energia e acessos, e quando o controlo local com uma interface de operador clara importa mais do que a independência dos dispositivos. Muitos projetos escolhem ambos: KNX ao nível do campo, Loxone ao nível da integração. É uma decisão de projeto e não um compromisso. A decisão deve ser registada com os respetivos fundamentos, porque a pessoa seguinte perguntará por que motivo a fronteira está onde está. Uma regra simples ajuda: colocar o controlo onde está o dispositivo e a coordenação onde está o edifício. Se o projeto não tiver equipa de manutenção, prefira a arquitetura com menos peças móveis e documentação mais clara.
- KNX primeiro: dispositivos de campo multi-fabricante e ETS interno
- Loxone primeiro: lógica integrada e uma visão única do operador
- Híbrido: barramento de campo KNX, supervisão Loxone
- Registar a fronteira e os seus fundamentos
Loxone e KNX em comparação
15 rows| Critério | Loxone | KNX |
|---|---|---|
| Arquitetura | Centrada no controlador; lógica no Miniserver | Distribuída; lógica nos dispositivos de barramento |
| Cablagem de campo | Tree, Air, KNX, Modbus e IP | Barramento de par entrançado com acopladores de linha e de área |
| Limites de topologia | Capacidade do controlador e limites dos segmentos Tree ou Air | Até 64 dispositivos por linha e 15 linhas por área |
| Programação | Blocos funcionais do Loxone Config | ETS com parâmetros de dispositivos e endereços de grupo |
| Escolha de dispositivos | Ecossistema Loxone mais protocolos abertos | Catálogo KNX multi-fabricante |
| Iluminação e sombreamento | Dispositivos nativos e integração KNX ou DALI | Atuadores e sensores KNX nativos |
| HVAC | Através de I/O, Modbus, BACnet ou KNX | Através de atuadores e gateways KNX |
| Lógica entre sistemas | Forte; um programa de controlador | Possível, mas dispersa por dispositivos e gateways |
| Reabilitação | Air e Tree reduzem a cablagem nova | Cablagem de barramento ainda necessária até cada dispositivo |
| Gateway e interface | Interface KNX nativa ou gateway IP | Interface ou router IP, tunnelling ou encaminhamento |
| Diagnóstico | Registos da plataforma e diagnóstico do controlador | Monitor de barramento, registos do gateway e diagnóstico ETS |
| Comportamento em falha | A falha do controlador interrompe a lógica central; os dispositivos locais variam | Os dispositivos de barramento podem manter funções locais |
| Gestão de alterações | Versão da Config e cópia de segurança do controlador | Projeto ETS e disciplina de endereços de grupo |
| Competências | Formação em Loxone Config | Experiência em ETS e disciplina de endereços de grupo |
| Adequação típica | Lógica integrada do edifício e uma visão única do operador | Caderno de encargos com dispositivos multi-fabricante |
Imagens do projeto
3 images
Perguntas frequentes
01O Loxone pode controlar dispositivos KNX?
Sim, através de uma interface ou gateway KNX. Os dispositivos KNX mantêm os seus próprios programas de aplicação; o Loxone lê e escreve endereços de grupo. O projeto deve confirmar quais os tipos de ponto de dados e endereços de grupo expostos.
02O KNX é mais aberto do que o Loxone?
O KNX é um standard aberto com dispositivos multi-fabricante. O Loxone é uma plataforma proprietária com interfaces abertas, incluindo KNX, Modbus, BACnet e APIs baseadas em IP. A abertura depende do que é necessário alterar mais tarde e não apenas do nome do protocolo.
03Qual é mais económico?
Não há uma resposta universal. O KNX pode ter preços de dispositivos mais competitivos, mas exige engenharia em ETS. O Loxone pode reduzir a cablagem e o esforço de integração, mas centra o projeto no seu controlador. Compare o ciclo de vida completo: projeto, hardware, programação, comissionamento, reservas e alterações futuras.
04Podemos combinar Loxone e KNX num mesmo edifício?
Sim. Um padrão comum é KNX para iluminação e sombreamento ao nível do campo, com o Loxone a executar a lógica entre sistemas, o AVAC e a energia. A fronteira deve ser documentada: qual o sistema responsável por cada endereço de grupo, cena e programação.
05O Loxone substitui uma instalação KNX?
Fisicamente, não. Os dispositivos KNX existentes podem geralmente permanecer no local e ser integrados. A substituição só faz sentido quando os dispositivos estão obsoletos, indisponíveis ou incapazes de fornecer a função exigida.
06Qual é melhor para um hotel?
Ambos podem funcionar. O KNX é comum nos cadernos de encargos hoteleiros europeus e oferece uma ampla escolha de dispositivos. O Loxone é forte onde o controlo de quartos, os eventos do PMS, a energia e a supervisão do edifício exigem uma camada de lógica única. O tipo de quarto e o modelo de operação devem decidir.
07É necessário o ETS para alterar um sistema KNX?
Sim, para alterações ao nível dos dispositivos: os parâmetros e os endereços de grupo residem no projeto ETS. Um supervisor pode alterar cenas e programações sem ETS, mas não a aplicação do dispositivo.
08O que acontece quando o controlador falha?
Os dispositivos KNX podem continuar a operar localmente no barramento para funções que não dependem de um controlador. Os controladores Loxone devem ser especificados com capacidade de reserva, cópia de segurança e um procedimento de recuperação documentado. O modo de falha pertence ao projeto.
Próximo passo
Traga-nos o edifício.
Diga-nos o tipo de edifício, os sistemas abrangidos e o resultado pretendido. Indicaremos o caminho mais curto para um sistema funcional.