Automations and Polling Interval Variability

[5ur3n]

Hi there

After a bit of messing about with my AX Pro, I have discovered a way to get motion detection events even when the alarm is not armed. This has spectacular automation and energy saving potential. I have described it here: https://community.home-assistant.io/t/hikvision-ax-pro-alarm/541882/5?u=5ur3n

However, to do something like turn the lights on when motion is detected, I've had to set the polling interval down to 1-2 seconds, but this causes the alarm to behave erratically, for instance,

• I sometimes have to try multiple times to open gates or disarm, even with the keyfob.
• The latency of loading the web ui or refreshing the app is a lot higher
• Sometimes the alarm refuses to respond to a silence alarm for a minute or more.
• PIRCam picture on demand times out in the HikConnect app.

My assumption here is that with 45-odd devices on the AX Pro, refreshing frequently might be maxing out the CPU or other resources and worsening latency.

I'm not very familiar with the ISAPI interfaces, but is it possible to create a workaround for this problem? Some ideas that could perhaps work:

• have an asynchronous update back to Hass for a specific sensor
• perhaps a group of sensors that are polled with higher frequency than the others
• I'm not sure if the implementation is refreshing all configs when it refreshes or merely updating statuses for sensors it is already aware of, but perhaps minimizing the volume of calls will help.
• I'm not sure if there is something like a CPU usage call but there isn't anything obvious in HikConnect to help with this.

My hypothesis here is that load reduction would mitigate the erratic behavior by reducing load on the hub with frequent calls. Of course, I have very little data to support this since there are no errors in the logs that I have seen.

What are your thoughts? Is this worth thinking about given the potential for smart automation?

[petrleocompel]

This issue is being tracked basically from start. #2

As far as I know there is no API how to monitor the CPU Usage.
There is a SSH but I had not time to discover what we can do.

Workaround is basically impossible.

• no API for "specific" sensors
• on update we are updating "statuses" not configs. Configs are updated only on start currently
• If you use even "camera" monitoring on the device (linked cameras) it will put load on the CPU

All of that is a reason why default pull interval is 30 seconds. Because it can cause overload.

You can get a lot of "why something does not work as expected" from this picture

[5ur3n]

Thank you @petrleocompel that makes sense to me. I have a spare hub so I'll explore a bit what is possible with SSH, security logs and perhaps the hardware interfaces on the device like RS232 or SIA.

[5ur3n]

I just wanted to check in... I've not found a way to do this with ARC protocols. The AX Pro does not seem to forward these sorts of detection alerts.

But, do you know if the AX Pro supports the following? This seems to be implemented on cameras and NVRs, but did you ever try this on the AX Pro previously?

/ISAPI/Event/notification/alertStream

[5ur3n]

I just wanted to check in... I've not found a way to do this with ARC protocols. The AX Pro does not seem to forward these sorts of detection alerts.

But, do you know if the AX Pro supports the following? This seems to be implemented on cameras and NVRs, but did you ever try this on the AX Pro previously?

/ISAPI/Event/notification/alertStream

[petrleocompel]

@5ur3n it is very rude to send the message 5 times...

[petrleocompel]

It is a continual HTTP long-pull stream undocumented for this type of device but it responds.

UnArmed system

{ "ipAddress": "192.168.X.X", "portNo": 80, "protocol": "HTTP", "macAddress": "XX", "channelID": 1, "dateTime": "2024-12-12T14:54:23+01:00", "activePostCount": 1, "eventType": "cidEvent", "eventState": "inactive", "eventDescription": "CID event", "deviceID": "XX" }

I will only technically work with "alarm triggering". Which would still be amazing but not enough for "sensors"

But you would get "real-time" alarm trigger.

[petrleocompel]

Sadly for us.
For "arming" and "disarming" it is the same event.

{
    "ipAddress": "x",
    "portNo": 80,
    "protocol": "HTTP",
    "macAddress": "x",
    "channelID": 1,
    "dateTime": "2024-12-12T15:00:59+01:00",
    "activePostCount": 1,
    "eventType": "cidEvent",
    /// Active until any zone is "armed"  even last disarming event is still active
    "eventState": "active", 
    "eventDescription": "CID event",
    "uuid": "x",
    "deviceID": "username",
    "CIDEvent": {
        "code": 3401,
        "name": "username",
         //// EVENT
        "type": "armAndDisarm",
        "trigger": "2024-12-12T15:00:57+01:00",
        "upload": "2024-12-12T15:00:59+01:00",
        "system": 1,
        "subSystemName": "AREA 1"
    }
}

But Seems trigger events are coming in live - But only "Armed"

{
    "ipAddress": "x",
    "portNo": 80,
    "protocol": "HTTP",
    "macAddress": "x",
    "channelID": 1,
    "dateTime": "2024-12-12T15:10:02+01:00",
    "activePostCount": 1,
    "eventType": "cidEvent",
    "eventState": "active",
    "eventDescription": "CID event",
    "uuid": "x",
    "deviceID": "",
    "CIDEvent": {
        "code": 1103,
        "name": "",
        "type": "zoneAlarmTamper",
        "trigger": "2024-12-12T15:09:59+01:00",
        "upload": "2024-12-12T15:10:02+01:00",
        "system": 10,
        // Triggered zone
        "subSystemName": "Area 1",
        "zone": 1,
        "zoneCompatible": true
    }
}

System does not stop sending those but does not indicate in any "state" that alarm is triggered.
So if zoneAlarmTamper will appear alarm is triggered. (only logic we can apply)

To disable new armAndDisarm event has to come in and then

{
    "ipAddress": "192.168.X.X",
    "portNo": 80,
    "protocol": "HTTP",
    "macAddress": "XX",
    "channelID": 1,
    "dateTime": "2024-12-12T14:54:23+01:00",
    "activePostCount": 1,
    "eventType": "cidEvent",
    /// Inactive alarm
    "eventState": "inactive",
    "eventDescription": "CID event",
    "deviceID": "XX"
}

[uvera]

There seems to be something related to ARC / listening mode in docs.

Maybe it's possible to listen for sensor events via ARC? One would have to implement the ARC reciever I guess?

[petrleocompel]

I am unsure if that is for all events. I think that is only for events during armed mode.
I know it says when alarm is triggered or event occurred, the device automatically uploads the alarm but ...

the ARC Json response object

{
  "SendARC":{
    "alarmTamperEnabled": , 
/*optional, boolean type, whether to enable alarm and tampering event notification: "true"-yes, "false"-no*/
    "lifeSecurityEnabled": , 
/*optional, boolean type, whether to enable life security event notification: "true"-yes, "false"-no*/
    "systemStatusEnabled": , 
/*optional, boolean type, whether to enable system status event notification: "true"-yes, "false"-no*/
    "operateEventEnabled": ,
/*optional, boolean type, whether to enable operation event notification: "true"-yes, "false"-no*/
    "zoneAlarmTamperEnabled": , 
/*optional, boolean, whether to enable alarm and tampering event notification of the supported zone: "true"-yes, "false"-no*/
    "exDevTamperEventEnabled": , 
/*optional, boolean, whether to enable peripheral tampering alarm notification: "true"-yes, "false"-no*/
    "hostTamperEventEnabled": , 
/*optional, boolean, whether to enable tampering alarm notification of security control panel: "true"-yes, "false"-no*/
    "emergencyEventEnabled": , 
/*optional, boolean, whether to enable panic alarm notification: "true"-yes, "false"-no*/
    "medicalEventEnabled": , 
/*optional, boolean, whether to enable medical alarm notification: "true"-yes, "false"-no*/
    "gasEventEnabled": , 
/*optional, boolean, whether to enable gas alarm notification: "true"-yes, "false"-no*/
    "fireEventEnabled": , 
/*optional, boolean, whether to enable fire alarm notification: "true"-yes, "false"-no*/
    "hostStatusEventEnabled": , 
/*optional, boolean, whether to enable notification of security control panel status: "true"-yes, "false"-no*/
    "exDevStatusEventEnabled": , 
/*optional, boolean, whether to enable peripheral status notification: "true"-yes, "false"-no*/
    "detectorStatusEventEnabled": ,
/*optional, boolean, whether to enable detector status notification: "true"-yes, "false"-no*/
    "intelligentAlarmEnable": 
/*optional, boolean, whether to enable smart alarm notification: "true"-yes, "false"-no*/
  }
}

Is kinda flat. It does not contain any information about "what sensor". Only true/false. Only way how to get more info in that moment is instantly update all affected tempered devices.

I can play around with that when I will be on site later but still seems not good enough.
During the armed state we have /ISAPI/Event/notification/alertStream that is amazing but otherwise seem still a little wanky.