Controle MQTT ao vivo

dica

O controle MQTT ao vivo é destinado ao controle ao vivo. Para enviar programações com antecedência, veja Controle MQTT Programado em vez disso.

Este guia o ajudará a configurar o MQTT em seu SmartgridOne Controller para controlar e monitorar remotamente instalações de baterias e painéis solares.

O que você precisa

1. SmartgridOne Controller com conectividade à internet.
2. Credenciais MQTT: Isso pode ser solicitado enviando um e-mail para support@eniris.be.
3. Ambiente de desenvolvimento Python (ou qualquer outro cliente MQTT). Este guia utiliza um exemplo básico escrito em Python para ajudá-lo a começar com o MQTT e o envio de comandos. Recomendamos usar Python pela facilidade de uso, mas qualquer outro cliente MQTT é suportado.

Informações extras

MQTT é um protocolo de comunicação rápido pela internet. É um sistema de mensagens de publicar/assinar, que permite uma conexão direta entre sua máquina e o SmartgridOne Controller. Seus ativos são classificados em grupos de solar, bateria, EV e HVAC.

Configuração inicial (Ponto de partida para novos usuários)

Eu tenho um SmartgridOne Controller que gostaria de configurar para Controle Remoto MQTT.

1. Verifique sua rede

Certifique-se de que sua rede permite tráfego de rede mqtt pela porta 1883. Você pode fazer isso utilizando o comando:

nc -zv mqtt.eniris.be 1883

Quando este comando não estiver disponível, você pode alternativamente baixar e executar este código python.

Em caso de dúvida, consulte seu engenheiro de rede ou use temporariamente o ponto de acesso 4G/5G do seu celular quando ocorrerem erros de conexão.

nota

Quando a porta 1883 não estiver acessível a partir de sua rede, oferecemos uma alternativa na porta 80. Isso pode ser configurado em seu cliente MQTT em uma etapa posterior deste manual.

2. Adicione seus dispositivos

Faca login na interface de comissionamento e certifique-se de que os dispositivos estão adicionados ao SmartgridOne Controller.

3. Adicione o sinal externo MQTT

4. Habilitar sinal remoto MQTT

O campo 'VPP ID' deve ser deixado em branco.

O tempo limite do mecanismo de fallback informa ao SmartgridOne Controller quanto tempo ele deve esperar por novos comandos. Quando o SmartgridOne Controller para de receber comandos, ele automaticamente adota a estratégia padrão após esse tempo limite.

Depois, selecione todos os dispositivos que você deseja incluir no Controle Remoto MQTT.

5. Sinal remoto adicionado

A interface de Controle Remoto MQTT agora foi ativada no SmartgridOne Controller.

Estamos agora prontos para enviar alguns comandos básicos usando um exemplo simples. A coluna Status informa se algum comando está ativo.

Script de demonstração em Python

Um bom ponto de partida seria testar sua nova integração configurada com um exemplo simples.

Este código de teste faz um trabalho simples de enviar continuamente os seguintes comandos:

• Bateria: Carregar a 5 kW
• Solar: Definir potência para 0 kW

O SmartgridOne Controller responde continuamente com uma mensagem de 'feedback' contendo os valores de potência da grade e dos ativos observados. Este recurso também está incluído neste exemplo.

Por favor, baixe o arquivo abaixo em seu IDE de Python preferido. Preencha seu número de série e credenciais MQTT e execute o script:

Quando o acima for bem-sucedido, você pode continuar enviando outros tipos de comandos. Todos os comandos estão descritos em nossa Documentação de Controle Remoto MQTT.

Documentação MQTT para Envio de Comandos

Esta seção detalha o formato de mensagem MQTT e os requisitos de carga útil para controlar remotamente políticas de energia em dispositivos dentro da rede do SmartgridOne Controller.

Tópico MQTT

O tópico MQTT usado para enviar comandos está estruturado da seguinte forma:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Onde 'controller SN' deve ser substituído pelo número de série real do SmartgridOne Controller que você pretende controlar.

Estrutura da Carga Útil MQTT

Os comandos são enviados como cargas úteis JSON. A estrutura da carga útil é projetada para especificar várias políticas de gerenciamento de energia e pontos de ajuste para diferentes componentes do sistema de rede inteligente. Aqui está o esboço da carga útil com descrições detalhadas dos campos:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint em watts>
    }
}

Descrição dos Campos

dica

Vários tipos de dispositivos (por exemplo, baterias + sol) podem ser controlados ao mesmo tempo.

• extraTags (Objeto):
  • nodeId (String): Um identificador exclusivo para o nó dentro da rede do SmartgridOne Controller. Isso é igual ao seu número de série, seguido de '_site_0' para a maioria dos dispositivos SmartgridOne Controller.
• time (Inteiro): Timestamp Unix em segundos indicando o momento em que a mensagem é enviada.
• fields (Objeto):
  • <Component>_policy (String): Tipo de política para o componente. É opcional e, se não especificado, o sistema usará a configuração padrão do SmartgridOne Controller.
  • <Component>_power_setpoint_w (Float): Ponto de ajuste de potência desejado em watts para o componente. Isso é opcional e só é relevante se uma política correspondente for especificada.

Componentes e Políticas

info

Ativos do mesmo tipo (por exemplo, duas baterias) serão combinados como um único componente. Por exemplo, quando duas baterias de 5 kWh estão instaladas, serão tratadas como uma bateria de 10 kWh.

Cada componente no objeto fields pode incluir uma política e um ponto de ajuste de potência. Os seguintes componentes podem ser controlados:

• solar_policy e solar_power_setpoint_w:

  • Controla a política e o ponto de ajuste da geração de energia solar. Políticas suportadas:
    • Ponto de ajuste de política: Definir a potência máxima produzida por todas as instalações solares conectadas combinadas. O campo solar_power_setpoint_w deve ser definido para o limite de potência de produção em watts.
    • Restrição de alimentação de política: Produzir em plena potência, seguindo os limites atuais da rede.
    • Política de custo: Habilita a minimização de custos de preços com um dia de antecedência (mercado EPEX Spot) na produção solar. Quando ocorrem preços de injeção negativos, reduzimos a produção para o consumo próprio. Quando tanto o preço de retirada quanto o preço de injeção são negativos, desligamos todas as instalações solares. O campo solar_power_setpoint_w é ignorado.
    • Política desligada: Desabilita toda interação para todos os ativos solares. Aviso: limites não estão sendo guardados nesse modo. O campo solar_power_setpoint_w é ignorado.

• storage_policy e storage_power_setpoint_w:

• Controla a política do sistema de armazenamento de energia e a taxa de descarga ou carga de energia.

  • Ponto de ajuste da política: Define a potência total de carga (ponto de ajuste positivo) ou potência de descarga (ponto de ajuste negativo) para o grupo de baterias. Quando múltiplas baterias estão conectadas, o ponto de ajuste é dividido pela potência de carga/descarga disponível para estressar igualmente as baterias. O campo storage_power_setpoint_w é configurado para a potência desejada da bateria.
  • Custo da política: Habilita a otimização de custo do preço de um dia à frente (mercado EPEX Spot) nas baterias, carregando-as durante as horas baratas e usando a energia nas horas caras. O campo storage_power_setpoint_w é ignorado.
  • Autoconsumo da política: Habilita um algoritmo simples de autoconsumo nas baterias. O excesso de produção solar é armazenado na bateria durante o dia, e quando o sol se põe, a energia é retirada da bateria. O campo storage_power_setpoint_w é ignorado.
  • Política desligada: Desabilita toda interação para todos os ativos de bateria. Aviso: limites não estão sendo controlados nesse modo. O campo storage_power_setpoint_w é ignorado.

• heat_pump_policy:

  • Ativa/desativa sistemas de bomba de calor. Os tempos mínimos e máximos de ativação sempre serão respeitados.
    • Custo da política: Habilita a otimização de custo do preço de um dia à frente (mercado EPEX Spot) nas bombas de calor. O algoritmo de precificação dinâmica local decide os melhores períodos de ativação.
    • Autoconsumo da política: Liga as bombas de calor se um excesso de energia solar for produzido.
    • Política desligada: Desliga as bombas de calor.
    • Política ligada: Liga as bombas de calor.

• switched_load_policy:

  • Ativa/desativa sistemas controlados por relé. Isso pode ser o relé embutido ou relés conectados à rede.
    • Custo da política: Habilita a otimização de custo do preço de um dia à frente (mercado EPEX Spot) no relé.
    • Autoconsumo da política: Liga o relé se um excesso de energia solar for produzido.
    • Política desligada.
    • Política ligada.

• variable_power_load_policy e variable_power_load_power_setpoint_w:

  • Gerencia a política de consumo de energia do veículo elétrico e o ponto de ajuste.
    • Ponto de ajuste da política: Define a potência total de carga para o grupo de VEs. O campo variable_power_load_power_setpoint_w é configurado para a potência de carga desejada.
    • Custo da política: Habilita a otimização de custo do preço de um dia à frente (mercado EPEX Spot) nas baterias, carregando durante as horas baratas. O campo variable_power_load_power_setpoint_w é ignorado.
    • Autoconsumo da política: Habilita a carga se um excesso de energia solar for produzido. O campo variable_power_load_power_setpoint_w é ignorado.
    • Política desligada: Desabilita toda interação para todos os ativos de VE. O campo variable_power_load_power_setpoint_w é ignorado.

• site_policy e site_power_setpoint_w:

  • Gerencia os limites de exportação do site.
    • Exportação da política: Define o limite de exportação para o site. O campo site_power_setpoint_w é configurado para o limite de exportação.
    • Padrão da política: Reverte o limite do site para a potência de exportação padrão, configurada na configuração do controlador.

Controle de Dispositivo

Dispositivos específicos também podem ser controlados, em vez de grupos de dispositivos com base em seus tipos. A mensagem tem uma estrutura idêntica:

• nodeId_policy e nodeId_power_setpoint_w

info

Quando dois comandos são enviados para o mesmo ativo (por exemplo, um comando específico para um inversor solar e um comando para todos os dispositivos solares), o método de controle específico do dispositivo terá preferência sobre o controle por tipo de dispositivo.

Comportamento de fallback

Para cada componente, se a _policy e _power_setpoint_w não forem especificados, o sistema usará automaticamente a política de fallback configurada no SmartgridOne Controller. Isso garante que cada dispositivo ou grupo de dispositivos opere de maneira segura e continue a funcionar mesmo se instruções específicas não forem fornecidas.

Se nenhum comando for enviado, após 60 segundos (ou o período de tempo configurado), as políticas padrão para os ativos serão reativadas.

Cancelar comandos existentes e retornar aos modos de controle locais

Um comando ativo pode ser cancelado enviando uma mensagem de comando de fallback.

Comando de Fallback

Um comando de fallback cancelará o comando existente imediatamente e o SmartgridOne Controller assumirá o controle da instalação. A política executada depende do que está configurado nas Configurações do SmartgridOne Controller.

Isso também pode ser usado em casos em que um sinal de controle secundário, como um cronograma, é utilizado como fallback.

Exemplos de mensagens:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "fallback",
    }
}

Comando Vazio

Um comando vazio pode ser enviado a qualquer momento para coletar informações do site. Isso não cancelará o comando atual, e não substituirá comandos de sinais de controle secundários com prioridades mais baixas.

O comando vazio é estruturado da seguinte forma:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {}
}

Exemplo de carga útil

Abaixo está um exemplo de uma carga útil para definir várias políticas e pontos de ajuste:

{
    "extraTags": {
        "nodeId": "OM12404080000000000_site_0"
    },
    "time": 1714652046,
    "fields": {
        "solar_policy": "setpoint",
        "solar_power_setpoint_w": 5000,
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": -5000
    }
}

Neste exemplo, a potência solar é configurada para gerar até 5000 watts, e o sistema de armazenamento de energia é configurado para carregar ou descarregar a uma taxa de 5000 watts, dependendo do sinal do valor do ponto de ajuste. Se a solar_policy ou a storage_policy forem omitidas, o respectivo dispositivo reverterá para as configurações padrão determinadas pelo SmartgridOne Controller.

Documentação MQTT para Receber Feedback

Esta seção descreve a estrutura e o conteúdo das mensagens de feedback enviadas pelo SmartgridOne Controller via MQTT. Essas mensagens são publicadas no tópico standard1/outbound/remoteControlMetrics/feedback/<Controller SN> após um comando ter sido processado.

Tópico de Feedback MQTT

O tópico de feedback MQTT é estruturado da seguinte forma:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Onde <Controller SN> deve ser substituído pelo número de série do SmartgridOne Controller que está enviando o feedback.

Estrutura da Carga Útil de Feedback MQTT

nota

Todos os ativos são agrupados por seu tipo. Isso significa que duas instalações solares individuais de 3 kW serão tratadas como um ativo de 6 kW.

As mensagens de feedback são formatadas como cargas úteis JSON. Essas cargas úteis fornecem feedback detalhado sobre o estado do sistema após a aplicação dos comandos de ponto de ajuste, considerando os limites da rede/dispositivo. Abaixo está a estrutura da carga útil de feedback com descrições de seus campos:

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Grid Active Power in Watts>,
                "today_imported_energy_Wh": <Grid Imported Energy in Watt-hours>,
                "today_exported_energy_Wh": <Grid Exported Energy in Watt-hours>,
                "import_limit_W": <Grid Import Limit in Watts>,
                "export_limit_W": <Grid Export Limit in Watts>,
            },
            "vpp_id": "<Identificador da Usina de Energia Virtual>",
            "storage": {
```json
{
    "energy_stored_Wh": <Energia Armazenada em Watt-horas>,
    "energy_capacity_Wh": <Capacidade Total de Energia em Watt-horas>,
    "mean_soc_perc": <Média de Percentagem do Estado de Carga>,
    "active_power_W": <Potência Ativa em Watts>,
    "executed_power_W": <Ponto de Potência Enviado para os Dispositivos em Watts>,
    "executed_policy": <Política Executada pelo Controlador>,
    "max_charge_power_W": <Potência Máxima de Carga em Watts>,
    "max_discharge_power_W": <Potência Máxima de Descarga em Watts>,
    "today_charged_Wh": <Energia Carregada no Dia de Hoje em Watt-horas>,
    "today_discharged_Wh": <Energia Descarregada no Dia de Hoje em Watt-horas>,
    "nr_devices": <Número de Dispositivos de Armazenamento Controlados Instalados>
},
"solar": {
    "active_power_W": <Potência Solar Ativa em Watts>,
    "executed_power_W": <Ponto de Potência Enviado para os Dispositivos em Watts>,
    "executed_policy": <Política Executada pelo Controlador>,
    "capacity_W": <Capacidade Solar em Watts>,
    "today_energy_Wh": <Energia Produzida Hoje em Watt-horas>,
    "nr_devices": <Número de Dispositivos Solares Controlados Instalados>
},
"heat_pump": {
    "executed_policy": <Política Executada pelo Controlador>,
    "operation_modes": <Modos de Operação da Bomba de Calor>,
    "executed_power_W": <Ponto de Potência Enviado para os Dispositivos em Watts>,
    "nr_devices": <Número de Dispositivos de Bomba de Calor Controlados Instalados>
},
"switched_load": {
    "executed_policy": <Política Executada pelo Controlador>,
    "devices_on": <Número de Dispositivos Ligados>,
    "devices_off": <Número de Dispositivos Desligados>,
    "executed_power_W": <Ponto de Potência Enviado para os Dispositivos em Watts>,
    "nr_devices": <Número de Dispositivos de Carga Alternada Controlados Instalados>
},
"variable_load": {
    "executed_policy": <Política Executada pelo Controlador>,
    "executed_power_W": <Ponto de Potência Enviado para os Dispositivos em Watts>,
    "active_power_W": <Potência do dispositivo em Watts>,
    "ev_requiring_charge": <O EV requer carga>,
    "currentL1_A": <Corrente do dispositivo na fase 1 em Ampere>,
    "currentL2_A": <Corrente do dispositivo na fase 2 em Ampere>,
    "currentL3_A": <Corrente do dispositivo na fase 3 em Ampere>,
    "executed_current_A": <Ponto de Corrente Enviado para os Dispositivos em Ampere>,
    "today_charged_Wh": <Energia Carregada Hoje em Watt-horas>,
    "today_discharged_Wh": <Energia Descarregada Hoje em Watt-horas>,
    "total_charged_Wh": <Energia Total Carregada em Watt-horas>,
    "total_discharged_Wh": <Energia Total Descarregada em Watt-horas>,
    "min_charge_current_A": <Carga Mínima em Ampere>,
    "max_charge_current_A": <Carga Máxima em Ampere>,
    "allow_zero_current": <O Carregador Suporta Pausar>
},
"response_code": <Código de Resposta>
},
"fields": {},
"requestTime": "<Timestamp Unix>",
"time": "<Timestamp Unix>",
"siteNodeId": "<Controlador SN>_site_0"
}

• executed_policy (Str): As políticas que foram aplicadas aos controláveis,
• executed_power_W (Float): A soma da potência total solicitada dos ativos, sendo enviada pelo nosso algoritmo de controle.
• active_power_W (Float): Representa a potência ativa atual na rede em watts.
• ev_requiring_charge (Bool): O EV requer carga. (Um carro está conectado).
• currentL1_A (Float): Corrente do dispositivo na fase 1 em Ampere.
• currentL2_A (Float): Corrente do dispositivo na fase 2 em Ampere.
• currentL3_A (Float): Corrente do dispositivo na fase 3 em Ampere.
• executed_current_A (Float): A soma da corrente total solicitada dos ativos, sendo enviada pelo nosso algoritmo de controle.
• today_charged_Wh (Float): A energia carregada para o(s) ativo(s) carregador(es) de EV hoje. Nota: Hoje é dado em horário UTC.
• today_discharged_Wh (Float): A energia descarregada do(s) ativo(s) carregador(es) de EV hoje. Nota: Hoje é dado em horário UTC.
• total_charged_Wh (Float): A energia total carregada para o(s) ativo(s) carregador(es) de EV.
• total_discharged_Wh (Float): A energia total descarregada do(s) ativo(s) carregador(es) de EV.
• min_charge_current_A (Float): Corrente mínima na qual o EV pode ser carregado.
• max_charge_current_A (Float): Corrente máxima na qual o EV pode ser carregado.
• allow_zero_current (Bool): O carregador de EV permite pausar.
• nodeId (Object):
  • Se um nodeId for incluído no comando, o feedback conterá o estado correspondente do dispositivo.
• response_code (Int):
  • Indica o status da operação. Um response_code de 0 normalmente significa sucesso, enquanto outros valores podem indicar diferentes tipos de erros ou informações de status (esses devem ser detalhados em uma referência separada).

Exemplo de Payload de Feedback

Aqui está um exemplo de uma mensagem de feedback após um comando para definir vários pontos de configuração de potência:

Este feedback demonstra o estado operacional atual do sistema após a execução dos pontos de configuração, indicando os efeitos na geração solar, armazenamento e interação geral com a rede.

Versões e Comportamento MQTT Suportados em Tópicos Não Autorizados

Ao usar MQTT, é importante considerar as diferenças nas especificações entre as versões 3.1, 3.1.1 e 5.0, particularmente em relação ao comportamento do broker quando os clientes publicam em tópicos não autorizados.

De acordo com a especificação MQTT 3.1.1 (veja a Especificação OASIS MQTT 3.1.1, seção MQTT-3.3.5-2), um broker deve encerrar a conexão assim que um cliente enviar um PUBLISH para um tópico para o qual não tem permissão. Esse comportamento pode levar a desconexões inesperadas para clientes que tentam publicar em tópicos mal configurados ou não autorizados.

Na MQTT 3.1, esse requisito não está presente. Quando um cliente publica em um tópico não autorizado sob esta versão, o broker normalmente ignora a mensagem (descartar silenciosamente) sem encerrar a conexão. Isso torna o MQTT 3.1, em alguns casos, mais adequado quando a robustez contra erros de configuração ou permissões temporariamente ausentes é mais importante do que a execução estrita da segurança.

Embora o MQTT 5.0 introduza a capacidade de trabalhar com códigos de razão (como PUBACK com um motivo de recusa), isso requer suporte tanto no lado do cliente quanto no lado do servidor. A migração para o MQTT 5.0, portanto, envolve um esforço adicional de implementação.

Consequências de Ignorar a Compatibilidade: Se um cliente se conectar usando MQTT 3.1.1 e tentar publicar mensagens em tópicos não autorizados, o broker encerrará abruptamente a sessão. Isso pode levar à instabilidade, perda de conectividade ou aumento da carga devido a tentativas repetidas de reconexão.

Abordagem Recomendada: Para sistemas onde os clientes podem (temporariamente) tentar publicar em tópicos não autorizados, ou onde o tratamento de erros não é estritamente implementado, recomendamos o uso do MQTT 3.1. Isso garante conexões mais estáveis e evita desconexões indesejadas durante a execução.