Voltmasters Platform
Incident management
Track incidents on a Voltmasters EMS project: the incident list with its tabs and filters, muting, and which incidents send an email or push notification.
Incident overview
The Incidents page lists all active and historical incidents for the project. Each entry shows the project, device, incident type and a description. Use the filters to focus on unresolved issues or to search the incident history.
Project-specific incidents can also be accessed via the Incidents tab within a project.
The tabs
The incident list is split into three tabs:
| Tab | What it shows |
|---|---|
| Open incidents | Everything currently unresolved. This is the working view. |
| All | Open and closed incidents, muted ones excluded. |
| Muted | Only the incidents of a muted type, so a silenced type stays inspectable. |
Muting an incident type
Some alarms are correct but not useful on a given installation: a device that is knowingly offline, a limitation that is expected on this site, a warning about hardware that is being replaced next week. Rather than living with a permanently red list, you can mute the incident type.
Muting works per type, not per incident. From an incident in the list, use the mute action and choose the scope:
| Scope | Effect |
|---|---|
| Mute for device | Only this device stops raising this incident type. Other devices keep raising it. |
| Mute for project | No device in the project raises this incident type any more. |
Device scope is the one to reach for by default; project scope is for a type that is genuinely irrelevant to the whole installation.
What muting does and does not do:
- Incidents of a muted type are still recorded. They move to the Muted tab instead of the open list, so nothing is lost and you can always see what has been happening.
- Muted incidents no longer send email or push notifications.
- Muting is reversible at the same scope it was applied: unmute for the device, or unmute for the project.
- The Muted by column shows who muted the type, so a silenced alarm can always be traced back to the person who silenced it and the decision can be revisited.
A type can also be muted for a deleted device, which matters when a removed device keeps producing noise on its way out.
Muting hides a symptom, it does not fix a cause. Use it for a known and accepted situation, and prefer the device scope so the same alarm elsewhere in the installation still reaches you. Review the Muted tab every so often: a mute that was meant to last a week has a way of lasting a year.
Severity
Each incident has a severity: Info, Warning or Critical. Incidents of every severity remain visible in the incident list.
For most incident types the severity decides whether you hear about it: email and mobile push notifications are only sent for Critical incidents, so the channels stay meaningful and do not fill up with informational noise. Some controller- and grid-level incidents are treated as emergency notifications and are surfaced immediately.
A number of incident types are the exception. Those have a notification rule of their own, described in the next section, and that rule decides instead of the severity.
Which incidents become a notification
An incident is always registered. Whether it also becomes a notification, meaning an active message to a person by email and mobile push, is a second question. For the types below the answer is not the severity but a condition of their own, because these are the cases where somebody genuinely has to act.
The names below are the incident types as they appear in the list.
| Incident type | When it is sent |
|---|---|
| Grid consumption limit exceeded | Only when the quarter-hour average sets a new record for the month above the access power in the connection contract. A lower exceedance later in the same month costs nothing extra on the grid invoice and stays silent. Every calendar month starts its own count. |
| Grid injection limit exceeded | The same, on the injection side. Periods in which the grid operator limited the site itself over telecontrol are excluded: what the operator imposes is not a fault of the installation. |
| The controller is offline | After one hour without a single sign of life from the controller. The incident itself already opens after thirty minutes, but a controller that is briefly unreachable is not worth a phone call. |
| Access control alarm | Immediately. The battery room or the cabinet has been opened. |
| Fire alarm, Fire alarm triggered and Fire alarm reported by the device | Immediately, at the highest priority, to every recipient of the project. A fire alarm is never suppressed, not even during announced maintenance, and it stays open until somebody resolves it by hand. |
| Modbus connection unhealthy | After sixty minutes without a single valid answer. Grouped per connection, so a gateway dropping out is one notification naming the devices behind it instead of one per device. Stays silent as long as the controller itself is offline, since nothing behind it can answer then. |
| Grid connection meter is unreachable over Modbus | The same, for the meter at the connection point specifically. |
| Lost communication with a charger behind the charging gateway | The same, for a charging station reached through a charging gateway. |
| The breaker tripped | Immediately, and every trip is its own notification, because somebody has to go and switch it back in each time. The recovery is reported as well, since that is the useful part for whoever is on site. |
| PV not generating power when expected | After eight hours that carried a forecast in which the inverter stayed under a fifth of it. Those hours may run across several days, so a nightfall in between does not reset the count. Hours in which production was deliberately curtailed do not count. Grouped per installation, so several inverters give one notification. |
What this means in practice:
- An incident type that is not in this list keeps the general behaviour described under Severity.
- A type in this list ignores the severity and the five-minute wait, and does not repeat after twelve hours either. One notification per occurrence.
- Muting still applies to every type, including these. A muted type never notifies.
- A project that is not yet validated does not send notifications. The first days after commissioning throw off a lot of readings, so everything is recorded but nothing calls anyone until the project is validated. Notifications start on their own once that happens.
Frequently asked questions
Which incidents trigger a notification?
Almost all incidents appear in your incident list, including faults, warnings and informational alerts for devices, the EMS controller and grid limits. Only some of them also become a notification.
The types listed under Which incidents become a notification follow their own condition, such as a new monthly record or an hour of silence. Everything else follows the severity.
For those other types, email notifications are bundled and delivered for Critical incidents only:
- A first email is sent once the incident has been open for at least five minutes (not yet resolved and not previously included in a bundle).
- A follow-up email may be sent approximately twelve hours after the incident began, if it is still open at that time.
Mobile push notifications are likewise limited to Critical incidents. A push notification is withdrawn automatically once the incident it announced is resolved.
Incidents of severity Info and Warning are recorded and shown in the incident list, but do not generate an email or a push notification unless their type has a rule of its own.
How long before a notification is sent?
For an incident type with a rule of its own, the timing is in the table under Which incidents become a notification. For every other type:
| Notification channel | Timing |
|---|---|
| Email (Critical incidents) | After the incident has been open for at least 5 minutes |
| Email follow-up | Approximately 12 hours after the start of the incident, if still unresolved |
| Mobile push (Critical only) | Sent when the incident is raised, and withdrawn when it is resolved |
Why did I not get a notification for an incident in my list?
There are a few reasons an incident is recorded without anyone being called about it, and all of them are deliberate:
- Its type has a rule that was not met. A grid exceedance that did not set a new monthly record, or a device that answered again within the hour, is registered but not reported.
- Its severity is Info or Warning and its type has no rule of its own.
- The type is muted for the device or for the project. Look in the Muted tab.
- The project is not yet validated, so it is still in its commissioning period.
The incident list is the complete picture. The notifications are a deliberately short selection out of it.
How do I configure notification recipients?
Under Settings → Incident rules, you can control which users receive notifications for this project.
- Navigate to Settings → Incident rules.
- You will see a list of users associated with the project.
- Toggle the switch next to a user's name to on to enable email and portal notifications for that user.
- Toggle it off to stop sending notifications to that user.
This configuration is per project; changes here only affect notifications for the current project.
Voltmasters EMS: incident management