Alertas e Notificações

Alertas

Gestor de alertas ▸ Alertas lista os alertas gerados pelas suas regras: o que está disparado neste momento, os resolvidos ou ambos. Abrir no Mirox

Cada alerta mostra o seu nível, a regra, a central, o componente (nas regras avaliadas por componente), o valor e desde quando — ou de quando até quando — esteve disparado. Um alerta que chegou durante um silenciamento fica marcado como Silenciado.

Um alerta resolve-se por si quando a condição deixa de se verificar, quando a regra é desativada, alterada de modo que já não corresponda, ou eliminada. Os alertas resolvidos permanecem na lista como histórico.

Reconhecer diz aos seus colegas que alguém está a tratar do assunto. Não fecha o alerta — só os valores da central o fazem.

As alterações a regras e silenciamentos também aparecem na atividade da sua organização.

Quem é notificado

Quando um alerta se abre, todas as pessoas da sua organização que têm acesso à central são notificadas — na app, por push na app móvel e por e-mail, exatamente como cada pessoa escolheu nas suas próprias definições de notificação no grupo Gestor de alertas. Aí cada pessoa escolhe os canais e o nível mínimo a partir do qual quer ser informada sobre estes alertas; por predefinição é Normal.

Quando o alerta se resolve, as pessoas que foram notificadas recebem um aviso de resolução. A notificação liga diretamente ao alerta.

Silenciamentos

Um silenciamento mantém as notificações afastadas durante algum tempo — para manutenção, um problema conhecido ou uma paragem planeada. Os alertas correspondentes continuam a abrir e a fechar e aparecem na lista, marcados como Silenciado; apenas as notificações e os destinatários ficam calados.

Abra Gestor de alertas ▸ Silenciamentos e clique em Novo silenciamento. Abrir no Mirox Escolha:

• Regra — uma regra ou todas as regras.
• Central — uma central ou todas as centrais.
• Início — agora ou num momento planeado.
• Durante — de 1 hora até 1 ano, ou Até uma data… para uma data de fim livre (no máximo um ano após o início).
• Comentário — o motivo, para que os seus colegas saibam.

Um silenciamento termina por si. Remova-o mais cedo com o seu botão de eliminar. Os silenciamentos são criados e removidos por Administradores e Moderadores.

Destinatários

Um destinatário recebe automaticamente cada alerta das regras a que está associado — um sistema de tickets, um canal de equipa ou uma caixa de correio partilhada. As pessoas não precisam de um destinatário; são, de qualquer forma, notificadas através das suas próprias definições.

Abra Gestor de alertas ▸ Destinatários e clique em Novo destinatário Abrir no Mirox, e depois associe-o a regras em Destinatários no editor de regras. Enviar teste entrega um alerta de exemplo para que possa verificar a ligação.

E-mail

Uma lista de endereços de e-mail. Cada alerta e a sua resolução chegam como um e-mail.

Webhook

Um endereço HTTPS que recebe um POST por cada alerta e a sua resolução, num destes formatos:

• JSON (assinado) — o alerta completo em JSON, veja abaixo.
• Microsoft Teams, Slack, Discord — uma mensagem já pronta para um webhook de entrada desse serviço. Consulte Ligar o Microsoft Teams para saber como criar um.

Ao criar um destinatário webhook, o seu segredo de assinatura é mostrado uma única vez. Cada pedido traz o cabeçalho X-Mirox-Signature: sha256=<hex> — o HMAC-SHA256 do corpo bruto do pedido com esse segredo — mais X-Mirox-Timestamp e um X-Mirox-Delivery-Id único. Verifique a assinatura antes de confiar num pedido e use o id de entrega para ignorar uma entrega repetida.

O corpo de JSON (assinado):

{
  "version": "1",
  "status": "firing",
  "event_id": "1216448682925686786",
  "rule_uid": "A1B2C3D4E5F6",
  "rule_name": "Inverter without power",
  "rule_version": 3,
  "priority": "high",
  "park_uid": "0A1B2C3D4E5F",
  "park_name": "Plant North",
  "instance_key": "inverter_id=7",
  "labels": { "inverter_id": "7" },
  "component": "Inverter 7",
  "metric": "AC power per inverter",
  "value": 0.0,
  "unit": "W",
  "op": "lt",
  "threshold": 10.0,
  "condition_since": 1791200400,
  "title": "[FIRING] Inverter without power — Plant North (Inverter 7)",
  "body": "Inverter 7 delivers only 0 W (limit 10 W)",
  "link": "https://service.mirox.io/#/alertmanager?tab=alerts&alert=1216448682925686786",
  "sent_at": "2026-10-06T09:05:12+00:00"
}

status é firing ou resolved; uma resolução repete o alerta com o último valor avaliado. condition_since é um carimbo de data/hora Unix. Podem ser acrescentados campos em versões posteriores — ignore o que não conhecer. event_id é uma cadeia de caracteres — o identificador é mais longo do que um número JavaScript consegue representar com exatidão.

Após repetidas falhas de entrega, um destinatário é desativado e marcado como Desativado; verifique o endereço e crie-o de novo.

Interface de indisponibilidade BWE

Comunica as indisponibilidades das suas turbinas eólicas ao seu comercializador direto através da interface de indisponibilidade BWE. Cada alerta de uma turbina torna-se uma indisponibilidade: quando o alerta dispara começa, quando é resolvido termina. O seu comercializador direto opera a interface e fornece-lhe três dados: o endereço do serviço web, o endereço do token e o nome de utilizador e a palavra-passe — introduza-os no destinatário. A palavra-passe é guardada encriptada e nunca mais é mostrada. Testar o início de sessão inicia sessão e mostra quantas centrais o comercializador atribuiu à sua conta; nunca comunica uma indisponibilidade.

• Motivo da indisponibilidade: um destinatário por motivo — MAINTENANCE (avarias, manutenção, operação manual), ADMINISTRATIVE (ordens administrativas como ruído ou proteção de morcegos e aves), GRID (limitação pelo operador da rede) ou MARKET (limitação pelo comercializador). Use GRID e MARKET apenas quando a origem da limitação for certa.
• Capacidade restante comunicada: 0 kW (indisponibilidade total) ou o valor do alerta quando a regra vigia uma métrica de potência — nunca mais do que a capacidade instalada registada pelo comercializador.
• Comunicado antecipadamente: a interface exige uma hora de fim, por isso um alerta aberto é comunicado até tantos dias antecipadamente (30 por predefinição); o seu fim reduz a indisponibilidade ao fim real.

Cada turbina é encontrada na lista de centrais do comercializador pelo número de série dos seus dados mestre; se o número coincidir, decide o fabricante. Associe o destinatário a regras que vigiam turbinas uma a uma — os exemplos Turbina parada por avaria e Turbina limitada por condicionantes ambientais foram feitos para isso. Uma turbina que o comercializador não conhece aparece como entrega falhada do destinatário.

Modelos

Um modelo define exatamente o que um destinatário envia, para que cada sistema receba o formato que espera: num webhook o método (POST, PUT ou PATCH), seus próprios cabeçalhos e o corpo em JSON, XML, CSV, HTML, texto simples ou dados de formulário; num e-mail o assunto e o texto (texto simples ou seu próprio HTML). Você escreve texto fixo e insere variáveis do alerta, da regra, da usina e do componente. Um modelo é reutilizável: vários destinatários podem usar o mesmo, e uma alteração vale para todos de uma vez.

Abra Gestor de alertas ▸ Destinatários Abrir no Mirox: abaixo dos destinatários estão seus modelos e os exemplos para começar. Usar exemplo copia um para sua organização; Novo modelo começa vazio. O modelo abre no editor: à esquerda as configurações, os cabeçalhos e o corpo, no meio a lista de variáveis — um clique insere a variável no cursor — e à direita a pré-visualização ao vivo: a requisição ou o e-mail exatamente como seria enviado, com o alerta de exemplo ou um dos seus alertas recentes, com todos os erros e avisos. Depois escolha o modelo para um destinatário — ao criá-lo ou com o botão de modelo na sua linha. Sem modelo, o destinatário mantém o formato integrado.

Os modelos são criados e alterados por administradores e moderadores; todos os membros podem vê-los. Um modelo usado por um destinatário não pode ser excluído — escolha antes outro para esse destinatário.

A linguagem dos modelos

Dentro de uma seção de lista estão disponíveis {{@index}} (a partir de 0), {{@number}} (a partir de 1), {{@first}} e {{@last}} — por exemplo {{^@last}},{{/@last}} coloca uma vírgula entre os itens. Uma variável inexistente fica vazia e a pré-visualização a mostra como aviso. Nada é executado num modelo; ele só produz texto.

Variáveis

As datas aparecem no fuso horário da usina, salvo se o filtro date indicar outro. A usina não tem campo para um número MaStR nem para uma localização de mercado — escreva esses identificadores como texto fixo no modelo.

Os filtros seguem a variável após | e podem ser encadeados, por exemplo {{alert.value|kw|number:1:de}}:

Formatos e escape

O formato do modelo decide como um valor é inserido, para que um nome de usina com aspas ou um «&» nunca quebre o resultado:

• JSON — dentro de uma string ("plant": "{{plant.name}}") o valor é escapado como texto; fora dela ("value": {{alert.value}}) vira um valor JSON: um número continua número, texto recebe aspas, um valor vazio vira null, objetos e listas são escritos como JSON.
• XML e HTML — <, >, & e aspas são escapados.
• CSV — um campo vai entre aspas quando contém o separador, uma aspa ou uma quebra de linha; num campo que o modelo já coloca entre aspas, as aspas são duplicadas. O separador é o que seu modelo usa (vírgula, ponto e vírgula, tabulação).
• Dados de formulário — os valores são codificados como URL.
• Texto simples — como está.

Valores de cabeçalho e o assunto do e-mail nunca contêm quebra de linha. O modelo é verificado ao salvar: deve estar completo (cada seção fechada, cada filtro conhecido), ter no máximo 64 KiB e, para JSON e XML, o resultado com o alerta de exemplo deve ser válido. Cabeçalhos: no máximo 30, apenas nomes padrão. Content-Type segue o formato; Content-Length, Host e os cabeçalhos X-Mirox-* são definidos pelo Mirox e não podem ser substituídos. Toda requisição de webhook continua assinada: X-Mirox-Signature é o HMAC-SHA256 exatamente do corpo que seu modelo produziu.

Exemplos

Cada exemplo é um ponto de partida que você copia e adapta:

• JSON genérico (envelope assinado) — O envelope de alerta documentado do Mirox — base para sistemas de tickets.
• Cartão do Microsoft Teams — Um Adaptive Card para um webhook do Teams Workflows.
• Mensagem do Slack — Mensagem Block Kit para um webhook de entrada do Slack.
• Embed do Discord — Um embed colorido para um webhook de canal do Discord.
• Documento XML — O alerta como documento XML.
• Linha CSV — Um cabeçalho e uma linha por alerta, separados por vírgulas.
• E-mail de texto — Um e-mail de texto compacto com os dados principais.
• E-mail HTML — Seu próprio e-mail HTML com tabela de dados.
• Comercializador direto: disponibilidade reduzida (CSV) — Aviso alemão de disponibilidade reduzida em CSV — ponto de partida a adaptar.
• Comercializador direto: disponibilidade reduzida (e-mail) — Aviso alemão por e-mail com usina, início, fim e potência disponível.

Os exemplos do comercializador direto (em alemão) informam uma disponibilidade reduzida de uma usina: nome e ID, início e fim, potência instalada e — numa regra sobre uma métrica de potência — a potência disponível, uma vez como linha CSV com ponto e vírgula e outra como e-mail. Não há formato obrigatório para esse aviso; adapte colunas e texto ao que seu comercializador exige e preencha o número MaStR e a localização de mercado como texto fixo.

Um modelo para um sistema de tickets que espera XML:

<ticket priority="{{alert.level}}">
  <title>{{alert.title}}</title>
  <site id="{{plant.uid}}">{{plant.name}}</site>
  {{#component.name}}<asset>{{component.name}}</asset>{{/component.name}}
  <opened>{{alert.since|date:"iso"}}</opened>
  <link>{{alert.link}}</link>
</ticket>

Testar os alertas

Um teste mostra todo o percurso de um alerta numa das suas centrais — sem esperar por um problema real e sem tocar nos dados da central. Abra Gestor de alertas ▸ Visão geral e clique em Testar alertas Abrir no Mirox; depois escolha a central, o nível do alerta de teste (até Crítico) e, opcionalmente, destinatários.

A plataforma escreve então um sinal de teste fixo para essa central: calmo durante 5 minutos, acima do limiar durante 15 minutos e calmo de novo. O agente da central avalia-o como qualquer uma das suas regras, por isso:

1. cerca de 5–10 minutos após o início abre-se o alerta de teste, no nível escolhido;
2. todos os que seriam notificados de um alerta real desse nível nessa central são notificados — na app, por push e por e-mail, segundo as suas próprias definições — e os destinatários escolhidos também o recebem;
3. cerca de 15 minutos depois resolve-se sozinho, com o seu aviso de resolução.

A página acompanha o teste passo a passo. Um teste termina sozinho após cerca de 30 minutos, ou antes com Parar; o seu alerta fica no histórico. Os testes nunca aparecem entre as suas regras e os dados de teste só são escritos enquanto um teste está ativo. Os testes são iniciados por Admins e Moderadores; podem decorrer até três em simultâneo.

Páginas Relacionadas

• Visão geral do Gestor de alertas
• Regras de Alerta
• Definições de Notificação