Cisco Prime 3.1 - Alarms by Site/Location

• Trying to develop a way to see which sites/locations within Prime have got critical alarms using the REST API. Want to use this to understand which sites have got access points offline (for reporting purposes). Access points that are offline generate a critical alarm.
• Thought could query the /webacs/api/v1/op/groups/sites node of the REST API.
•  According to the documentation, this should retrieve all of the sites as well as any critical alarms associated with those sites. The logic is that if an access point is down at one of those sites, it should be included in the critical alarm count against the site.
• The issue hitting is that some fields like alarms and device count are always zero for every site, even though the site has critical alarms or access points offline and could see alarms in the Prime GUI.

   <siteOpDTO>

    <apCount>2</apCount>

    <clearedAlarms>0</clearedAlarms>                          <-------------------- this is always zero

    <clientCount>15</clientCount>

    <criticalAlarms>0</criticalAlarms>                          <-------------------- this is always zero

    <deviceCount>0</deviceCount>

    <groupId>14582291326</groupId>

    <groupName>Third Floor</groupName>

    <informationAlarms>0</informationAlarms>

    <latitude>0.0</latitude>

    <longitude>0.0</longitude>

    <majorAlarms>0</majorAlarms>                          <-------------------- this is always zero

    <minorAlarms>0</minorAlarms>                          <-------------------- this is always zero

    <name>Location/All Locations/Hotels/BigHotel</name>

    <siteType>Floor Area</siteType>

    <warningAlarms>0</warningAlarms>                          <-------------------- this is always zero

  </siteOpDTO>

In 3.1.x the behavior is that AP related alarms are reported to the site where the controller is located.  Since your device count in that site is 0 (indicating that the controller is not located here), it's expected that the alarms for the down APs will not be reported here.  This should be consistent across the UI and API.  We realize that this is not optimal behavior, so in 3.2 (which has recently been posted to cisco.com for download) we changed the behavior to report these AP-specific alarms in the site where the AP is located.