Technical FAQs

Ask a Question

Struxureware Power Monitoring - Inaccurate Alarm Counts or Alarms Page Displays Errors 'Cannot read Alarm data'

Issue
In the Web Applications Alarms page, all alarms show as "Cannot read Alarm Data".  



May also  not show the active alarm count even though there are alarms displayed.
Active Alarm count may show "0".

Product Line
StruxureWare Power Monitoring 7.0.x
Power Monitoring Expert 7.2.x , 8.x

Environment
Web Applications
Alarms Tab

Cause
This message occurs when the ION_Data database contains large number of unacknowledged events or the Web Applications are not able to properly access the alarm data. 


Resolution

Scenario / Resolution 1:

This can happen if the upgraded database (ION_Data) contains a large number of unacknowledged events. To determine if there are a large number of unacknowledged events, run the following query against ION_Data. This will return the number of unacknowledged events with a timestamp greater than the timestamp you have chosen:

*Note: Irreparable database damage can occur. These procedures should only be performed by users familiar with SQL Server Management Studio. Databases should be backed up prior to performing this procedure.* 

select COUNT(*)from vAlarmLog 
where AckTimeUTC is null
and Priority > 127 
and TimestampUTC > 'some timestamp filter'  

--Example time stamp format: 2014-11-11 16:00

To acknowledge all of these alarms quickly, without having to use the Alarms user interface, execute the following query:

Declare @CurrentDateTime varchar(max)
SET @CurrentDateTime =GETUTCDATE()
INSERT INTO EventAcknowledgement(EventLogID,AckTimeUTC,UserName)
(SELECT a.ID, @CurrentDateTime,'supervisor'from vAlarmLog a where AckTimeUTC is null and Priority > 127)

This query will use the present UTC date / time as the alarm acknowledgment, and supervisor as the account that performed the acknowledgement.

Once the alarms have been acknowledged, the Alarm Viewer will function normally. It is also recommended to delete old, unwanted events to reduce the number of events that will need to be processed. This can be done using the Trim function in Database Manager. Select only Events and choose an appropriate date range.

Scenario / Resolution 2:

If the server machine is on a workgroup, change the Schneider Electric services to run under a local Windows administrator account, restart the services, perform an iisreset, and then check to ensure that alarms are pulling in successfully.

Scenario / Resolution 3:

Check the Windows Host file within the C:\windows\system32\drivers\etc\directory and check the localhost IP address. By default, web services only allows access from 127.0.0.1 which is default localhost. If the address is different than the default the localhost IP address will need to be added to the web services web.config file such as where the IP address is that found within the Windows host file.

After editing and saving the host file restart the Schneider Electric services and perform an iisreset to verify that alarm and event data is pulling in successfully.

Scenario / Resolution 4:

In some cases, the available system RAM is very low, it will not cause Web Applications to fail, but the Active Alarm Viewer will not load the alarms. When viewing the Web Application log (right click "Setting" in the Web Application interface) you see the following error:
"AlarmViewerDisplayPanelViewModel encountered an error loading Alarms from the server. System.Exception: Error"

If you check the RAM in Task Manager, you'll see the available RAM is very low. Normally, restarting the server will fix this issue. Other than that, you can limit the memory available for SQL server (see FA213995), or if the server is under specified, please add RAM to match the system specifications.

Scenario / Resolution 5:

*Note: Irreparable database damage can occur. These procedures should only be performed by users familiar with SQL Server Management Studio. Databases should be backed up prior to performing this procedure.* 

If an event string has non alphanumeric characters, the error message can display once each time a filter is changes and the event is included in results.
The solution is to update the string to not include special characters. Use the script below to find the event string with special characters.

Use ION_Data
Select [ID], [String] From EventString where not [String] like '%[^a-zA-Z0-9 ]%'

Update EventString
Set [String] = 'Unknown Event error'
where ID = (use ID returned from previous query)

Scenario / Resolution 6:

During system upgrades from PME 7.x to 8.1 it's possible for a device to become listed twice as both a downstream and physical device.  The Application Modules database runs a stored procedure against the ION_Network database in order to pull the source information named 'spDSD_GetAllSourcesMetaDataDescription'.  We can manually run this stored procedure in order to review the entries for duplicates.  

*Note: Irreparable database damage can occur. These procedures should only be performed by users familiar with SQL Server Management Studio. Databases should be backed up prior to performing this procedure.* 

1) Expand Databases < ION_Network < Programmability < Stored Procedures, right click spDSD_GetAllSourcesMetaDataDescription, and select Modify.
2) Add 'ORDER BY SystemName ASC' after the last line in the code and hit 'Execute'.  This will update the procedure to sort the list of sources alphabetically.
3) Right click spDSD_GetAllSourcesMetaDataDescription, select 'Execute Stored Procedure...', and click okay on the new pop up window.
4) Review the results list which will display similar to that shown below.



5) If a device displays as both a physical type and downstream device there are two options available.  If the device is in fact a physical source then its source category type will need to be updated within the ION_Network.dbo.SRC_Source table using a query similar to that shown below.

Update ION_Network.dbo.SRC_Source set SourceCategoryID = 3 where SourceID = x (where x is the ID row from the SRC_Source table)

This will change its source category from 5 (downstream) to 3 (physical).  On the other hand if it is determined that the source really is a downstream device then you must delete the entry from the device table. This table is for physical devices only and downstream devices are not considered physical devices. 

Delete from ION_Network.dbo.Device where ID = x (where x is the ID row from the Device table)

Once you have made the above changes to ION_Network:

6) Shut down the ApplicationModules services.
7) Run the T-SQL code below to clean out any cached data in the application modules data base

use ApplicationModules
Delete from datastore.TicketResultReference
Delete from DataStore.TicketResult

8) Right click spDSD_GetAllSourcesMetaDataDescription, select Modify, remove the 'ORDER BY SystemName ASC' line at the end of the procedure, and hit 'Execute' to restore it to the original format.

8) Start up the application modules services and log into the web client and test.
Was this helpful?
What can we do to improve the information ?