Automations and Polling Interval Variability
Opened this issue · 7 comments
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?
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
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.
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
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 it is very rude to send the message 5 times...
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.
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"
}