NVR support

[kukulich]

Is it possible to support NVR? It would be nice to add one device (NVR) and all info about cameras would be detected automatically.

It should also solve a problem when cameras cannot be added because they are connected via NVR and NVR use specific custom IP addresses for them - and the IP addresses are not usable directly.

[rroller]

I think that's doable. But I don't have an nvr and I'd need one to build out the functionality.

[kukulich]

I can help with debugging and testing. Is there a list of API somewhere?

[rroller]

The problem is that I need an actual NVR so I can do edit-test cycles locally to get all the APIs correct. Without that I have no idea if my code would work or even where to start. I have to play around with the APIs to understand them and for that I need an NVR unit.

[kukulich]

I have already tested some API:

/cgi-bin/magicBox.cgi?action=getSystemInfo

deviceType=31
processor=ST7108
serialNumber=4F07335PAZEEA9B
updateSerial=NVR2X-4KS3

/cgi-bin/magicBox.cgi?action=getSoftwareVersion

version=4.001.0000005.0,build:2020-11-17

/cgi-bin/magicBox.cgi?action=getMachineName

name=NVR

/cgi-bin/magicBox.cgi?action=getVendor

vendor=Dahua

But I don't know what I should test next... If you can guide me, I may be able to send a PR...

[kukulich]

/cgi-bin/magicBox.cgi?action=getDeviceType

type=DHI-NVR2108-8P-4KS2

/cgi-bin/magicBox.cgi?action=getDeviceClass

class=NVR

[kukulich]

This looks like a way to detect number of channels/cameras:

/cgi-bin/configManager.cgi?action=getConfig&name=VideoColor

table.VideoColor[0][0].Brightness=50
table.VideoColor[0][0].ChromaSuppress=50
table.VideoColor[0][0].Contrast=50
table.VideoColor[0][0].Gamma=50
table.VideoColor[0][0].Hue=50
table.VideoColor[0][0].Saturation=50
table.VideoColor[0][0].Style=Standard
table.VideoColor[0][0].TimeSection=1 00:00:00-24:00:00
table.VideoColor[0][1].Brightness=50
table.VideoColor[0][1].ChromaSuppress=50
table.VideoColor[0][1].Contrast=50
table.VideoColor[0][1].Gamma=50
table.VideoColor[0][1].Hue=50
table.VideoColor[0][1].Saturation=50
table.VideoColor[0][1].Style=Standard
table.VideoColor[0][1].TimeSection=0 00:00:00-24:00:00
table.VideoColor[0][2].Brightness=50
table.VideoColor[0][2].ChromaSuppress=50
table.VideoColor[0][2].Contrast=50
table.VideoColor[0][2].Gamma=50
table.VideoColor[0][2].Hue=50
table.VideoColor[0][2].Saturation=50
table.VideoColor[0][2].Style=Standard
table.VideoColor[0][2].TimeSection=0 00:00:00-24:00:00
table.VideoColor[1][0].Brightness=50
table.VideoColor[1][0].ChromaSuppress=50
table.VideoColor[1][0].Contrast=50
table.VideoColor[1][0].Gamma=50
table.VideoColor[1][0].Hue=50
table.VideoColor[1][0].Saturation=50
table.VideoColor[1][0].Style=Standard
table.VideoColor[1][0].TimeSection=1 00:00:00-24:00:00
table.VideoColor[1][1].Brightness=50
table.VideoColor[1][1].ChromaSuppress=50
table.VideoColor[1][1].Contrast=50
table.VideoColor[1][1].Gamma=50
table.VideoColor[1][1].Hue=50
table.VideoColor[1][1].Saturation=50
table.VideoColor[1][1].Style=Standard
table.VideoColor[1][1].TimeSection=0 00:00:00-24:00:00
table.VideoColor[1][2].Brightness=50
table.VideoColor[1][2].ChromaSuppress=50
table.VideoColor[1][2].Contrast=50
table.VideoColor[1][2].Gamma=50
table.VideoColor[1][2].Hue=50
table.VideoColor[1][2].Saturation=50
table.VideoColor[1][2].Style=Standard
table.VideoColor[1][2].TimeSection=0 00:00:00-24:00:00
table.VideoColor[2][0].Brightness=50
table.VideoColor[2][0].ChromaSuppress=50
table.VideoColor[2][0].Contrast=50
table.VideoColor[2][0].Gamma=50
table.VideoColor[2][0].Hue=50
table.VideoColor[2][0].Saturation=50
table.VideoColor[2][0].Style=Standard
table.VideoColor[2][0].TimeSection=1 00:00:00-24:00:00
table.VideoColor[2][1].Brightness=50
table.VideoColor[2][1].ChromaSuppress=50
table.VideoColor[2][1].Contrast=50
table.VideoColor[2][1].Gamma=50
table.VideoColor[2][1].Hue=50
table.VideoColor[2][1].Saturation=50
table.VideoColor[2][1].Style=Standard
table.VideoColor[2][1].TimeSection=0 00:00:00-24:00:00
table.VideoColor[2][2].Brightness=50
table.VideoColor[2][2].ChromaSuppress=50
table.VideoColor[2][2].Contrast=50
table.VideoColor[2][2].Gamma=50
table.VideoColor[2][2].Hue=50
table.VideoColor[2][2].Saturation=50
table.VideoColor[2][2].Style=Standard
table.VideoColor[2][2].TimeSection=0 00:00:00-24:00:00
table.VideoColor[3][0].Brightness=50
table.VideoColor[3][0].ChromaSuppress=50
table.VideoColor[3][0].Contrast=50
table.VideoColor[3][0].Gamma=50
table.VideoColor[3][0].Hue=50
table.VideoColor[3][0].Saturation=50
table.VideoColor[3][0].Style=Standard
table.VideoColor[3][0].TimeSection=1 00:00:00-24:00:00
table.VideoColor[3][1].Brightness=50
table.VideoColor[3][1].ChromaSuppress=50
table.VideoColor[3][1].Contrast=50
table.VideoColor[3][1].Gamma=50
table.VideoColor[3][1].Hue=50
table.VideoColor[3][1].Saturation=50
table.VideoColor[3][1].Style=Standard
table.VideoColor[3][1].TimeSection=0 00:00:00-24:00:00
table.VideoColor[3][2].Brightness=50
table.VideoColor[3][2].ChromaSuppress=50
table.VideoColor[3][2].Contrast=50
table.VideoColor[3][2].Gamma=50
table.VideoColor[3][2].Hue=50
table.VideoColor[3][2].Saturation=50
table.VideoColor[3][2].Style=Standard
table.VideoColor[3][2].TimeSection=0 00:00:00-24:00:00
table.VideoColor[4][0].Brightness=50
table.VideoColor[4][0].ChromaSuppress=50
table.VideoColor[4][0].Contrast=50
table.VideoColor[4][0].Gamma=50
table.VideoColor[4][0].Hue=50
table.VideoColor[4][0].Saturation=50
table.VideoColor[4][0].Style=Standard
table.VideoColor[4][0].TimeSection=1 00:00:00-24:00:00
table.VideoColor[4][1].Brightness=50
table.VideoColor[4][1].ChromaSuppress=50
table.VideoColor[4][1].Contrast=50
table.VideoColor[4][1].Gamma=50
table.VideoColor[4][1].Hue=50
table.VideoColor[4][1].Saturation=50
table.VideoColor[4][1].Style=Standard
table.VideoColor[4][1].TimeSection=0 00:00:00-24:00:00
table.VideoColor[4][2].Brightness=50
table.VideoColor[4][2].ChromaSuppress=50
table.VideoColor[4][2].Contrast=50
table.VideoColor[4][2].Gamma=50
table.VideoColor[4][2].Hue=50
table.VideoColor[4][2].Saturation=50
table.VideoColor[4][2].Style=Standard
table.VideoColor[4][2].TimeSection=0 00:00:00-24:00:00
table.VideoColor[5][0].Brightness=50
table.VideoColor[5][0].ChromaSuppress=50
table.VideoColor[5][0].Contrast=50
table.VideoColor[5][0].Gamma=50
table.VideoColor[5][0].Hue=50
table.VideoColor[5][0].Saturation=50
table.VideoColor[5][0].Style=Standard
table.VideoColor[5][0].TimeSection=1 00:00:00-24:00:00
table.VideoColor[5][1].Brightness=50
table.VideoColor[5][1].ChromaSuppress=50
table.VideoColor[5][1].Contrast=50
table.VideoColor[5][1].Gamma=50
table.VideoColor[5][1].Hue=50
table.VideoColor[5][1].Saturation=50
table.VideoColor[5][1].Style=Standard
table.VideoColor[5][1].TimeSection=0 00:00:00-24:00:00
table.VideoColor[5][2].Brightness=50
table.VideoColor[5][2].ChromaSuppress=50
table.VideoColor[5][2].Contrast=50
table.VideoColor[5][2].Gamma=50
table.VideoColor[5][2].Hue=50
table.VideoColor[5][2].Saturation=50
table.VideoColor[5][2].Style=Standard
table.VideoColor[5][2].TimeSection=0 00:00:00-24:00:00
table.VideoColor[6][0].Brightness=50
table.VideoColor[6][0].ChromaSuppress=50
table.VideoColor[6][0].Contrast=50
table.VideoColor[6][0].Gamma=50
table.VideoColor[6][0].Hue=50
table.VideoColor[6][0].Saturation=50
table.VideoColor[6][0].Style=Standard
table.VideoColor[6][0].TimeSection=1 00:00:00-24:00:00
table.VideoColor[6][1].Brightness=50
table.VideoColor[6][1].ChromaSuppress=50
table.VideoColor[6][1].Contrast=50
table.VideoColor[6][1].Gamma=50
table.VideoColor[6][1].Hue=50
table.VideoColor[6][1].Saturation=50
table.VideoColor[6][1].Style=Standard
table.VideoColor[6][1].TimeSection=0 00:00:00-24:00:00
table.VideoColor[6][2].Brightness=50
table.VideoColor[6][2].ChromaSuppress=50
table.VideoColor[6][2].Contrast=50
table.VideoColor[6][2].Gamma=50
table.VideoColor[6][2].Hue=50
table.VideoColor[6][2].Saturation=50
table.VideoColor[6][2].Style=Standard
table.VideoColor[6][2].TimeSection=0 00:00:00-24:00:00
table.VideoColor[7][0].Brightness=50
table.VideoColor[7][0].Contrast=50
table.VideoColor[7][0].Hue=50
table.VideoColor[7][0].Saturation=50
table.VideoColor[7][0].TimeSection=1 00:00:00-24:00:00
table.VideoColor[7][1].Brightness=50
table.VideoColor[7][1].Contrast=50
table.VideoColor[7][1].Hue=50
table.VideoColor[7][1].Saturation=50
table.VideoColor[7][1].TimeSection=0 00:00:00-24:00:00

[alanpilz]

I’m also interested in the NVR integration. I have a Dahua 4108 NVR, installed this great integration and I see “main” camera added and I have a preview of one of the cameras. But only one camera is visible. I simply added the IP of the dahua NVR and it detected 1 Device with 5 entities.

[kukulich]

I'll try to prepare PR.

[frapersan]

I have a nvr (dahua hcvr5108hs-s3) when I configure the integration it works, but on the integrations page it appears as:

no warning appears in the logs.

I can help, I am fully available

[chali272]

im also using dahua nvr and like to see it supported, when adding the nvr today im getting one camera.

[kukulich]

I did not find any API to detect number of cameras... However it may be possible to detect if the device is NVR (via getDeviceClass) so the best option would be to add second config_flow step - user can specify the number of cameras/channels by itself.

[Mikefila]

Okay So I was going through the code and in camera.py I saw this

For now we'll only support 1 channel. I don't have any cams where I can test a second channel.
I'm not really sure what channel 2 means anyways, it doesn't seem to be the substream.
CHANNEL = 1

Channel refers to dvr/xvr/nvr channels. subtype denotes main(0)/sub stream(1) Rtsp streams are in the form of
rtsp://<username>:<password>@<ip>:<port>/cam/realmonitor?channel=1&subtype=0

Channels are offset by one. Channel 0 = Camera 1; 1=2; 2=3 etc.

I use this right now and I am able to get all events from an xvr running 11 analog cameras.

https://github.com/algirdasc/appdaemon-apps/blob/master/dahua_mqtt.py

[Mikefila]

Probably the most important part, the only thing I had to modify was a setting. Instead of defining a camera in the form of camera/1 I removed the number and just used camera

[chali272]

Okay So I was going through the code and in camera.py I saw this

For now we'll only support 1 channel. I don't have any cams where I can test a second channel.
I'm not really sure what channel 2 means anyways, it doesn't seem to be the substream.
CHANNEL = 1

Channel refers to dvr/xvr/nvr channels. subtype denotes main(0)/sub stream(1) Rtsp streams are in the form of
rtsp://<username>:<password>@<ip>:<port>/cam/realmonitor?channel=1&subtype=0

Channels are offset by one. Channel 0 = Camera 1; 1=2; 2=3 etc.

I use this right now and I am able to get all events from an xvr running 11 analog cameras.

https://github.com/algirdasc/appdaemon-apps/blob/master/dahua_mqtt.py

noob questone, what file is this replacing in the Dahua folder/whats should your file be named as? (i cant see any file named dahua_mqtt.py)

[Mikefila]

I'm sorry if I was unclear, I did not change anything on this integration nor do I have it working.

The link I posted is a different integration all together. It works through appdaemon. I only referenced so the maintainer of this integration has a working example of a script that will log on to a nvr/dvr/xvr. Perhaps it maybe helpful.

Follow this post for details of the other integration, if you have further questions please post them to that thread. I'm subscribed and will answer there as not to derail this thread.

https://community.home-assistant.io/t/dahua-ipc-to-mqtt-app/93327/174?u=mikefila

[fokcuk]

what is this section undr init.py?
def init(self, hass: HomeAssistant, events: list, address: str, port: int, rtsp_port: int, username: str,
password: str) -> None:
"""Initialize."""
self.client: DahuaClient = DahuaClient(username, password, address, port, rtsp_port,
async_get_clientsession(hass))
self.dahua_event: DahuaEventThread
self.platforms = []
self.initialized = False
self.model = ""
self.machine_name = ""
self.connected = None
self.channels = {"1": "1"}
self.events: list = events

If we use NVR address, it works and events are registered, but only for channel 1. Also there is no way to modify entity name, so even if we modify the channel in the code, it will link it to the same one.

[rroller]

Yeah I have a hard coded channel coded through the code. I can make that an option when configuring the integration to allow you to pick the channel. I think that will work.

[fokcuk]

Yeah I have a hard coded channel coded through the code. I can make that an option when configuring the integration to allow you to pick the channel. I think that will work.

And make am option for entity name pick, otherwise it assigns the same name to the same NVR when adding and no option to change it.
Which file picks the channel for events? I saw in one there is 1:1 for a channel, but don't know it its a start:end (like 1:5) or if you want a particular channel you have to select 2:2, 3:3 etc

[rroller]

I'm close to completing a change that allows one to set the name during configuration time. This will be the building blocks needed to support channels.

It's basically the same configuration form now, but after you click submit, it'll open a new form with the name of the camera and lets you edit it.

[fokcuk]

great! thank you.
How does it get the motion events? I thought I changed the channel info in the code but I think it reads any motion event and NVR will have different events for different channels/cameras

[fokcuk]

Platform dahua does not generate unique IDs. ID 3CPAZ5EF403317U_motion_detection already exists - ignoring switch.nvr_motion_detection
Platform dahua does not generate unique IDs. ID 3CPAZ5EF403317U_disarming already exists - ignoring switch.nvr_disarming

Can you please add the sensor unique IDs as well?

[haid45]

I'm close to completing a change that allows one to set the name during configuration time. This will be the building blocks needed to support channels.

It's basically the same configuration form now, but after you click submit, it'll open a new form with the name of the camera and lets you edit it.

@rroller Ill be eager to test this when you have finished.

[rroller]

Thanks. I'll make this the next thing I work on. I need to un-hard-code all the channels I currently have hard coded

[haid45]

Amazing, I'm readily available to test this out for you. I currently have an NVR installed with 4 cameras (channels). The integration is able to pick up just the main channel at the moment.

[rroller]

@haid45 when you added your camera, for the IP address, do you use your NVR IP Address? I assume you don't use the IP of the camera? So you'd be adding 4 camera's all with the IP of your NVR?

[haid45]

@rroller, yes I used the IP address of the NVR as I wasn't able to get the individual ip's of the cameras. Well actually, I was but they seemed to be on a local network within the NVR because the ip's where along the lines of 10.0.0.1.
Adding the 4 cameras with IP of the NVR is definitely the end game here.

[rroller]

Awesome, this is totally doable. I'm working on the changes now.

[haid45]

How exciting! looking forward to trying it out 🥳

[Mikefila]

Hi I just installed this today for an XVR. I am able to add additional cameras, however, all the motion events for the cameras are tied together. When one has motion they are all triggered. I also noticed that the cross region detection is randomly firing and not reflecting actual events.

I use dahua to mqtt and I am anle to see the events just fine, I had disabled it when I tried this intergration. I don't know if it's helpful but here is the yaml I use to make sensors from motion events.

 - platform: mqtt
    name: Middle Yard Motion
    state_topic: cameras
    value_template: "{{ 'ON' if value_json.code == 'VideoMotion' and value_json.action == 'Start' and value_json.index == '7' else 'OFF'}}"
    device_class: motion

  - platform: mqtt
    name: Middle Yard Tripwire
    state_topic: cameras
    value_template: "{{ 'ON' if value_json.code == 'CrossLineDetection' and value_json.action == 'Start' and value_json.index == '7' else 'OFF'}}"
    device_class: motion

  - platform: mqtt
    name: Middle Yard Intrusion
    state_topic: cameras
    value_template: "{{ 'ON' if value_json.code == 'CrossRegionDetection' and value_json.action == 'Start' and value_json.index == '7' else 'OFF'}}"
    device_class: motion

[rroller]

@Mikefila thanks. Can you enable debug logs and post me the event logs? I think I'm probably missing something when triggering events... I think I need to include a channel.

[rroller]

@Mikefila and others, I released 0.9.16 to address the events issues. Please give it a try. Now each motion event should be per cam as expected.

https://github.com/rroller/dahua/releases/tag/0.9.16

[Mikefila]

Thanks for the quick response but it is still the same, mailbox is index 1 and front garden is index 0

2021-08-28 14:17:23 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR front garden', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '0', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR front garden'}
2021-08-28 14:17:23 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR Mailbox', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '0', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR Mailbox'}
2021-08-28 14:17:39 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR front garden', 'Code': 'VideoMotion', 'action': 'Start', 'index': '0', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR front garden'}
2021-08-28 14:17:39 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR Mailbox', 'Code': 'VideoMotion', 'action': 'Start', 'index': '0', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR Mailbox'}
2021-08-28 14:18:13 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR front garden', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '0', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR front garden'}
2021-08-28 14:18:13 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR Mailbox', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '0', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR Mailbox'}

[rroller]

@Mikefila weird, all the index values are 0. I was trying to use the index to distinguish each cam's event. It looks like I could use the name?

[Mikefila]

That is because index 0 was the only camera triggered then. After walking past several cameras I get the following. Note cameras on index 2 and index 3 are not defined but do exist. I'm not sure why the are all jumbled

2021-08-28 14:29:35 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR front garden', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '1', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR front garden'}
2021-08-28 14:29:35 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR mailbox', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '1', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR mailbox'}
2021-08-28 14:29:35 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR mailbox', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '1', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR mailbox'}
2021-08-28 14:29:42 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR front garden', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '2', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR front garden'}
2021-08-28 14:29:42 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR mailbox', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '2', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR mailbox'}
2021-08-28 14:29:42 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR mailbox', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '2', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR mailbox'}
2021-08-28 14:29:45 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR front garden', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '3', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR front garden'}
2021-08-28 14:29:45 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR mailbox', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '3', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR mailbox'}
2021-08-28 14:29:45 DEBUG (MainThread) [custom_components.dahua] Cam Data received: {'name': 'XVR mailbox', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '3', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR mailbox'}

btw I removed and reinstalled the cams just to make sure the indexes were right, that is why Mailbox changed to lower case mailbox

[rroller]

Thanks, this helps a lot. I'm going to try an make another fix. I'll report back once it is ready.

[rroller]

This is the actual data that comes back from the device...

--myboundary
Content-Type: text/plain
Content-Length:127

Code=VideoMotion;action=Stop;index=0;data={
   "Id" : [ 0 ],
   "RegionName" : [ "Region1" ],
   "SmartMotionEnable" : false
}

Notice it doesn't have anything to identify the device itself. That's fine for single cams, but when we are attached to an NVR I'm not sure I know how to identify which cam the event came from.

[voskuh]

This is the actual data that comes back from the device...

--myboundary
Content-Type: text/plain
Content-Length:127

Code=VideoMotion;action=Stop;index=0;data={
   "Id" : [ 0 ],
   "RegionName" : [ "Region1" ],
   "SmartMotionEnable" : false
}

Notice it doesn't have anything to identify the device itself. That's fine for single cams, but when we are attached to an NVR I'm not sure I know how to identify which cam the event came from.

The index is the right way to know which cam triggered the event.

Would it be easier to add just one device (the dvr or nvr) and then select the channels to listen to.

[rroller]

I've just released 0.9.17 with some extra debug logs. @Mikefila can you upgrade and paste in your event logs as you did before?

[rroller]

I think I see a problem with how I've coded this. For single cams it works great. But for NVR's I'm creating a thread per channel to listen for events. Say you have 10 cams. I'll create 10 threads connected to the NVR to listen to events. Now all 10 threads will get the same events. And that's why we are seeing this duplication. Really I need a single thread to listen for events and have it dispatch to the correct cam integration

[voskuh]

I think I see a problem with how I've coded this. For single cams it works great. But for NVR's I'm creating a thread per channel to listen for events. Say you have 10 cams. I'll create 10 threads connected to the NVR to listen to events. Now all 10 threads will get the same events. And that's why we are seeing this duplication. Really I need a single thread to listen for events and have it dispatch to the correct cam integration

Yes, I think that's the problem.

[rroller]

I think I can put in a short term fix for now and work on the single thread approach (which is more involved) in a future update.

[rroller]

OK 0.9.18 is released with a short term fix that hopefully fixes this duplication issue.

[voskuh]

OK 0.9.18 is released with a short term fix that hopefully fixes this duplication issue.

As far as I can see this solved the duplication issue for now.

[Mikefila]

I'm not sure I know how to identify which cam the event came from.

I haven't installed .18 this is .17

The script i use now just basically transfers the event log to mqtt. Video Motion the only way to identify the camera is through index

2021-08-28 16:22:31 DEBUG (MainThread) [custom_components.dahua] Cam Data received from channel 1: {'name': 'XVR mailbox', 'Code': 'VideoMotion', 'action': 'Start', 'index': '6', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR mailbox'}
2021-08-28 16:22:31 DEBUG (MainThread) [custom_components.dahua] Cam Data received from channel 0: {'name': 'XVR front garden', 'Code': 'VideoMotion', 'action': 'Start', 'index': '6', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR front garden'}
2021-08-28 16:22:42 DEBUG (MainThread) [custom_components.dahua] Cam Data received from channel 1: {'name': 'XVR mailbox', 'Code': 'VideoMotion', 'action': 'Start', 'index': '5', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR mailbox'}
2021-08-28 16:22:42 DEBUG (MainThread) [custom_components.dahua] Cam Data received from channel 0: {'name': 'XVR front garden', 'Code': 'VideoMotion', 'action': 'Start', 'index': '5', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR front garden'}
2021-08-28 16:23:04 DEBUG (MainThread) [custom_components.dahua] Cam Data received from channel 1: {'name': 'XVR mailbox', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '6', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR mailbox'}
2021-08-28 16:23:04 DEBUG (MainThread) [custom_components.dahua] Cam Data received from channel 0: {'name': 'XVR front garden', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '6', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR front garden'}
2021-08-28 16:23:15 DEBUG (MainThread) [custom_components.dahua] Cam Data received from channel 1: {'name': 'XVR mailbox', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '5', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR mailbox'}
2021-08-28 16:23:15 DEBUG (MainThread) [custom_components.dahua] Cam Data received from channel 0: {'name': 'XVR front garden', 'Code': 'VideoMotion', 'action': 'Stop', 'index': '5', 'data': {'SmartMotionEnable': False}, 'DeviceName': 'XVR front garden'}

Same goes for crossRegion crossLine etc except these events can be also be named. You can have many different IVS events from a single camera and have individual triggers for each event.

2021-08-28 16:18:22 DEBUG (MainThread) [custom_components.dahua] Cam Data received from channel 1: {'name': 'XVR mailbox', 'Code': 'CrossRegionDetection', 'action': 'Stop', 'index': '3', 'data': {'Action': 'Appear', 'Class': 'Normal', 'CountInGroup': 1, 'DetectRegion': [[4168, 3111], [4405, 7778], [5916, 7510], [5388, 3160]], 'EventSeq': 46, 'FrameSequence': 1697394, 'GroupID': 0, 'IndexInGroup': 0, 'Mark': 0, 'Name': 'Full Screen', 'Object': {'Action': 'Appear', 'BoundingBox': [4096, 4888, 4608, 5448], 'Center': [4352, 5168], 'Confidence': 0, 'FrameSequence': 0, 'ObjectID': 116, 'ObjectType': 'Unknown', 'RelativeID': 0, 'Source': 0.0, 'Speed': 0, 'SpeedTypeInternal': 0}, 'PTS': 32293.0, 'RuleId': 1, 'Sequence': 0, 'Source': 0.0, 'Track': None, 'UTC': 1630167491, 'UTCMS': 0}, 'DeviceName': 'XVR mailbox'}

Where 'Name': 'Full Screen', can be a unique id for all IVS events.

This is the value template I use to get events by name, I dont need to reference the camera index

{{ 'ON' if value_json.data.Name == 'FrontTrip' and value_json.action == 'Start' else 'OFF'}}

To truncate, you can name events but not motion events.

[rroller]

@Mikefila yeah it's best to use the event bus in HA to do these automations instead of the sensors I made. The sensors work for the simple case that lots of people will use but if you have a more advanced setup then you'll need to use the event fired on the bus as you correctly point out, has all the needed data.And with the latest update I believe they are deduplicated.

[Mikefila]

This is great .18 is working separating the events. I am going to add my other cameras and I'll report if there are any issues.

I apologize, I often leave out pertinent parts but expand on details. I spent sometime sorting through the JSON from the other script, so I'm pretty familiar with the event outputs.

I though I saw you mention about using names. I wanted to explain that names can be unique but requires additional configuration by the user, so not really a viable option.

What is the event type for the cameras?

[rroller]

@Mikefila it's in the readme (let me know if it's missing anything and I'll update).. but it looks like this...

platform: event
event_type: dahua_event_received
event_data:
  name: Cam13
  Code: VideoMotion
  action: Start

You can use anything in the event data (the data you posted above). Here's an example...

{
    "event_type": "dahua_event_received",
    "data": {
        "name": "Cam13",
        "Code": "VideoMotion",
        "action": "Start",
        "index": "0",
        "data": {
            "Id": [
                0
            ],
            "RegionName": [
                "Region1"
            ],
            "SmartMotionEnable": false
        },
        "DeviceName": "Cam13"
    },
    "origin": "LOCAL",
    "time_fired": "2021-06-30T04:00:28.605290+00:00",
    "context": {
        "id": "199542fe3f404f2a0a81031ee495bdd1",
        "parent_id": null,
        "user_id": null
    }
}

[GaryOkie]

@Mikefila yeah it's best to use the event bus in HA to do these automations instead of the sensors I made. The sensors work for the simple case that lots of people will use but if you have a more advanced setup then you'll need to use the event fired on the bus as you correctly point out, has all the needed data.And with the latest update I believe they are deduplicated.

I was involved in a now defunct PR to add event handling to the Amcrest Integration. The developer had a very hard time getting it approved and gave up. One of the reasons was he added a config yaml change which was a no-no, so he went back and added config flow code, and then was told there were too many changes at once, break the PR apart.

In this PR discussion, Balloob reviewed it as well, and had this to say about events and binary sensors...

See home-assistant/core#40496 (comment)

balloob on Nov 13, 2020

Events should not be binary sensors to begin with. All events should be … events.

See https://developers.home-assistant.io/docs/integration_events

We should remove the option to define which binary sensors are added. Instead that should be controlled by the user by enabling/disabling entities in the entity registry.

In revisiting this PR I just discovered that another developer picked up where blademckain left off and was somehow able to get event handling added to the Amcrest integration. (https://www.home-assistant.io/integrations/amcrest/#events)

And I see some config yaml updates were added as well for tripwire detection as binary sensors!. Whoa. So inconsistent. No idea how that got approved

I mention all of this because there is a LOT of overlap between the Amcrest integration and your new Dahua code. I started using your code because the original code owner for Amcrest bailed out, and it lacked doorbell support, tripwire, etc. Now I see the Amcrest integration has this capability as well (plus PTZ, and new support for NVR channels). What it still lacks is config flow support.

I'm wondering what the possibility is for collaboration between the two integrations? It maybe boils down to which library is supported better - python_amcrest or python DahuaVTO.

[rroller]

I don't like the HA model where you have to go through very rigorous code review and long release cycles for integrations. The HACS model is more ideal IMO where we can update integrations out of band with official HA releases. I'm just doing this for fun so I'll continue to build this integration. I also don't like the Amcrest branding. Amcrest are Dahua cameras rebranded (I know it's trivial :) ) The main blocker for me working on the Amcrest integration is the inability to get code merged because of the code review process.

[GaryOkie]

I understand! I was not suggesting dropping what you are doing here and working on the Amcrest Integration at all. I recall seeing somwhere in your comments that the eventual roadmap for this Dahua code was to be part of core.

My intent was 2 parts - to show the direction the code needed to take in terms of how sensors and events should be handled from a HASS developer's perspective (and review).

And to show that there is a lot of code that can be shared.

BTW - All my cameras and NVR's are Dahua, except for the doorbells. Not a big deal, but I put up with the Amcrest branding and even suggested to blademckain that he fork Amcrest to be the new Dahua integration. I love what you are doing here and am finding it works really well for my needs. I just had not realized that the Amcrest core code had improved so much lately as well.

[tane64]

Also using Dahua NVR.
When onvif is enabled you can access any camera and stream. Just change the channel for other cameras. Streams are fast in the 2021.9 whit auto resize to device.

-rtsp_transport tcp -i rtsp://user:onvifpassword@172.16.4.102:554/cam/realmonitor?channel=1&subtype=1&unicast=true&proto=Onvif

[blademckain]

@Mikefila yeah it's best to use the event bus in HA to do these automations instead of the sensors I made. The sensors work for the simple case that lots of people will use but if you have a more advanced setup then you'll need to use the event fired on the bus as you correctly point out, has all the needed data.And with the latest update I believe they are deduplicated.

I was involved in a now defunct PR to add event handling to the Amcrest Integration. The developer had a very hard time getting it approved and gave up. One of the reasons was he added a config yaml change which was a no-no, so he went back and added config flow code, and then was told there were too many changes at once, break the PR apart.

In this PR discussion, Balloob reviewed it as well, and had this to say about events and binary sensors...

See home-assistant/core#40496 (comment)

balloob on Nov 13, 2020

Events should not be binary sensors to begin with. All events should be … events.

See https://developers.home-assistant.io/docs/integration_events

We should remove the option to define which binary sensors are added. Instead that should be controlled by the user by enabling/disabling entities in the entity registry.

In revisiting this PR I just discovered that another developer picked up where blademckain left off and was somehow able to get event handling added to the Amcrest integration. (https://www.home-assistant.io/integrations/amcrest/#events)

And I see some config yaml updates were added as well for tripwire detection as binary sensors!. Whoa. So inconsistent. No idea how that got approved

I mention all of this because there is a LOT of overlap between the Amcrest integration and your new Dahua code. I started using your code because the original code owner for Amcrest bailed out, and it lacked doorbell support, tripwire, etc. Now I see the Amcrest integration has this capability as well (plus PTZ, and new support for NVR channels). What it still lacks is config flow support.

I'm wondering what the possibility is for collaboration between the two integrations? It maybe boils down to which library is supported better - python_amcrest or python DahuaVTO.

the dissident programmer is here :)

@rroller your work is great
thanks a lot

[tomlut]

My DHI-NVR5208-8P-4KS2E with 7 cameras set up no issues. I'm getting camera feeds and intelligent motion alerts. However it takes 15 times longer than the Onvif integration to set up (60 sec as opposed to 4 sec for Onvif).

Is this normal?

Can anything be done?

[Mikefila]

Nvr/dvr/xvr support was added after the fact. So it treats each instance as if it was a standalone ip camera. Instead of logging in once to the nvr, it logs in for each camera and slows the unit down.

I don't think anything can be done on our side. I have 11 cameras on a ssd pi and it takes longer than a minute to load. I have 5 streams enabled.

[tomlut]

Can the logins be done simultaneously?