NewAlarmMessageHandler() not getting invoked for access control alarms on 2023 R3 with the latest patch installed

I have written an access control plugin which works perfectly fine on 2022 R3. When it came to 2023 R3 there were issues regarding alarmclient. When the latest patch was applied it sorted out few issues, but one issue is still persisting. If we take the 2022R3 logs , we could see on the highlight that NewAlarmMessageHandler() has been invoked.

But when the same plugin is installed on 2023 R3 it doesnt invoke th NewAlarmMessageHandler() even after the latest patch installation which claims to fix the issue with alarmclient. This leaves the plugin unusable on 2023 R3. The below log shows no signs of NewAlarmMessageHandler being invoked even though the alarm is visible on Alarm Manager on Smart client.

Did anyone faced similar issue? If so whare are your suggestions

NewAlarmMessageHandler isn’t a part of the MIP SDK but your code. Please add a note on what you subscribe to and how.

Is this an Event Server plugin?

Regarding the bug..

https://developer.milestonesys.com/s/article/Getting-Alarm-list-error-occurred-when-verifying-security-for-message-troubleshooting

On applying the fix, can you verify that you use the new NuGet and apply patches to all the environments? It is a bit drastic this bug in that you need to use new NuGet and patch Event Server, Management Client and Smart Client..

I am subscribing to NewAlarmIndication

_newAlarmObject = _messageCommunication.RegisterCommunicationFilter(NewAlarmMessageHandler,

      new VideoOS.Platform.Messaging.CommunicationIdFilter(VideoOS.Platform.Messaging.MessageId.Server.NewAlarmIndication), null, EndPointType.Server);

Is this an Event Server plugin? (It is important for us to understand what environment you see this, so is your code executing in Event Server, Smart Client, Management Client or standalone?)

Yes , this plugin runs under event server

Can you confirm you use the newest MIP SDK (NuGet)?

We will try to reproduce.

The MIPSDK version is v4.0.30319

Please build using the newest MIP SDK..

https://www.nuget.org/profiles/milestonesys

I suspect it will not make a difference but please try and let me know.

I cannot reproduce.

Do you get alarms that are not Access Control alarms or do you never get any alarms whatsoever?

Here is a guide on general troubleshooting - https://developer.milestonesys.com/s/article/debugging-techniques-for-Event-Server-plugins

You have shown some MIP Logs, I wonder if you have examined the general Event Server logs for error messages that might give clues for the issue. - [C:\ProgramData\Milestone\XProtect](file:C:/ProgramData/Milestone/XProtect) Event Server\logs

Please find the below video on how to reproduce this issue with the samples from MIPSDK Component and plugin samples

https://drive.google.com/file/d/1az5kGrDEtJaHSgytI90egoX7Ed9w1JXd/view?usp=drive_link

I am able to get alarms that are not access control

Thank you for the video. I will test this way and let you know what I find.

I asked if this was an Event Server plugin and tested with that, no issue.

You show me a reproduction, where you do not use a Event Server plugin but a standalone application, the Alarm Event Viewer sample. Testing in standalone I can reproduce the issue. As there is a plugin involved when deploying the access control I think we misunderstood each other.

Thank you for reporting this, I will make a report to Milestone Development and let you know what they find.

Thank you for the efforts

Yes , My code is a plugin that runs under Event Server and it has been running successfully for past couple of years till 2022 R3.

I the demo video also I am using “DemoAccessControlPlugin” from MIPSDK samples.

The Standalone application contains the listener code which listens to the Events and alarms and updates the grid view. In my case the listener code goes inside the same plugin.

Here goes my listener code, where the first log is not written in 2023 R3 but the same works without any issues in 2022 R3 , which made me suspect that the listener for “NewAlarmIndication” is not triggered as expected on 2023 R3 with the latest cummulative patch:

private object NewAlarmMessageHandler(VideoOS.Platform.Messaging.Message message, FQID dest, FQID source)

{

  Alarm alarm = message.Data as Alarm;

  **ACUtil.Log(false, "NewAlarmMessageHandler()", alarm.EventHeader.Message + " from source : " + [alarm.EventHeader.Source.Name](https://alarm.EventHeader.Source.Name));**

  try

  {

    var configset = db.GetCollection<ConfigurationSet>("ConfigurationSet").FindAll();

    //For alarms that are not listed in the config file

    if (!alarm.EventHeader.Message.Contains(":-"))

    {

      var mapCollection = db.GetCollection<VelocityToVisionMapper>("VelocityToVisionMapper");

      DateTime LocalEventTime = TimeZone.CurrentTimeZone.ToLocalTime(alarm.EventHeader.Timestamp);

      ACUtil.Log(false, "Searching VV internals for :", LocalEventTime.ToString() + " " + alarm.EventHeader.Message + " from " + [alarm.EventHeader.Source.Name](https://alarm.EventHeader.Source.Name));

      //BaseEventStorage BES = null;

      int baseEventId = 0;

      bool foundBES = false;

      int count = 0;

      string typeName = "Access Control System Event";

      if (alarm.EventHeader.Type.ToLower() == typeName.ToLower())

      {

        alarmClient = \_alarmClientManager.GetAlarmClient(EnvironmentManager.Instance.MasterSite.ServerId);

        EventLine\[\] events = alarmClient.GetEventLines(0, 100, ConfigureEventFilter(alarm.EventHeader.Timestamp));

        if (events.Length == 0)

        {

          events = alarmClient.GetEventLines(0, 100, ConfigureEventFilter(LocalEventTime));

        }

        foreach (var evt in events)

        {

          if (evt.Message.ToLower() == alarm.EventHeader.Message.ToLower())

          {

            BaseEvent baseevent = alarmClient.GetEvent([evt.Id](https://evt.Id));

            AccessControlEvent ac = baseevent as AccessControlEvent;

            string id = ac.AccessControlSystemEventId;

            int velocityAlarmID;

            bool parsingstatus = int.TryParse(id, out velocityAlarmID);

            if ((parsingstatus) && (!visitedBaseEvents.Contains(velocityAlarmID)))

            {

              baseEventId = velocityAlarmID;

              foundBES = true;

              foreach (var item in db.GetCollection<BaseEventStorage>().FindAll())

              {

                if (item.BaseEventID == baseEventId)

                {

                  visitedBaseEvents.Add(baseEventId);

                  item.visited = true;

                  db.GetCollection<BaseEventStorage>().Update(item);

                }

              }

              ACUtil.Log(false, "NewAlarmEventHandler()", "Found base event from Velocity Vision internals : " + velocityAlarmID);

              break;

            }

            else

            {

              ACUtil.Log(false, "NewAlarmEventHandler()", " Couldnt find base event");

            }

          }

        }

  //Some more logic

  }

  catch (Exception Ex)

  {

    ACUtil.Log(true, " NewAlarmMessageHandler()", Ex.StackTrace.ToString());

  }

  return null;

}

if you have the issue in an Event Server plugin and Milestone solves the issue for standalone the fix will not help you.

In your Event Server plugin which references do you have?

VideoOS.Platform.AccessControl you must have.

Do you have also VideoOS.Platform?

Do you have other references from Milestone?

Now that you put the NewAlarmMessageHandler, I am curious, could you explain in words what it does for you?

I have both VideoOS.Platform and VideoOS.Platform.AccessControl in the plugin references. Also I suspect that the issue is with how the MIPSDK triggers the listener function in response to the AccessControl Alarm rather than the issue with the sample itself as the same listener is invoked fine with 2022 R3.

My listener function gathers information from the new Alarm and creates a map in an in-memory database for future reference

I have asked questions in the Support Case you have.

We can later update this thread if a fix of general interest is developed..