Sistema Loxone
Guia do Sistema Loxone: Arquitetura e Aplicações
Como está estruturado um sistema de automação de edifícios Loxone: Miniserver, extensões, Tree, Air e 1-Wire, programação em Config, integração com KNX, BACnet e Modbus, e entrega de projetos.
Resposta rápida
A Loxone é uma plataforma de automação de edifícios local-first construída em torno do Miniserver, um controlador que executa lógica, programações e cenas sem necessidade obrigatória de ligação à nuvem. As extensões acrescentam entradas e saídas, Tree, Air e 1-Wire ligam dispositivos de campo, e o Config define o comportamento que a aplicação e as interfaces expõem.
Uma arquitetura local-first
A Loxone foi concebida em torno de um princípio simples: o edifício deve continuar a funcionar quando a Internet não funciona. O Miniserver armazena o programa de controlo, executa programações e cenas e comunica com os dispositivos de campo em buses locais. O acesso remoto e a aplicação móvel são comodidades sobrepostas, e não uma dependência para a operação diária. Esta conceção adequa-se a edifícios com conetividade pouco fiável, requisitos rigorosos de residência de dados ou necessidade de continuar a operar durante uma falha de rede. Também altera o modelo de assistência: o integrador pode diagnosticar a lógica localmente, e o proprietário não fica exposto ao fim de uma subscrição. Local-first não significa isolado. Gateways e interfaces ligam equipamentos KNX, Modbus, DALI e BACnet, e um supervisor pode ler o sistema sem assumir o controlo. Para um edifício comercial aplica-se o mesmo princípio à rede de controladores: primeiro a autonomia local, depois a coordenação central. A questão prática é quais as funções que têm de sobreviver a uma falha de WAN e se o projeto testou esse cenário. Uma afirmação local-first que nunca foi testada offline é apenas uma frase de marketing. O teste deve ser repetido após uma atualização de firmware, porque uma alteração no comportamento do controlador pode reintroduzir silenciosamente uma dependência que o projeto tinha eliminado. A autonomia local também tem um custo: cada controlador necessita da sua própria cópia de segurança e do seu próprio plano de substituição.
- Lógica e programações armazenadas no local
- Aplicação e acesso remoto como camadas opcionais
- Buses locais para dispositivos de campo
- Gateways para sistemas de terceiros
O Miniserver e as extensões
O Miniserver é o controlador central: contém o programa, as programações, as permissões de utilizador e as interfaces. As entradas e saídas integradas cobrem diretamente uma instalação pequena; as extensões acrescentam capacidade através de um bus local quando o projeto cresce. O planeamento de capacidade deve ocorrer antes da construção do quadro, porque o tipo de entrada, o tipo de saída e a capacidade de reserva afetam o invólucro, a fonte de alimentação e a cablagem. O projeto deve também registar que funções funcionam em cada controlador, para que uma falha tenha um efeito limitado. As cópias de segurança, os documentos de licença e um procedimento de reposição testado fazem parte do sistema, não são uma reflexão tardia. A seleção do modelo é uma decisão de projeto baseada na contagem de pontos, nos requisitos de interface e na expansão futura, não uma escolha predefinida repetida do projeto anterior. O modelo selecionado deve ser documentado com a contagem de pontos e a lista de interfaces que o justificaram. Uma margem de capacidade de reserva é mais barata em fase de projeto do que um segundo quadro após a entrega, e deve ser indicada como percentagem da capacidade utilizada, em vez de ficar como uma intenção vaga. O procedimento de substituição deve ser escrito para alguém que nunca viu o quadro e testado uma vez enquanto o engenheiro original ainda está disponível. Um segundo controlador para resiliência é uma escolha de projeto, não uma predefinição; necessita de um comportamento de comutação por falha definido.
- Programa, programações e permissões
- E/S integradas mais bus de extensão
- Planeamento de capacidade e de reserva
- Cópias de segurança e uma reposição testada
Tree, Air e 1-Wire
A Loxone utiliza três tecnologias de periféricos para funções diferentes. O Tree é um bus com fios para interruptores, sensores, reguladores e atuadores; transporta energia e dados e adequa-se a obras novas, onde os traçados de cabos são planeados. O Air é um protocolo sem fios para dispositivos em que a cablagem é impraticável, incluindo reabilitação e algumas localizações de sensores; necessita de um levantamento de sinal e de uma estratégia de alimentação para dispositivos a pilhas. O 1-Wire é um bus simples utilizado sobretudo para medição de temperatura em pisos, tubagens e salas, com um endereçamento que torna cada sensor identificável. Os três podem coexistir numa mesma instalação. As regras de projeto abrangem a topologia, o comprimento dos cabos, a terminação, o orçamento de potência e a separação do ruído da rede elétrica. A escolha não depende de qual a tecnologia mais recente, mas do edifício, dos traçados e do modelo de manutenção. O sem fios deve ser tratado como uma decisão de projeto com um plano de manutenção, e não como um atalho ao planeamento. Documentar os endereços dos dispositivos e a topologia do bus poupa horas durante o comissionamento e na posterior deteção de avarias, e é a primeira coisa que se perde quando um projeto passa entre instaladores. Um dispositivo sem fios que exige uma escada para ser alcançado é um custo de manutenção, mesmo quando não é um problema de controlo. Etiquetar cada segmento de bus nas duas extremidades é um pequeno hábito que poupa uma longa tarde.
- Tree: bus com fios, com energia e dados
- Air: sem fios para reabilitação e sensores
- 1-Wire: medição de temperatura
- Topologia, alimentação e endereçamento documentados
Config: programar o edifício
O Config é o ambiente de engenharia onde o comportamento do edifício é definido. Os blocos funcionais tratam entradas, saídas, lógica, programações, cenas, alarmes e direitos de utilizador. Um projeto bem estruturado utiliza convenções de nomenclatura, blocos reutilizáveis e comentários que outro engenheiro consegue seguir. A simulação e os testes online ajudam a verificar a lógica antes do comissionamento, mas não substituem as verificações ponto a ponto no local. O controlo de versões é importante: uma programação alterada ou um novo interbloqueio deve ser registado com data e motivo. O controlo de acesso ao ficheiro do projeto também é importante, porque uma edição não documentada pode comprometer uma sequência testada. O resultado do Config não é apenas um programa funcional; é uma descrição mantível de como o edifício deve comportar-se, que é o que o proprietário necessita na entrega. Uma convenção de nomenclatura acordada no início é mais barata do que renomear blocos após o comissionamento. Se a única pessoa capaz de ler o programa saiu do projeto, o edifício perdeu parte da sua documentação. O programa deve ser tratado como um documento controlado, não como um caderno pessoal. Um programa que depende de variáveis globais não documentadas não é mantível, por mais elegante que a lógica pareça no ecrã. Dois engenheiros devem conseguir abri-lo e encontrar o mesmo bloco para a mesma função.
- Blocos funcionais para lógica e sequências
- Convenções de nomenclatura e blocos reutilizáveis
- Simulação e testes de pontos no local
- Controlo de versões e acesso controlado
Integração com outros sistemas
Muito poucos edifícios são de fornecedor único. A Loxone integra através de interfaces nativas e gateways: KNX para iluminação e dispositivos de sala, Modbus RTU ou TCP para contadores, inversores e equipamentos, DALI para luminárias, BACnet através de um gateway para instalações e sistemas de supervisão, e HTTP ou REST para serviços de software. Os contactos secos continuam a ser uma alternativa fiável para incêndio, equipamentos legados e sinais de estado simples. Cada interface necessita de um mapa de pontos: endereço de origem, nome de destino, tipo de dados, unidade, escalonamento, direção de leitura ou escrita e estado de falha. Os gateways acrescentam um dispositivo que tem de ser alimentado, configurado e documentado. O projeto de integração deve indicar o que acontece quando um gateway fica offline e se o controlador local pode continuar sem ele. O suporte nativo e o suporte por gateway são compromissos diferentes; a especificação deve indicar qual deles é exigido para cada sistema. Para cada interface, registe quem é responsável pela configuração do gateway e quem é contactado quando falha. Uma interface que funciona hoje mas não tem responsável falhará silenciosamente no próximo ano. O estado de falha deve ser definido para cada ponto, e não para o gateway como um todo. O registo de interfaces é mais útil do que um esquema de cablagem quando um dispositivo de terceiros se comporta mal.
- KNX e DALI para iluminação e controlo de sala
- Modbus para contadores e equipamentos
- BACnet através de gateway para instalações
- Mapa de pontos com escalonamento e estados de falha
Planeamento e capacidade
Planear um projeto Loxone é sobretudo um exercício de contagem e de fronteiras. Comece pela lista de pontos, agrupe os pontos por localização e decida qual o controlador que serve cada grupo. Mantenha o âmbito de cada controlador suficientemente pequeno para que uma falha afete uma zona ou um equipamento, e não o edifício inteiro. Reserve E/S para alterações futuras; uma margem de planeamento típica é de 10 a 20 por cento da capacidade utilizada, mas a expectativa de crescimento do próprio projeto deve decidir. Verifique o orçamento de potência do bus, os comprimentos de cabo e o número de dispositivos por linha face à documentação do fabricante para o modelo e o firmware exatos. Reserve espaço no quadro para uma extensão adicional e etiquete os bornes de reserva. Registe a lista de interfaces com o protocolo, o modelo de gateway e a contagem de pontos em cada ligação. Um plano de capacidade que não está escrito é uma suposição, e uma suposição feita antes da construção do quadro torna-se uma limitação durante os próximos dez anos. O plano deve também indicar o que acontece quando um controlador é substituído, porque esse dia chegará. O ficheiro do programa, a licença e a cópia de segurança devem ser guardados onde o proprietário os controla, e não apenas no servidor do integrador. O plano de capacidade deve ser revisto em cada alteração de projeto, e não apenas no início.
- Agrupar pontos por localização e fronteira de falha
- Margem de reserva típica de 10 a 20 por cento
- Verificar potência do bus, comprimento de cabo e número de dispositivos
- Registar o plano de capacidade e o percurso de substituição
Entrega e ciclo de vida
Um projeto Loxone é entregue por fases: requisitos, lista de pontos, projeto do quadro, configuração, testes em fábrica, comissionamento no local, entrega e assistência. Os testes em fábrica detetam erros de cablagem e de configuração antes de o local estar ocupado. O comissionamento no local comprova cada ponto, cada sequência e cada alarme, incluindo o comportamento quando um dispositivo é desligado. A entrega deve incluir cópias de segurança, diagramas de rede, credenciais, um guia do utilizador e formação para as pessoas que irão operar o edifício. O modelo de assistência deve ser explícito: quem responde, com que âmbito e como são aprovadas as alterações. Um sistema local-first é mais fácil de manter quando o proprietário detém o ficheiro do projeto e a documentação, em vez de depender do portátil de um único engenheiro. O planeamento do ciclo de vida deve também abranger dispositivos de reserva, atualizações de firmware e o processo para acrescentar um novo piso ou inquilino. O proprietário deve conseguir acrescentar um dispositivo ou alterar uma programação sem reconstruir todo o programa. Esse é o significado prático de um sistema aberto e local. O guião de comissionamento deve incluir um reinício do controlador, a desconexão de um dispositivo de bus e uma falha de gateway, porque são essas as condições que o edifício acabará por enfrentar. A formação deve incluir como ler um alarme, e não apenas como premir um botão de cena. O primeiro ano de operação deve incluir uma revisão das alterações efetivamente realizadas, porque essa lista revela se o sistema é utilizado conforme o projeto.
- Primeiro os requisitos e a lista de pontos
- Testes em fábrica antes dos trabalhos no local
- Comissionamento ponto a ponto
- Cópias de segurança, formação e condições de assistência
Onde outra plataforma se adequa melhor
Uma plataforma local-first não é a resposta certa para todos os edifícios. Instalações muito grandes com centenas de ciclos de controlo, requisitos rigorosos de cibersegurança de nível industrial ou uma especificação que impõe um determinado sistema de supervisão podem ser melhor servidos por outra arquitetura. A Loxone é mais forte onde o controlo de sala, a autonomia local, a integração de dispositivos de terceiros e um sistema claro operado pelo proprietário são importantes. É mais fraca onde um projeto necessita de uma base de dados única muito grande, de engenharia BACnet nativa aprofundada ou de uma organização de assistência que só trabalha com uma plataforma empresarial. A conversa honesta de projeto é sobre adequação, não sobre lealdade a uma marca. Um projeto pode utilizar a Loxone para controlo de salas e instalações e um supervisor separado para o reporte de carteira, desde que a fronteira e a propriedade dos pontos estejam documentadas. O pior resultado é uma plataforma escolhida por ideologia e depois forçada para além da sua função prevista, porque o sistema resultante não é nem local-first nem de nível empresarial. Uma boa especificação indica o que cada plataforma faz e o que deliberadamente não faz. A fronteira deve ser revista quando é acrescentado um novo sistema, porque os pressupostos antigos raramente sobrevivem a uma nova interface. Uma plataforma que tem de ser defendida em todas as reuniões é habitualmente a plataforma errada para o projeto. Os modos de falha comuns são um controlador forçado para além da sua capacidade, um gateway sem responsável, um programa com um único leitor e uma cópia de segurança que nunca foi reposta. Cada um é uma omissão de projeto e não um defeito do produto.
- Boa adequação para salas, instalações e integração de terceiros
- Adequação mais fraca a parques muito grandes com base de dados única
- Arquiteturas divididas funcionam quando as fronteiras estão documentadas
- Escolher a plataforma pela função, não pelo rótulo
Elementos do sistema Loxone e respetivas notas de projeto
16 rows| Elemento | Função | Aplicação típica | Nota de projeto |
|---|---|---|---|
| Miniserver | Controlador central e motor de lógica | Sala técnica ou quadro de piso | Planear capacidade, cópia de segurança e substituição |
| Extensão | Entradas e saídas adicionais | Zonas adicionais e sinais de instalações | Contabilizar capacidade de reserva e potência do bus |
| Tree | Bus de periféricos com fios | Interruptores, sensores e reguladores | Topologia, terminação e orçamento de potência |
| Air | Periféricos sem fios | Reabilitação e sensores remotos | Levantamento de sinal e plano de pilhas |
| 1-Wire | Medição de temperatura | Sensores de piso, tubagem e sala | Comprimento de cabo e endereçamento |
| Config | Ambiente de programação | Lógica, programações e cenas | Versão e documentação |
| Loxone App | Interface de utilizador | Controlo por ocupantes e operadores | Vistas e permissões por perfil |
| Interface KNX | Integração de dispositivos KNX | Iluminação e sombreamento | Mapeamento de endereços de grupo |
| Modbus | Integração de contadores e equipamentos | Contadores, inversores e acionamentos | Mapa de registos e escalonamento |
| Gateway BACnet | Integração de dispositivos BACnet | Instalações e unidades de tratamento de ar | Mapeamento de objetos e carga de interrogação |
| Gateway DALI | Controlo de iluminação | Luminárias e drivers | Endereçamento e grupos |
| Alimentação e cópia de segurança | Alimentação e resiliência | Quadros e controladores | UPS, proteção contra sobretensões e teste de reposição |
| Rede | Conetividade de controladores e gateways | Redes locais e do local | Segmentação, endereçamento e fonte de tempo |
| Acesso remoto | Assistência remota e acesso à aplicação | Utilização por operadores e integradores | Acesso por função, registo e revogação |
| Capacidade de reserva | Pontos e dispositivos futuros | Expansão e compartimentação do inquilino | Indicar a margem como percentagem |
| Documentação e cópias de segurança | Entrega e recuperação | Proprietário e equipa de manutenção | Versionado, guardado fora do portátil de engenharia |
Imagens do projeto
3 images
Perguntas frequentes
01O que é um Loxone Miniserver?
É o controlador central de um sistema Loxone. Armazena o programa, executa lógica e programações, fornece interfaces e coordena extensões e dispositivos periféricos. O controlo permanece local, pelo que o edifício pode funcionar sem ligação à nuvem. A capacidade, o número de interfaces e as soluções de cópia de segurança devem ser planeados antes da construção do quadro.
02A Loxone precisa de ligação à internet?
Não para o controlo local. O Miniserver opera o edifício no local. O acesso à Internet é utilizado para acesso remoto à aplicação, notificações, atualizações e assistência remota. O projeto deve identificar quais as funções que têm de continuar quando a ligação WAN está em baixo, e o comissionamento deve comprovar essa lista em vez de a presumir.
03Qual é a diferença entre Tree, Air e 1-Wire?
O Tree é um barramento com fios para interruptores, sensores e atuadores. O Air é sem fios, para dispositivos em que a cablagem não é viável. O 1-Wire é um barramento simples, utilizado sobretudo para sensores de temperatura. Podem coexistir, e a escolha depende do edifício, dos trajetos e do plano de manutenção. Os dispositivos sem fios exigem um levantamento de sinal e um plano de substituição de pilhas.
04A Loxone pode integrar-se com BACnet?
Sim, através de um gateway BACnet. O gateway mapeia objetos BACnet para pontos Loxone. Antes de fixar o projeto, verifique o suporte de objetos, a capacidade de pontos, o comportamento do polling e o que acontece quando o gateway fica offline. Um gateway que não está documentado é um ponto único de falha sem responsável.
05A Loxone é adequada para edifícios comerciais?
Pode ser, quando o controlo local, as interfaces abertas e um modelo de suporte claro se ajustam ao projeto. Os projetos comerciais exigem normalmente mais documentação, acesso baseado em funções, testes de integração e planeamento do ciclo de vida do que uma habitação. O âmbito e o suporte devem ser acordados de forma explícita. Um edifício comercial necessita também de um responsável designado para o programa e para as cópias de segurança.
06Como se programa um sistema Loxone?
O comportamento é construído no Config a partir de blocos funcionais para entradas, saídas, lógica, horários, cenas e alarmes. Os bons projetos utilizam convenções de nomenclatura, blocos reutilizáveis, controlo de versões e testes de pontos no local antes da entrega. O programa deve ser tratado como um documento controlado que outro engenheiro possa ler e manter.
07O que acontece se o Miniserver falhar?
As funções desse controlador param até que este seja restaurado ou substituído. O projeto deve limitar o âmbito de cada controlador, manter cópias de segurança, dispor de hardware sobressalente e documentar o procedimento de restauro. As funções críticas não devem depender de um único dispositivo não documentado. A substituição deve ser possível sem reconstruir o programa de memória.
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.