Alertes et notifications

Alertes

Gestionnaire d'alertes ▸ Alertes liste les alertes déclenchées par vos règles : ce qui est déclenché en ce moment, les alertes résolues, ou les deux. Ouvrir dans Mirox

Chaque alerte affiche son niveau, la règle, la centrale, le composant (pour les règles jugées par composant), la valeur, et depuis quand — ou de quand à quand — elle était déclenchée. Une alerte arrivée pendant une mise en sourdine est marquée En sourdine.

Une alerte se résout d'elle-même lorsque la condition n'est plus remplie, lorsque la règle est désactivée, modifiée de sorte qu'elle ne correspond plus, ou supprimée. Les alertes résolues restent dans la liste comme historique.

Acquitter indique à vos collègues que quelqu'un s'en occupe. Cela ne ferme pas l'alerte — seules les valeurs de la centrale le font.

Les modifications de règles et de mises en sourdine apparaissent aussi dans l'activité de votre organisation.

Qui est notifié

Lorsqu'une alerte s'ouvre, toutes les personnes de votre organisation qui ont accès à la centrale sont notifiées — dans l'app, par notification push sur l'app mobile et par e-mail, exactement comme chacun l'a choisi dans ses propres paramètres de notification sous le groupe Gestionnaire d'alertes. Chacun y choisit les canaux et le niveau minimal à partir duquel il veut être informé de ces alertes ; par défaut, c'est Normale.

Lorsque l'alerte se résout, les personnes notifiées reçoivent un avis de résolution. La notification renvoie directement à l'alerte.

Mises en sourdine

Une mise en sourdine tient les notifications à l'écart pendant un moment — pour une maintenance, un problème connu ou un arrêt planifié. Les alertes correspondantes continuent de s'ouvrir et de se fermer et apparaissent dans la liste, marquées En sourdine ; seules les notifications et les destinataires restent silencieux.

Ouvrez Gestionnaire d'alertes ▸ Mises en sourdine et cliquez sur Nouvelle mise en sourdine. Ouvrir dans Mirox Choisissez :

• Règle — une règle, ou toutes les règles.
• Centrale — une centrale, ou toutes les centrales.
• Début — maintenant, ou à une heure planifiée.
• Pendant — de 1 heure jusqu'à 1 an, ou Jusqu'à une date… pour une date de fin libre (au plus un an après le début).
• Commentaire — pourquoi, pour que vos collègues le sachent.

Une mise en sourdine se termine d'elle-même. Retirez-la plus tôt avec son bouton de suppression. Les mises en sourdine sont créées et retirées par les Admins et les Modérateurs.

Destinataires

Un destinataire reçoit automatiquement chaque alerte des règles auxquelles il est associé — un système de tickets, un canal d'équipe ou une boîte mail partagée. Les personnes n'ont pas besoin d'un destinataire ; elles sont de toute façon notifiées via leurs propres paramètres.

Ouvrez Gestionnaire d'alertes ▸ Destinataires et cliquez sur Nouveau destinataire Ouvrir dans Mirox, puis associez-le à des règles sous Destinataires dans l'éditeur de règles. Envoyer un test remet une alerte d'exemple pour vérifier la connexion.

E-mail

Une liste d'adresses e-mail. Chaque alerte et sa résolution arrivent sous forme d'un e-mail.

Webhook

Une adresse HTTPS qui reçoit un POST pour chaque alerte et sa résolution, dans l'un de ces formats :

• JSON (signé) — l'alerte complète au format JSON, voir ci-dessous.
• Microsoft Teams, Slack, Discord — un message prêt à l'emploi pour un webhook entrant de ce service. Voir Connecter Microsoft Teams pour savoir comment en créer un.

Lorsque vous créez un destinataire webhook, son secret de signature n'est affiché qu'une seule fois. Chaque requête porte l'en-tête X-Mirox-Signature: sha256=<hex> — le HMAC-SHA256 du corps brut de la requête avec ce secret — ainsi que X-Mirox-Timestamp et un X-Mirox-Delivery-Id unique. Vérifiez la signature avant de faire confiance à une requête, et utilisez l'identifiant de remise pour ignorer une remise répétée.

Le corps de JSON (signé) :

{
  "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 vaut firing ou resolved ; une résolution reprend l'alerte avec la dernière valeur jugée. condition_since est un horodatage Unix. Des champs peuvent être ajoutés dans des versions ultérieures — ignorez ce que vous ne connaissez pas. event_id est une chaîne de caractères — l'identifiant est plus long qu'un nombre JavaScript ne peut le représenter exactement.

Après des remises échouées répétées, un destinataire est désactivé et marqué Désactivé ; vérifiez l'adresse et recréez-le.

Interface d'indisponibilité BWE

Déclare les indisponibilités de vos éoliennes à votre agrégateur via l'interface d'indisponibilité BWE. Chaque alerte d'une éolienne devient une indisponibilité : quand l'alerte se déclenche elle commence, quand elle est résolue elle se termine. Votre agrégateur exploite l'interface et vous fournit trois éléments : l'adresse du service web, l'adresse du jeton ainsi que le nom d'utilisateur et le mot de passe — saisissez-les dans le destinataire. Le mot de passe est stocké chiffré et n'est plus jamais affiché. Tester la connexion se connecte et indique combien de centrales l'agrégateur a attribuées à votre compte ; aucune indisponibilité n'est déclarée.

• Motif de l'indisponibilité : un destinataire par motif — MAINTENANCE (défauts, maintenance, exploitation manuelle), ADMINISTRATIVE (décisions administratives comme le bruit ou la protection des chauves-souris et des oiseaux), GRID (bridage par le gestionnaire de réseau) ou MARKET (bridage par l'agrégateur). N'utilisez GRID et MARKET que si l'origine du bridage est certaine.
• Capacité restante déclarée : 0 kW (indisponibilité totale) ou la valeur de l'alerte quand la règle surveille une métrique de puissance — jamais plus que la capacité installée connue de l'agrégateur.
• Déclaré à l'avance : l'interface exige une heure de fin, une alerte ouverte est donc déclarée jusqu'à ce nombre de jours à l'avance (30 par défaut) ; sa résolution ramène l'indisponibilité à sa fin réelle.

Chaque éolienne est retrouvée dans la liste des centrales de l'agrégateur grâce au numéro de série de ses données de base ; le fabricant départage un numéro partagé. Associez le destinataire à des règles qui surveillent les éoliennes une par une — les exemples Éolienne arrêtée sur défaut et Éolienne bridée pour l'environnement sont faits pour cela. Une éolienne inconnue de l'agrégateur apparaît comme un envoi échoué du destinataire.

Modèles

Un modèle définit exactement ce qu'envoie un destinataire, pour que chaque système reçoive le format attendu : pour un webhook la méthode (POST, PUT ou PATCH), vos propres en-têtes et le corps en JSON, XML, CSV, HTML, texte brut ou données de formulaire ; pour un e-mail l'objet et le texte (texte brut ou votre propre HTML). Vous écrivez du texte fixe et insérez des variables de l'alerte, de la règle, de la centrale et du composant. Un modèle est réutilisable : plusieurs destinataires peuvent l'utiliser et une modification s'applique à tous à la fois.

Ouvrez Gestionnaire d'alertes ▸ Destinataires Ouvrir dans Mirox : sous les destinataires se trouvent vos modèles et les exemples pour démarrer. Utiliser l'exemple en copie un dans votre organisation ; Nouveau modèle démarre vide. Le modèle s'ouvre dans l'éditeur : à gauche les réglages, les en-têtes et le corps, au milieu la liste des variables — un clic insère la variable au curseur — et à droite l'aperçu en direct : la requête ou l'e-mail exactement tel qu'il serait envoyé, avec l'alerte d'exemple ou une de vos alertes récentes, et toutes les erreurs et avertissements. Choisissez ensuite le modèle pour un destinataire, à sa création ou avec le bouton modèle de sa ligne. Sans modèle, un destinataire garde son format intégré.

Les modèles sont créés et modifiés par les administrateurs et les modérateurs ; chaque membre peut les consulter. Un modèle utilisé par un destinataire ne peut pas être supprimé : choisissez d'abord un autre modèle pour ce destinataire.

Le langage des modèles

Dans une section de liste, {{@index}} (à partir de 0), {{@number}} (à partir de 1), {{@first}} et {{@last}} sont disponibles — par exemple {{^@last}},{{/@last}} place une virgule entre les éléments. Une variable inexistante reste vide et l'aperçu la signale par un avertissement. Rien n'est exécuté dans un modèle ; il ne produit que du texte.

Variables

Les dates sont affichées dans le fuseau horaire de la centrale, sauf si le filtre date en indique un autre. La centrale n'a pas de champ pour un numéro MaStR ni un point de livraison — écrivez ces identifiants en texte fixe dans le modèle.

Les filtres suivent la variable après | et peuvent s'enchaîner, par exemple {{alert.value|kw|number:1:de}} :

Formats et échappement

Le format du modèle décide de la manière dont une valeur est insérée, pour qu'un nom de centrale avec des guillemets ou une esperluette ne casse jamais le résultat :

• JSON — dans une chaîne ("plant": "{{plant.name}}"), la valeur est échappée comme texte ; en dehors ("value": {{alert.value}}), elle devient une valeur JSON : un nombre reste un nombre, le texte reçoit des guillemets, une valeur vide devient null, objets et listes sont écrits en JSON.
• XML et HTML — <, >, & et les guillemets sont échappés.
• CSV — un champ est mis entre guillemets s'il contient le séparateur, un guillemet ou un saut de ligne ; dans un champ que le modèle met déjà entre guillemets, les guillemets sont doublés. Le séparateur est celui de votre modèle (virgule, point-virgule, tabulation).
• Données de formulaire — les valeurs sont encodées en URL.
• Texte brut — tel quel.

Les valeurs d'en-tête et l'objet de l'e-mail ne contiennent jamais de saut de ligne. Le modèle est vérifié à l'enregistrement : il doit être complet (chaque section fermée, chaque filtre connu), faire au plus 64 Kio, et pour JSON et XML son résultat avec l'alerte d'exemple doit être valide. En-têtes : 30 au maximum, noms standard uniquement. Content-Type suit le format ; Content-Length, Host et les en-têtes X-Mirox-* sont définis par Mirox et ne peuvent pas être remplacés. Chaque requête webhook reste signée : X-Mirox-Signature est le HMAC-SHA256 exactement du corps produit par votre modèle.

Exemples

Chaque exemple est un point de départ à copier et adapter :

• JSON générique (enveloppe signée) — L'enveloppe d'alerte Mirox documentée — base pour les systèmes de tickets.
• Carte Microsoft Teams — Une Adaptive Card pour un webhook Teams Workflows.
• Message Slack — Message Block Kit pour un webhook entrant Slack.
• Embed Discord — Un embed coloré pour un webhook de salon Discord.
• Document XML — L'alerte sous forme de document XML.
• Ligne CSV — Un en-tête et une ligne par alerte, séparés par des virgules.
• E-mail texte — Un e-mail texte compact avec l'essentiel.
• E-mail HTML — Votre propre e-mail HTML avec un tableau.
• Agrégateur : disponibilité réduite (CSV) — Avis allemand de disponibilité réduite en CSV — point de départ à adapter.
• Agrégateur : disponibilité réduite (e-mail) — Avis allemand par e-mail avec centrale, début, fin et puissance disponible.

Les exemples agrégateur (direct marketer) (en allemand) signalent une disponibilité réduite d'une centrale : nom et identifiant, début et fin, puissance installée et — pour une règle sur une métrique de puissance — la puissance disponible, une fois en ligne CSV avec point-virgule et une fois en e-mail. Il n'existe pas de format contraignant pour cet avis ; adaptez colonnes et formulation aux exigences de votre agrégateur et saisissez le numéro MaStR et le point de livraison en texte fixe.

Un modèle pour un système de tickets qui attend du 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>

Tester vos alertes

Un test montre tout le parcours d'une alerte sur l'une de vos centrales — sans attendre un vrai problème et sans toucher aux données de la centrale. Ouvrez Gestionnaire d'alertes ▸ Vue d'ensemble et cliquez sur Tester les alertes Ouvrir dans Mirox, puis choisissez la centrale, le niveau de l'alerte de test (jusqu'à Critique) et, si besoin, des destinataires.

La plateforme écrit alors un signal de test fixe pour cette centrale : calme pendant 5 minutes, au-dessus du seuil pendant 15 minutes, puis à nouveau calme. L'agent de la centrale l'évalue comme n'importe laquelle de vos règles, donc :

1. environ 5 à 10 minutes après le départ, l'alerte de test s'ouvre — au niveau choisi ;
2. toutes les personnes qui seraient averties d'une vraie alerte de ce niveau sur cette centrale le sont — dans l'application, par push et par e-mail, selon leurs propres réglages — et les destinataires choisis la reçoivent aussi ;
3. environ 15 minutes plus tard, elle se résout d'elle-même, avec son avis de résolution.

La page suit le test étape par étape. Un test se termine de lui-même après environ 30 minutes, ou plus tôt avec Arrêter ; son alerte reste dans l'historique. Les tests n'apparaissent jamais parmi vos règles, et les données de test ne sont écrites que pendant un test actif. Les Admins et Modérateurs lancent les tests ; trois au plus peuvent tourner en même temps.

Pages associées

• Aperçu du Gestionnaire d'alertes
• Règles d'alerte
• Paramètres de notification