System-specific Issue Generation Settings

System-specific Issue Generation Settings

Mana is able to automatically various types of issues and notifications automatically. For an overview, see: Notifications in the Mana User's Manual.

For a detailed overview of how COM ERR and NOT PRODUCING notifications work, see Events and Notifications in this guide. If you are an administrator looking to debug notifications, or find out why an issue was or was not created, see Issue Creation Diagnostic Tools.

System COM ERR Timeout

The website can be configured to wait a specified amount of minutes before setting a system's status to COM ERR. This is to allow some lag in communications between the device(s) and Mana. This timeout can be set on the system form:

Please see: System Statuses page in the Mana User's Manual.

System-specific Issue Generation Settings

Issue Generation Timeout

The website can be configured to wait a specified amount of daytime minutes after a system has stopped reporting before creating a COM ERR issue in the System-specific Notifications Control Panel. 

Similarly, a timeout can be set for NOT PRODUCING issues. It is measured in daytime minutes: only time between 07:00 and 17:00 site-local time counts. This window is fixed; it does not follow the site's sunrise/sunset or its Expected Production Period.

The count starts at the system's last reading at or above its Minimum Production Threshold. If that reading was before 07:00, the count starts at 07:00 that day; if at or after 17:00, it starts at 07:00 the next day. Each full day without a good reading adds 600 minutes, and any new good reading restarts the count. For example, with a 180-minute timeout and no good reading after 16:00, the count reaches 60 minutes by 17:00 and resumes at 07:00 the next morning, reaching 180 at about 09:00.

A NOT PRODUCING issue is only created if the system status is already NOT PRODUCING (see System Statuses). Issues are checked every 5 minutes between 07:00 and 17:00 site time, so none is ever created outside those hours. An issue may come up to about 10 minutes before or after the timeout is reached, because the first check that finds the problem only records it. Issue creation also waits while a data reload is in progress, and for 30 minutes after the system was in COM ERR.

Note that the issue generation timeout is not in addition to the COM ERR timeout, but the COM ERR timeout must elapse before a system state is set to COM ERR. In other words, the system must first enter COM ERR (for this the timeout is set on the System properties page in the "Production COM ERR Timeout" field). Once it enters COM ERR, we check if the timeout set on the notifications panel for the system has elapsed, and if it has, the issue is created.  

Enabling/Disabling Notifications for a System

Additionally, COM ERR, NOT PRODUCING, and production DEVIATION type notifications can be turned off completely for a system in the System-specific Notifications Control Panel.

Note that if you turn off a type of notification for a system, then such notifications will also be turned off for the subsystems of that system as well!

System-specific Notifications Control Panel

To set the above system-specific settings, click on the little envelope next to the given system:

COM ERR Notifications options

Uncheck the "Enabled" checkbox to completely disable COM ERR type notifications for this system and all of its subsystems.

Set a timeout threshold for how long a system should be in the COM ERR state before an issue is created, as explained above in Issue Generation Timeout section. If nothing is set, the default value is 120 minutes.

NOT PRODUCING Notifications options

Uncheck the "Enabled" checkbox to completely disable NOT PRODUCING type notifications for this system and all of its subsystems.

Set the timeout: the number of daytime minutes without a reading at or above the Minimum Production Threshold before an issue is created, as explained above in the Issue Generation Timeout section. If nothing is set, the default is 120 minutes.

Set the Minimum Production Threshold (kW): the average power of a single reading below which the system is treated as effectively not producing. If nothing is set (or the value is 0 or negative), it defaults to 1% of the system DC size, or 5 kW if the size is unknown. The same threshold also decides the system status (see footnote *3 on the System Statuses page) and when the issue is resolved automatically.

Keep this value low, around 5% of DC size. It is meant to detect a system that has effectively stopped, not one that is underperforming. A high value raises an issue on every overcast day and during the normal late-afternoon ramp-down. Use Production DEVIATION notifications to detect underperformance.

A NOT PRODUCING issue is resolved automatically once a reading at or above the threshold arrives after the outage started. This is checked every 5 minutes between 07:00 and 17:00 site time. Issues that a user has edited or commented on are not closed automatically. Instead the system adds a comment saying they can be closed.

Production DEVIATION Notifications options

See the Notifications chapter of the Mana User's Manual for an explanation of how Production DEVIATION notifications work.

Uncheck the "Enabled" checkbox to completely disable Production DEVIATION type notifications for this system and all of its subsystems.

Set a timeout threshold for how long readings need to deviate from the expected values before an issue is created.

Set the under- and over-performing threshold that needs to be exceeded before the above timeout becomes active. If the system is above or below the given threshold for at least the number of minutes set in the timeout, then an issue will be created.