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.
Aperçu des incidents
La page Incidents liste tous les incidents actifs et passés du projet. Chaque entrée montre le projet, l’appareil, le type d’incident et une description. Utilisez les filtres pour vous concentrer sur ce qui n’est pas résolu ou pour parcourir l’historique.
Les incidents propres à un projet sont aussi accessibles via l’onglet Incidents à l’intérieur d’un projet.
Les onglets
La liste des incidents est répartie en trois onglets :
| Onglet | Ce qu’il montre |
|---|---|
| Incidents ouverts | Tout ce qui n’est pas encore résolu. C’est la vue de travail. |
| Tous | Les incidents ouverts et clôturés, hors incidents masqués. |
| Masqué | Uniquement les incidents d’un type masqué, pour qu’un type mis en sourdine reste consultable. |
Mettre un type d’incident en sourdine
Certaines alarmes sont correctes mais sans utilité sur une installation donnée : un appareil sciemment hors ligne, une limitation attendue sur ce site, un avertissement sur du matériel qui sera remplacé la semaine prochaine. Plutôt que de vivre avec une liste durablement rouge, vous pouvez mettre le type d’incident en sourdine.
La mise en sourdine fonctionne par type, pas par incident. Depuis un incident de la liste, utilisez l’action de mise en sourdine et choisissez la portée :
| Portée | Effet |
|---|---|
| Ignorer pour l’appareil | Seul cet appareil cesse de générer ce type d’incident. Les autres continuent. |
| Ignorer pour le projet | Plus aucun appareil du projet ne génère ce type d’incident. |
La portée par appareil est celle à utiliser par défaut ; la portée projet est réservée à un type réellement sans intérêt pour toute l’installation.
Ce que la mise en sourdine fait et ne fait pas :
- Les incidents d’un type masqué sont toujours enregistrés. Ils passent dans l’onglet Masqué au lieu de la liste ouverte : rien n’est perdu et vous pouvez toujours voir ce qui s’est passé.
- Les incidents masqués n’envoient plus de notification par e-mail ni de notification push.
- La mise en sourdine est réversible, à la portée où elle a été appliquée : la lever pour l’appareil, ou pour le projet.
- La colonne Mis en sourdine par montre qui a masqué le type, de sorte qu’une alarme silencieuse peut toujours être remontée à la personne qui l’a silencée et la décision réexaminée.
Un type peut aussi être masqué pour un appareil supprimé, ce qui compte quand un appareil retiré continue de faire du bruit en partant.
La mise en sourdine cache un symptôme, elle ne corrige pas une cause. Utilisez-la pour une situation connue et acceptée, et privilégiez la portée par appareil pour que la même alarme ailleurs dans l’installation vous parvienne encore. Repassez de temps en temps dans l’onglet Masqué : une mise en sourdine prévue pour une semaine a vite fait de durer un an.
Gravité
Chaque incident a une gravité : Info, Avertissement ou Critique. Les incidents de toutes les gravités restent visibles dans la liste.
Pour la plupart des types d’incidents, c’est la gravité qui décide si vous êtes prévenu : les notifications par e-mail comme les notifications push ne sont envoyées que pour les incidents Critique, pour que ces canaux gardent leur sens et ne se remplissent pas de bruit informatif. Certains incidents liés au contrôleur et au réseau sont traités comme des notifications d’urgence et remontent immédiatement.
Un certain nombre de types font exception. Ils ont leur propre règle de notification, décrite dans la section suivante, et c’est cette règle qui décide à la place de la gravité.
Quels incidents deviennent une notification
Un incident est toujours enregistré. Qu’il devienne aussi une notification, c’est-à-dire un message actif envoyé à une personne par e-mail et par notification push, est une autre question. Pour les types ci-dessous, la réponse ne dépend pas de la gravité mais d’une condition qui leur est propre, car ce sont les cas où quelqu’un doit réellement intervenir.
Les noms ci-dessous sont les types d’incidents 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 prévue dans le contrat de raccordement. Un dépassement plus faible plus tard dans le même mois ne coûte rien de plus sur la facture réseau 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 : ce que le gestionnaire impose n’est pas un défaut de l’installation. |
| Le contrôleur est hors ligne | Après une heure sans le moindre signe de vie du contrôleur. L’incident lui-même s’ouvre déjà après trente minutes, mais un contrôleur brièvement injoignable ne vaut pas un coup de téléphone. |
| 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. Une alarme incendie n’est jamais supprimée, même pendant une maintenance annoncée, et 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, au lieu d’une par appareil. Reste silencieux tant que le contrôleur lui-même est hors ligne, puisque rien derrière lui ne peut alors répondre. |
| Compteur du raccordement injoignable via Modbus | Idem, spécifiquement pour le compteur au point de raccordement. |
| Communication perdue avec une borne derrière la passerelle de recharge | Idem, pour une borne de recharge atteinte via une passerelle de recharge. |
| Le disjoncteur a déclenché | Immédiatement, et chaque déclenchement est une notification à part, car quelqu’un doit chaque fois aller le réenclencher. Le rétablissement est signalé aussi, puisque c’est la partie utile pour qui est sur place. |
| 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, donc la nuit entre les deux ne remet pas le compteur à zéro. Les heures où la production a été volontairement écrêtée ne comptent pas. Regroupé par installation, donc plusieurs onduleurs donnent une seule notification. |
Ce que cela signifie en pratique :
- Un type d’incident qui ne figure pas dans cette liste garde le fonctionnement général décrit sous Gravité.
- Un type de cette liste ignore la gravité et l’attente de cinq minutes, et ne se répète pas non plus après douze heures. Une notification par occurrence.
- La mise en sourdine s’applique toujours à chaque type, y compris ceux-ci. Un type masqué ne notifie jamais.
- Un projet pas encore validé n’envoie pas de notifications. Les premiers jours après la mise en service produisent beaucoup de mesures erratiques : tout est enregistré, mais personne n’est appelé tant que le projet n’est pas validé. Les notifications démarrent d’elles-mêmes dès que c’est le cas.
Questions fréquentes
Quels incidents déclenchent une notification ?
Presque tous les incidents apparaissent dans votre liste, y compris les défauts, les avertissements et les alertes informatives concernant les appareils, le contrôleur EMS et les limites réseau. Seule une partie d’entre eux devient aussi une notification.
Les types repris sous Quels incidents deviennent une notification suivent leur propre condition, comme un nouveau record mensuel ou une heure de silence. Tout le reste suit la gravité.
Pour ces autres types, les notifications par e-mail sont groupées et envoyées uniquement pour les incidents Critique :
- Un premier e-mail part dès que l’incident est ouvert depuis au moins cinq minutes (pas encore résolu et pas déjà repris dans un envoi groupé).
- Un e-mail de suivi peut partir environ douze heures après le début de l’incident, s’il est encore ouvert à ce moment-là.
Les notifications push sont elles aussi limitées aux incidents Critique. Une notification push est retirée automatiquement dès que l’incident qu’elle annonçait est résolu.
Les incidents de gravité Info et Avertissement sont enregistrés et affichés dans la liste, mais ne génèrent ni e-mail ni notification push, sauf si leur type a sa propre règle.
Combien de temps avant qu’une notification parte ?
Pour un type d’incident qui a sa propre règle, le délai figure dans le tableau sous Quels incidents deviennent une notification. Pour tous les autres types :
| Canal de notification | Moment |
|---|---|
| E-mail (incidents Critique) | Après que l’incident est ouvert depuis au moins 5 minutes |
| E-mail de suivi | Environ 12 heures après le début de l’incident, s’il n’est toujours pas résolu |
| Push (Critique uniquement) | Envoyée à l’ouverture de l’incident, retirée à sa résolution |
Pourquoi n’ai-je pas reçu de notification pour un incident de ma liste ?
Il y a quelques raisons pour lesquelles un incident est enregistré sans que personne ne soit prévenu, et toutes sont voulues :
- Son type a une règle qui n’a pas été remplie. Un dépassement réseau qui n’a pas établi de nouveau record mensuel, ou un appareil qui a de nouveau répondu dans l’heure, est enregistré mais pas signalé.
- Sa gravité est Info ou Avertissement et son type n’a pas de règle propre.
- Le type est masqué pour l’appareil ou pour le projet. Regardez dans l’onglet Masqué.
- Le projet n’est pas encore validé et se trouve donc encore dans sa période de mise en service.
La liste des incidents donne l’image complète. Les notifications en sont une sélection volontairement courte.
Comment configurer les destinataires des notifications ?
Sous Paramètres → Règles d’incidents, vous choisissez quels utilisateurs reçoivent les notifications pour ce projet.
- Allez dans Paramètres → Règles d’incidents.
- Vous voyez la liste des utilisateurs liés au projet.
- Mettez l’interrupteur à côté du nom d’un utilisateur sur activé pour lui envoyer les notifications par e-mail et dans le portail.
- Mettez-le sur désactivé pour cesser de lui en envoyer.
Cette configuration est propre au projet ; les modifications faites ici ne concernent que les notifications du projet en cours.
Voltmasters EMS : gestion des incidents