Loxone Config
Programação em Loxone Config — Estrutura, lógica e entrega
Como o Loxone Config está estruturado, como manter a lógica legível e testável, e o que entregar para que outro engenheiro possa manter o projeto.
Resposta rápida
O Config é o ambiente de engenharia onde o projeto do Miniserver é construído: salas, funções, entradas, saídas, lógica, programações e interfaces de utilizador. Uma boa programação é estruturada, nomeada e documentada, para que outro engenheiro a possa ler. Não se trata de escrever blocos engenhosos; trata-se de tornar o comportamento do edifício visível, testável e seguro de alterar.
O projeto é um modelo do edifício
O Config organiza o trabalho por sala e função, não por uma lista plana de terminais. Uma sala contém as suas luzes, estores, clima e sensores; uma função descreve o que a sala faz. Essa estrutura é a diferença entre um projeto que pode ser mantido e um conjunto de blocos que por acaso funciona. Nomeie os pontos na perspetiva do edifício, utilize prefixos consistentes e mantenha a hierarquia de salas e funções alinhada com a lista de pontos. Quando a nomenclatura se desvia, todas as tarefas seguintes ficam mais lentas: alarmes, tendências, gráficos, entrega e diagnóstico dependem todos dos mesmos nomes. Uma verificação útil é entregar a árvore do projeto a alguém que nunca viu o local e pedir-lhe que encontre a sala de reuniões do terceiro piso sem usar a pesquisa.
- Espelhe a lista de salas na árvore do projeto
- Utilize uma única convenção de nomenclatura desde o primeiro dia
- Mantenha gráficos e alarmes nos mesmos nomes
Lógica em camadas
Coloque o comportamento simples junto do dispositivo: uma luz segue o seu interruptor, uma válvula segue o setpoint da sua sala. Coloque o comportamento entre salas e entre sistemas numa camada de edifício claramente identificada. Coloque os relatórios e a otimização acima dessa camada. Esta divisão impede que uma pequena alteração numa sala se propague por todo o projeto e torna possível testar por partes. Utilize máquinas de estados para sequências com estados distintos, em vez de um emaranhado de condições que só o autor compreende. Documente cada bloco não óbvio com uma nota breve: o que faz, o que o aciona e o que acontece em caso de falha do sensor. Se um bloco precisa de um parágrafo para ser explicado, esse parágrafo pertence às notas do projeto junto ao bloco, e não a um documento separado que ninguém abre.
- A lógica de dispositivo, sala e edifício mantém-se separada
- Utilize máquinas de estados para sequências de várias etapas
- Comente todos os blocos não óbvios
Evidência de teste, não confiança
Um projeto não está concluído quando a aplicação parece correta. Teste as entradas uma a uma, force falhas de sensores, verifique o encaminhamento de alarmes, valide as programações em diferentes tipos de dia e confirme que as sobreposições expiram. Registe o resultado na lista de pontos, e não na memória de alguém. Teste o caminho de falha: o que acontece quando um dispositivo de barramento desaparece, um contador deixa de responder ou a rede cai. Uma folha de teste escrita e breve é mais valiosa do que uma longa demonstração, porque sobrevive a mudanças de pessoal e torna a visita de assistência seguinte mais barata. Inclua também o caminho humano: o operador sabe o que fazer quando surge um alarme às 02:00, e essa instrução está no dossiê de entrega e não apenas na cabeça do instalador?
- Teste todas as entradas e saídas face à lista de pontos
- Provogue falhas e registe o estado resultante
- Valide programações, sobreposições e encaminhamento de alarmes
Entrega e controlo de alterações
Entregue o ficheiro do projeto, a versão do software, a cópia de segurança, o diagrama de rede, a lista de pontos e um registo de alterações. Proteja o projeto com credenciais controladas pelo proprietário, e não com credenciais que saem com o instalador. Acorde a forma como as alterações serão pedidas, testadas e registadas. Uma pequena alteração a uma programação não deve exigir uma visita ao local se o acesso remoto e as permissões forem bem concebidos. A medida de uma boa configuração não é a quantidade de lógica escrita; é a confiança com que a equipa do proprietário consegue operar e modificar o edifício depois de os engenheiros saírem. Um projeto que não pode ser restaurado, explicado e alterado por outra pessoa não foi realmente entregue; foi apenas ligado.
- Credenciais e licenças controladas pelo proprietário
- Um processo escrito de pedido e teste de alterações
- Um teste de restauro antes da entrega final
Camadas de programação
5 rows| Camada | O que contém | Evidência de teste |
|---|---|---|
| Dispositivo | Entradas, saídas e comportamento local seguro em caso de falha | Teste de entradas e saídas ponto a ponto |
| Sala | Iluminação, estores, clima e cenas de sala | Teste de cenas de sala e setpoints |
| Edifício | Programações, interbloqueios, alarmes e lógica de energia | Teste de sequências, alarmes e comutação por falha |
| Interface de utilizador | Páginas da aplicação, controlos tácteis e vistas por perfil | Verificação de acessos por perfil e de usabilidade |
| Entrega | Cópias de segurança, versões, notas e registo de alterações | Teste de restauro e revisão do as-built |
Imagens do projeto
3 images
Perguntas frequentes
01O Config é programação ou configuração?
Ambos. É um ambiente gráfico, mas o trabalho é de engenharia: estrutura, lógica, nomenclatura e testes. A distinção importa menos do que saber se o resultado é legível e fácil de manter.
02É necessário escrever código?
A maioria dos projetos é construída com blocos de função nativos. A lógica personalizada está disponível para sequências especiais, mas deve ser documentada e justificada, porque aumenta as competências necessárias para manter o local.
03Outro integrador pode manter o projeto?
Sim, se o ficheiro do projeto, a convenção de nomenclatura, as notas e as credenciais forem entregues corretamente. Isso deve ser uma exigência contratual e não um favor após a conclusão.
04Com que frequência devem ser feitas cópias de segurança?
Antes e depois de cada alteração, e na entrega. Guarde uma cópia fora do controlador e teste o restauro. Uma cópia de segurança não testada é apenas uma esperança.
05A aplicação pode ser personalizada por utilizador?
Sim. As páginas e permissões de utilizador podem ser estruturadas por perfil, para que operadores, técnicos e residentes vejam níveis de detalhe e controlos diferentes.
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.