Aplicação Loxone
Loxone App e acesso remoto — Controlo local, cloud opcional
Como funcionam o acesso local à aplicação e a conetividade remota num sistema Loxone, como conceber perfis e segurança, e o que continua a funcionar durante uma falha.
Resposta rápida
A aplicação liga-se ao Miniserver através da rede local e também pode ser acedida remotamente através de um serviço cloud ou de uma VPN do local. As programações e a lógica locais continuam a funcionar sem internet. O acesso remoto deve ser um caminho concebido, baseado em perfis e auditado, e não uma porta aberta, e a utilização da cloud deve ser uma escolha e não uma dependência.
Local em primeiro lugar, por conceção
O caminho normal é simples: a aplicação encontra o Miniserver na rede local, autentica o utilizador e lê ou escreve pontos. As programações, sequências e interbloqueios são executados no controlador, não na aplicação. É por isso que uma falha da ligação à internet não para o edifício; apenas interrompe a visibilidade e o controlo remotos. Este modelo local-first também mantém a latência baixa para o controlo de sala e reduz os dados que saem do local. A questão de projeto não é se a cloud é útil, mas que funções têm de continuar disponíveis quando ela não está. Registe por escrito quais as funções consideradas críticas, porque essa lista determina onde são necessários controlo local, alarmes independentes e alimentação de reserva, e que funções podem esperar em segurança.
- O controlo de sala funciona na rede local
- Programações e interbloqueios são executados no controlador
- O acesso remoto é um caminho adicional, não a base
Acesso remoto sem expor o edifício
O acesso remoto pode ser assegurado através do serviço cloud do fornecedor, de uma VPN site-to-site ou de um equipamento gerido de acesso remoto. Cada um tem uma fronteira de confiança diferente. Um relay cloud é conveniente, mas depende do fornecedor e da WAN; uma VPN dá mais controlo ao proprietário, mas exige competências de rede; um equipamento gerido pode combinar controlo de acesso, registo e suporte. Qualquer que seja o caminho escolhido, evite o encaminhamento direto de portas para o controlador. Aplique o menor privilégio, contas separadas, autenticação multifator na periferia da rede e um registo de quem alterou o quê. Documente o caminho escolhido no diagrama de rede, incluindo quem detém as credenciais e como o acesso é revogado quando um subcontratado ou membro da equipa sai.
- Escolha deliberadamente entre cloud, VPN ou acesso gerido
- Nunca exponha o controlador diretamente à internet
- Registe as sessões remotas que alteram setpoints
Perfis, vistas e notificações
Nem todos os utilizadores precisam do mesmo ecrã. Um operador precisa de alarmes, tendências e uma visão clara do edifício. Um técnico precisa de pontos, parâmetros e diagnóstico. Um residente ou inquilino precisa de cenas de sala e de um conjunto limitado de controlos. As vistas baseadas em perfis reduzem erros e facilitam a formação. As notificações devem seguir a mesma lógica: encaminhe os alarmes críticos para o perfil responsável, suprima repetições incómodas e torne a confirmação visível. Uma aplicação bem concebida não é uma cópia reduzida da ferramenta de engenharia; é uma vista do modelo operacional específica de cada perfil. Teste as vistas com utilizadores reais antes da entrega; uma página que parece arrumada no escritório pode ser ilegível num telefone dentro de uma sala técnica, e é aí que será utilizada.
- Separe as vistas de operador, técnico e inquilino
- Encaminhe os alarmes por responsabilidade, não por lista de dispositivos
- Torne visíveis a confirmação e a escalada
Lista de verificação de segurança e resiliência
Trate a rede de automação como uma zona separada da rede de escritório. Documente que portas e serviços estão expostos, mantenha o firmware atualizado, desative os serviços não utilizados e altere as credenciais predefinidas. Faça uma cópia de segurança do projeto antes de iniciar trabalhos remotos e registe cada sessão remota que altere um setpoint. Planeie o que acontece quando a WAN falha, quando o fornecedor de cloud tem uma interrupção e quando um utilizador deixa a organização. O acesso remoto é uma capacidade operacional, pelo que necessita de um responsável, de um ciclo de revisão e de um processo de saída, e não apenas de uma aplicação instalada num telefone. Reveja as contas remotas ao mesmo tempo que as listas de incêndio e de acessos, para que as chaves digitais do edifício não sobrevivam às pessoas que as detinham.
- Segmente a rede de automação
- Mantenha o firmware e as credenciais atualizados
- Defina um processo de saída para contas remotas
Imagens do projeto
3 images
Perguntas frequentes
01A aplicação funciona sem internet?
Na rede local, sim. O acesso remoto requer um caminho de rede; o controlo local do edifício continua independentemente, porque a lógica é executada no Miniserver.
02É necessária uma ligação à cloud?
Não. O acesso à cloud é uma conveniência e uma opção de monitorização. O controlo local e o ficheiro do projeto permanecem no local, o que é a base do modelo local-first.
03Os inquilinos podem ter o seu próprio acesso?
Sim, com contas baseadas em perfis limitadas às suas salas ou pisos. Mantenha as contas dos inquilinos separadas das contas de operação do edifício e reveja as permissões quando os arrendamentos mudarem.
04O que acontece durante uma falha da WAN?
A automação local continua. Os comandos remotos, os relatórios na cloud e os alarmes fora do local ficam indisponíveis até a conetividade regressar, pelo que os alarmes críticos necessitam de um caminho local ou independente.
05Como deve ser protegido o acesso remoto?
Utilize uma VPN ou um relay gerido, contas com o menor privilégio, autenticação multifator na periferia, atualizações de firmware e registo de sessões. Evite expor o controlador diretamente à internet.
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.