ECHONET Lite

ECHONET Lite é uma especificação de comunicação criada pelo ECHONET Consortium para permitir que eletrodomésticos, equipamentos residenciais, sistemas de energia e controladores HEMS interajam por uma linguagem comum. O protocolo modela cada função como um objeto de equipamento. Um nó pode conter um objeto de perfil e vários objetos, como ar-condicionado, aquecedor de água por bomba de calor, iluminação, medidor de energia, inversor fotovoltaico, bateria, carregador de veículo elétrico ou sensor. Cada objeto expõe propriedades identificadas por EPC, ECHONET Property Code. As operações são expressas por ESV, ECHONET Service. O controlador pode solicitar leitura, escrever valores, receber notificações e confirmar. A mensagem inclui cabeçalho EHD, identificador de transação TID, objeto de origem SEOJ, objeto de destino DEOJ, serviço ESV, quantidade de propriedades OPC e blocos com EPC, tamanho PDC e dados EDT. Essa estrutura compacta permite operar em dispositivos com recursos limitados. O modelo de objetos é a parte central. Em vez de cada fabricante inventar um JSON diferente para temperatura, energia ou modo, o APPENDIX Detailed Requirements for ECHONET Device Objects define classes, propriedades, códigos, formatos, unidades, valores e requisitos. Um ar-condicionado pode expor estado de operação, modo, temperatura alvo, temperatura ambiente, velocidade do ventilador e outras funções. Um medidor inteligente possui propriedades de energia acumulada, potência instantânea, corrente e histórico conforme perfis e especificações de interface. A interoperabilidade depende não apenas do protocolo básico, mas do Application Communication Interface Specification, AIF, aplicável à classe. AIFs definem combinações obrigatórias e sequências entre equipamento e HEMS. Isso reduz a situação em que dois produtos “falam ECHONET Lite” mas não compartilham as mesmas propriedades. O ECHONET Consortium mantém certificação de conformidade da especificação e de AIF. O comprador deve verificar o modelo e a classe. ECHONET Lite foi recomendado em 2012 como interface pública para HEMS por um grupo de padronização de casas inteligentes do Ministério da Economia, Comércio e Indústria do Japão. A adoção se consolidou em medidores inteligentes e equipamentos de energia. A especificação inglesa 1.14, datada de 30 de setembro de 2022, contém visão geral, middleware, equipamentos e gateways. O catálogo APPENDIX continua recebendo releases e revisões; em novembro de 2025, o Consortium publicou versão inglesa do Release R rev.3. A versão do APPENDIX importa porque novas classes e propriedades aparecem. O protocolo pode operar sobre diferentes camadas inferiores. O uso mais comum em IP emprega UDP/IPv4 ou IPv6 e a porta 3610. Descoberta e comunicação podem usar multicast ou endereços conhecidos, conforme a especificação. O ECHONET Lite frame é independente de uma marca. Em redes não IP, adaptadores e gateways podem mapear. O controlador HEMS descobre nós, consulta o objeto de perfil para obter a lista de instâncias, lê property maps e passa a interagir. Property maps indicam quais EPCs aceitam GET, SET ou notificações. Essa etapa evita tentar operações inexistentes. Um erro comum é assumir que toda propriedade listada no APPENDIX está implementada em todo produto. A classe define possibilidades; o mapa e o AIF definem o que existe e o que é obrigatório. O controlador deve ler e adaptar. Outro erro é interpretar bytes sem escala. Os formatos podem usar inteiros com sinal, valores especiais de erro e unidades definidas. O software precisa validar. ECHONET Lite suporta notificações espontâneas. Um equipamento pode informar mudança de estado sem polling contínuo. Entretanto, propriedades e condições de notificação variam. O controlador deve reconciliar com leituras periódicas. UDP não garante entrega. Uma notificação pode se perder. Para estado crítico, fazer GET. O TID ajuda correlacionar pedido e resposta. Repetições precisam ser controladas. Um SET pode ser processado e a resposta perdida. O cliente deve ler o estado antes de repetir cegamente. O protocolo básico histórico não foi desenhado com criptografia e autenticação fim a fim obrigatórias equivalentes a Matter. A segurança depende da rede, do produto e de especificações adicionais. O Consortium desenvolve funções de autenticação de dispositivo e, em outubro de 2025, anunciou grupo para estruturar certificação de função de segurança DA. Isso mostra evolução, mas a implantação precisa verificar suporte real. Em uma LAN, qualquer host capaz de enviar pacotes pode tentar ler ou comandar se o dispositivo não autentica. VLAN, firewall e gateway são essenciais. O HEMS deve ser o único controlador autorizado. A porta 3610 não deve ser exposta à Internet. Acesso remoto passa por serviço autenticado. A integração com Matter é um tema recente. O Consortium publica exemplos de aplicação para Matter–ECHONET Lite Bridge. Uma bridge traduz dispositivos e propriedades ECHONET para clusters Matter. A tradução pode perder funções específicas, especialmente energia e equipamentos japoneses. O bridge deve declarar. Matter oferece commissioning seguro, fabric e multi-admin; ECHONET possui catálogo maduro de energia. Eles podem coexistir. O protocolo não substitui certificação elétrica, de rádio ou metrológica. Um medidor ECHONET não é fiscal automaticamente. AIF do medidor e aprovação local importam. No Brasil, a adoção é limitada e produtos japoneses podem usar faixas, tensão, plugues e serviços incompatíveis. O integrador precisa verificar. Para uma residência com sistema fotovoltaico japonês, bateria e aquecedor, ECHONET Lite pode fornecer integração profunda sem APIs proprietárias. Para mercado ocidental genérico, Matter, Modbus, KNX ou APIs de fabricante podem ter mais suporte. A decisão deve considerar disponibilidade de equipamentos, documentação em inglês, certificação, gateway e manutenção. A força do ECHONET Lite é a semântica padronizada de objetos. A limitação é ecossistema regional e complexidade do catálogo. Um gateway genérico precisa conhecer centenas de classes e versões. O sistema deve versionar. Logs precisam mostrar SEOJ, DEOJ, ESV, EPC e TID para diagnóstico. Wireshark pode decodificar com dissector. Um pacote recebido não prova que a ação física ocorreu; ler a propriedade. O controlador deve tratar `SNA`, Service Not Available, quando operação falha. Um ESV de resposta negativa informa. Não transformar em zero. O software deve conservar estado anterior e marcar indisponível. A confiabilidade do sistema requer timeout, retries limitados, backoff e detecção de reinício. O objeto de perfil ajuda atualizar inventário. A certificação reduz variação, mas testes multi-vendor continuam. Plugfests do Consortium ajudam. A integração deve usar a versão oficial japonesa como referência em caso de divergência da tradução, conforme aviso dos documentos. Isso é relevante para fabricantes. O usuário final vê apenas equipamentos no HEMS; a precisão do modelo determina se funções aparecem corretamente.