Como escolher um servidor de supervisão KNX

Todos os projetos KNX chegam à mesma encruzilhada. O bus está projetado, os dispositivos estão escolhidos e depois alguém tem de decidir o que fica por cima: aquilo que transforma um conjunto de endereços de grupo em algo que um cliente consegue realmente operar. Se errar nessa decisão, só o descobre dois anos depois, quando o cliente pede algo que a plataforma não consegue fazer.

O que se segue são as perguntas que vale a pena fazer antes de se comprometer, pela ordem em que costumam passar a ser importantes. Nenhuma delas tem uma resposta universalmente certa — têm uma resposta que é a certa para o projeto que tem à sua frente.

1. O que fala nativamente e o que precisa de um gateway?

Quase todas as plataformas afirmam suportar vários protocolos. A distinção que importa é se um protocolo está integrado no servidor ou se é alcançado através de uma interface externa que é preciso comprar, montar, alimentar e manter.

Pergunte especificamente por Modbus e BACnet. Um servidor com gateways KNX, Modbus e BACnet integrados não custa nada a mais em espaço no quadro; um que precise de uma interface separada por protocolo acrescenta hardware, uma fonte de alimentação e mais um ponto que pode avariar. Pergunte também se o servidor pode atuar como slave Modbus e não apenas como master — vai precisar disso no dia em que um empreiteiro geral quiser expor o edifício ao seu BMS.

2. Como é licenciado?

É aqui que os projetos ficam caros sem darem por isso. Algumas plataformas licenciam por endereço de grupo, por utilizador, por instalação da app, por dispositivo ligado ou por ano. Cada um destes é um número que cresce depois de o orçamento ser assinado.

Calcule o total de um projeto real, não o preço de entrada: uma moradia com 400 endereços, seis membros da família, quatro tablets e o telemóvel do caseiro dá um valor diferente num modelo por endereço e num modelo fixo. E verifique se as notificações push são contabilizadas, porque os eventos de alarme e de porta geram muitas.

3. Calha DIN ou de parede?

Um servidor em calha DIN vive no quadro e fica fora de vista: adequa-se a projetos complexos, a vários subsistemas e a tudo onde o quadro seja o centro de gravidade natural. Uma unidade de parede que combina servidor e interface tátil elimina um equipamento e um ponto de falha, o que convém a projetos residenciais que querem um único ponto de controlo de topo de gama.

A questão não é qual é melhor, mas onde está o centro do projeto. Uma moradia com uma sala principal e um quadro pequeno tem uma forma diferente de um edifício de escritórios de cinco pisos com três prumadas.

4. O que acontece quando a internet falha?

Pergunte onde corre realmente a lógica. Se o servidor está no local e a app comunica com ele através da rede local, uma falha de internet custa-lhe o acesso remoto e mais nada — o edifício continua a funcionar. Se os cenários, os horários ou o controlo por voz dependem de uma ida e volta à cloud, uma falha no fornecedor transforma-se numa falha em casa do seu cliente, e é a si que ligam.

Faça também a pergunta seguinte: que funcionalidades, em concreto, exigem a cloud. O vídeo remoto de câmaras e intercomunicadores normalmente exige, por razões de largura de banda, e isso é razoável. Acender uma luz não deveria exigir.

5. Como voltar a entrar após a entrega?

Vai precisar de alterar algo remotamente. Descubra se a programação remota por ETS é possível, como é protegida e se exige redirecionamento de portas no router do cliente — porque o departamento informático do cliente, ou um CGNAT, acabará por tornar o redirecionamento de portas impossível.

Um gateway VPN fornecido pelo fabricante evita essa conversa por completo. Pergunte se está incluído ou se é um módulo pago, e o que acontece se deixar de pagar.

6. Quem o configura e quanto tempo demora a aprender?

A ferramenta de configuração é onde está a sua margem. Uma plataforma que demora três dias a aprender e quatro horas a pôr em serviço é melhor do que uma que demora uma tarde a aprender e três dias a pôr em serviço, sempre, a partir do segundo projeto.

Peça uma licença de teste e construa um pequeno projeto real antes de a especificar numa obra. Analise em particular como se desenha a visualização: se está a compor os ecrãs à mão para cada divisão, ou se a estrutura vem do projeto ETS e você a vai refinando.

7. Faz alguma coisa com os dados de energia ou limita-se a mostrá-los?

A contagem tornou-se padrão e a maioria das plataformas desenha-lhe um gráfico. A pergunta útil é o que acontece a seguir. O sistema consegue converter quilowatts-hora em moeda local para que o cliente perceba o valor? Consegue desligar cargas não críticas antes de o disjuntor geral disparar? Consegue exportar os dados registados para a faturação de inquilinos ou para uma auditoria energética?

Um gráfico é uma funcionalidade. A gestão de cargas que evita um apagão é um motivo para o cliente o recomendar.

8. Como é o suporte numa sexta-feira à tarde?

O teste honesto de um fabricante não é a datasheet, é o que acontece quando está em obra, o cliente está a ver e algo não funciona. Descubra se fala com um engenheiro ou com uma fila de tickets, se existe um número de telefone e se a documentação existe numa língua que a sua equipa lê.

Pergunte aos outros instaladores do fabricante em vez de perguntar ao fabricante. Num evento do setor KNX obtém uma resposta direta em trinta segundos.

9. Durante quanto tempo este hardware será suportado?

As instalações KNX sobrevivem à maioria da eletrónica de consumo. Pergunte há quanto tempo está a ser comercializada a geração atual, como é a cadência de atualizações e o que aconteceu à geração anterior quando esta foi lançada. Uma plataforma que abandona o hardware de quatro em quatro anos é uma plataforma que o fará revender um projeto que já vendeu.

No final não há nenhuma grelha de pontuação. O ponto é que a decisão sobre a plataforma é tanto uma decisão comercial como técnica: define o seu tempo de colocação em serviço, a sua margem, a sua exposição quando algo avaria e aquilo a que poderá dizer que sim daqui a três anos.

Se quiser testar estas perguntas num projeto concreto, envie-nos a lista de dispositivos e os subsistemas — diremos o que precisa, incluindo quando a resposta for que precisa de outra coisa.