Plateforme Voltmasters
Gestion des incidents
Suivre les incidents d’un projet EMS Voltmasters : la liste avec ses onglets et ses filtres, la mise en sourdine, et quels incidents envoient un e-mail ou une notification push.
La liste des incidents
Sous Incidents se trouvent les incidents actifs et clôturés de tous vos projets. À l’intérieur d’un projet, l’onglet Incidents ne montre que les incidents de ce projet.
- Les onglets : Incidents ouverts (pas encore résolus), Tous (ouverts et clôturés, sans les masqués) et Masqué (uniquement les incidents d’un type masqué).
- Rechercher dans la liste.
- La gravité : Info, Avertissement ou Critique.
- Le début et la fin de l’incident.
- La cloche : mettre le type d’incident en sourdine. Voir Mettre un type d’incident en sourdine.
Mettre un type d’incident en sourdine
Certaines alarmes sont justes mais inutiles sur une installation donnée : un appareil volontairement hors ligne, une limitation attendue sur ce site, ou du matériel qui sera bientôt remplacé. Vous pouvez alors mettre le type d’incident en sourdine.
La mise en sourdine fonctionne par type, pas par incident. Cliquez sur la cloche d’un incident et choisissez la portée :
| Portée | Effet |
|---|---|
| Ignorer pour l’appareil | Seul cet appareil ne signale plus ce type d’incident. Les autres appareils continuent de le signaler. |
| Ignorer pour le projet | Plus aucun appareil du projet ne signale ce type d’incident. |
Choisissez par défaut la portée par appareil. La portée projet est réservée à un type sans intérêt pour toute l’installation.
- Les incidents d’un type masqué sont toujours enregistrés, dans l’onglet Masqué au lieu de la liste ouverte.
- Les incidents masqués n’envoient ni e-mail ni notification push.
- La mise en sourdine est réversible à la même portée : la lever pour l’appareil, ou pour le projet.
- La colonne Mis en sourdine par montre qui a masqué le type.
- Un type peut aussi être masqué pour un appareil supprimé.
La mise en sourdine cache un symptôme, elle ne corrige pas une cause. Utilisez-la pour une situation connue et acceptée, et repassez de temps en temps par l’onglet Masqué : une mise en sourdine prévue pour une semaine dure vite un an.
Quand un incident devient une notification
Chaque incident est enregistré et affiché dans la liste. Une notification, c’est-à-dire un e-mail et une notification push, ne part que dans les cas ci-dessous, et uniquement vers les personnes désignées (voir Qui reçoit une notification).
flowchart TD
I["Nouvel incident"] --> V{"Projet validé ?"}
V -- "Non" --> L["Seulement dans la liste"]
V -- "Oui" --> D{"Type masqué ?"}
D -- "Oui" --> G["Seulement dans l’onglet Masqué"]
D -- "Non" --> R{"Type avec sa propre règle ?"}
R -- "Oui" --> RR["Notification dès que la condition est remplie"]
R -- "Non" --> K{"Gravité Critique ?"}
K -- "Non" --> L
K -- "Oui" --> M["Push tout de suite, e-mail après 5 minutes"]
Un projet qui n’est pas encore validé n’envoie pas de notifications : les premiers jours après la mise en service produisent beaucoup de mesures inhabituelles. Après la validation, les notifications démarrent d’elles-mêmes.
Incidents critiques
Pour un type sans règle propre, c’est la gravité qui décide. Seul Critique donne une notification :
| Canal | Délai |
|---|---|
| Notification push | Tout de suite. Elle est retirée automatiquement dès que l’incident est résolu. |
| Dès que l’incident est ouvert depuis au moins 5 minutes. Les e-mails sont groupés. | |
| E-mail de suivi | Environ 12 heures après le début, si l’incident est encore ouvert. |
Limite d’e-mails : un problème qui revient sans cesse est signalé chaque fois comme un nouvel incident. Les e-mails sont donc limités par situation. Une situation est la combinaison du projet, de l’appareil et du type d’incident. Elle envoie au plus un e-mail par jour, et cela sur au plus deux jours par semaine calendaire (du lundi au dimanche, dans le fuseau horaire du projet). Ces deux jours ne doivent pas se suivre. Les notifications push ne sont pas limitées.
Types avec leur propre règle
Pour ces types, la notification ne dépend pas de la gravité mais d’une condition propre. Ils envoient une notification à chaque fois que la condition est remplie, sans le délai de 5 minutes et sans e-mail de suivi. La mise en sourdine s’applique aussi à ces types. Les noms sont les types tels qu’ils apparaissent dans la liste.
| Type d’incident | Quand la notification part |
|---|---|
| Limite de prélèvement réseau dépassée | Uniquement lorsque la moyenne quart-horaire établit un nouveau record du mois au-dessus de la puissance d’accès du contrat de raccordement. Un dépassement plus faible plus tard dans le même mois ne coûte rien de plus et reste silencieux. Chaque mois civil repart de zéro. |
| Limite d’injection réseau dépassée | Idem, côté injection. Les périodes pendant lesquelles le gestionnaire de réseau a lui-même limité le site par télécontrôle sont exclues. |
| Le contrôleur est hors ligne | Après une heure sans signe de vie du contrôleur. L’incident lui-même s’ouvre déjà après trente minutes. |
| Alarme de contrôle d’accès | Immédiatement. Le local batteries ou l’armoire a été ouvert. |
| Alarme incendie, Alarme incendie déclenchée et Alarme incendie signalée par l’appareil | Immédiatement, avec la priorité la plus haute, à chaque destinataire du projet. Elle reste ouverte jusqu’à ce que quelqu’un la résolve manuellement. |
| Connexion Modbus défaillante | Après soixante minutes sans une seule réponse valide. Regroupé par connexion : si une passerelle tombe, vous recevez une seule notification qui cite les appareils derrière elle. Reste silencieux tant que le contrôleur lui-même est hors ligne. |
| Compteur du raccordement injoignable via Modbus | Idem, pour le compteur au point de raccordement. |
| Communication perdue avec une borne derrière la passerelle de recharge | Idem, pour une borne atteinte via une passerelle de recharge. |
| Le disjoncteur a déclenché | Immédiatement, et chaque déclenchement est une notification à part. Le rétablissement est signalé aussi. |
| Le PV ne produit pas alors qu’il le devrait | Après huit heures couvertes par une prévision pendant lesquelles l’onduleur est resté sous un cinquième de celle-ci. Ces heures peuvent s’étaler sur plusieurs jours. Les heures où la production a été volontairement écrêtée ne comptent pas. Regroupé par installation. Un onduleur qui a perdu la communication ne génère pas d’incident de production : la perte de communication est signalée comme un incident à part. |
Qui reçoit une notification
Sous Paramètres → Règles d’incidents figurent les utilisateurs du projet, chacun avec un interrupteur. Activé signifie que cet utilisateur reçoit les notifications de ce projet, désactivé qu’il ne les reçoit plus. Le réglage ne vaut que pour ce projet.
Questions fréquentes
Pourquoi n’ai-je pas reçu de notification pour un incident de ma liste ?
Suivez le schéma sous Quand un incident devient une notification. C’est en général l’une de ces raisons :
- Le projet n’est pas encore validé.
- Le type est masqué pour l’appareil ou le projet. Regardez dans l’onglet Masqué.
- Le type a sa propre règle qui n’a pas été remplie, par exemple un dépassement réseau sans nouveau record mensuel, ou un appareil qui a de nouveau répondu dans l’heure.
- La limite d’e-mails est atteinte : la même situation (projet, appareil et type d’incident) a déjà envoyé un e-mail aujourd’hui, ou deux jours cette semaine calendaire. La notification push arrive quand même.
- La gravité est Info ou Avertissement.
- Vous êtes sur désactivé sous Règles d’incidents.