Help with HIKVision Virtual Machine access (via Homebridge on a Synology NAS)

[dbrewood]

Okay guys I need a bit of help. I'm an Apple user and the final target of a project I've set myself is to integrate my HIKVision cameras into Apple Homekit via Homebridge. Homebridge is running and working on my Synology NAS. My initial thought is to add a camera into the Synology Surveillance System as if I can get it working in there then I know I can likely got it working in Homebridge.
The NVR we have is a DS-7608NI-K2 / 8P linked to 3 x DYN 7608NI cameras. It has been working well since it was installed about 2 years ago. The cameras run on the NVR's own network (192.168.254.X). A static route is set up on my router to send 192.168.254.X to the NVR.
To try and gain access to the cameras (either by user logon or via camera scanning wizard) I've so far:

• Turned on ONVIF
• Turned on virtual machines
• Noted the ports of the virtual machines and forwarded them to the NVR

So after doing that I can get to the camera login portal at: http://192.168.1.xx:65002 but any logins I try for any users fail and the camera threatens to lock me out.

My installer has said the issues are caused by the cameras using the NVR network and that I should change each camera to be on the main home network instead of using the NVRs network.
Any thoughts / suggestions would be appreciated.

 

[Dan]

Hi @dbrewood

Your installer was correct, the Virtual Host function only works for Hikvision's own cameras and not 3rd-party cameras.

We usually recommend that users add 3rd-party cameras to their local network (via individual PoE injectors or a separate PoE switch) because you then have full access to each of those cameras via their dedicated local IP addresses and you can still add them to the NVR over the local network.

 

[dbrewood]

Thanks for the quick reply. These are Hikvision cameras. The installer had further said:

I think that’s the issue you’re having. The plug and play option is the NVR is on your house network and each of the cameras are on the NVR’s network, so you’re accessing the cameras via the NVR. What you need to do is add all the cameras to the house network as individual devices, basically the same as the NVR. What that will allow you to do, is access each camera separately to the NVR. I’m pretty sure that’s what you will need to do, to get the access you require.

and

That’s why it’s showing security as N/A in the first screenshot. Because you’re using the NVR network, the cameras can’t be accessed within the house network it’s attached too, so doesn’t need IP password protection.

So do I need to reconfigure all the cameras to be on the home network? I'd have thought the logon for the NVR would work for the cameras as they are fully installed on the NVR and working? If that was done though would they still be able to link to the NVR for recording / playback etc?

 

[Dan]

Hi @dbrewood

What camera models do you have? You say they are Hikvision cameras but above you say they are "DYN 7608NI cameras" which we have never heard of and nothing comes up on Google when we search for this.

 

[dbrewood]

Hmm that is what the NVR shows them as. The cameras are actually:

 

[Dan]

Thanks @dbrewood

I looked at your original post again and realised I hadn't understood exactly what your issue is, basically your problem is that you can get to the virtual host login pages for each camera but they won't accept any password you try, is that correct?

Have you tried the admin NVR password? When you plug new cameras directly into the PoE ports on the NVR they should be activated with the NVRs admin password.

 

[dbrewood]

Hi Dan that is 100% correct.

Ahhh you've got me thinking...... Yep I know the original password the system was configured with (since changed on the NVR), and I just tried that on a camera and bingo I'm logged in.

So that is the initial hurdle out of the way. I've now added a new user to the camera I'm using to test the system with and have managed to authenticate the camera in the Synology Surveillance Station, but alas after a minute or so it disconnected and will not reconnect.

If it helps at all the SS settings are as below. I hope that may offer some clues?

 

[Dan]

Hi @dbrewood

Thanks for the above info.

We haven't tested this thoroughly but from our previous experience of connecting Hikvision cameras to Synology you need to add them using the admin user details, this is because there are certain permissions that are only granted to the admin user and SS needs access to those permissions.

If you have to have additional users created it might be possible to get around this issue by logging directly into the camera and going to Configuration > Network > Advanced Settings > Integration Protocol and enabling Open Network Video Interface (ONVIF), you can then add an ONVIF user to the camera and then try adding it to SS by setting the Brand to ONVIF (but this will likely limit your ability to use the advanced AcuSense features).

 

[dbrewood]

It looks like it was a user permissions issue. For my added camera user I've given it full admin permissions, logged into SS on the NAS again and it's now showing with a camera feed. I can also access SS via DS Cam on the iPhone and get full video (with sound - never had that with the HIKVision app). So that is stage 1 complete I think.
Next is seeing if I can get it into Homebridge

 

[dbrewood]

Well one step forward two steps backwards - ish .....

I've searched though all the Homebridge plugins available looking under HikVision and CCTV and tried all the plugins available. Some are NVR based others look to connect to the cameras directly.

None of the NVR based plugins work, neither do most of the camera based ones.

The one which has the most promise is the 'Homebridge Camera FFmpeg' plugin, but when configured:

It shows the camera / speaker in Homebridge but in the 'Home' app on iOS it says device not responding....
Nothing I change seems to make any difference.

 

[Tesla]

Review your RTSP stream address. This thread may help: Hikvision RTSP Stream URLs

 

[dbrewood]

Okay I've just checked out that thread, and I've tried various permutations, still no luck..... Next I've been to the plugin page on Git and tried out the HIKVision configs on there, still 'No response'. They also have a link to ispyconnect which gives details of configs from various camera models. The HIKVision page which includes my camera:

Says I should use the format of:

And using their wizard that gives me the rtsp string of:

rtsp://adminuser:adminpw@ip_address/Streaming/Channels/101

And yet again that gives me a No Response from the camera on the Home app on the iPhone.
I'm getting very close to giving up I guess now.

 

[dbrewood]

Okay to recap.......
The NVR is IP address 192.168.1.77
The Drive Camera is 192.168.254.5 (on the NVR network)
The Drive Camera virtual machine port is 65001
The router has a static route sending all traffic for 192.168.254.5 to 192.168.1.77
Ports 554 and 65001-65003 are open on the NAS firewall

Using the Surveillance Station on the NAS I can connect to the camera as (i.e via the NVR and VM port):

With no problems at all.

When trying to get the FFmpeg plugin working in Homebridge I've tried:

rtsp://192.168.1.77:554/Streaming/Channels/101
rtsp://192.168.1.77:554/Streaming/Channels/101/
rtsp://192.168.1.77:65001/Streaming/Channels/101/
rtsp://192.168.254.5:554/Streaming/Channels/101
rtsp://192.168.254.5:554/Streaming/Channels/101/
rtsp://192.168.254.5/Streaming/Channels/101
rtsp://192.168.254.5/Streaming/Channels/101/
rtsp://admin:password@192.168.1.77:554
rtsp://admin:password@192.168.1.77:554/Streaming/Channels/102/
rtsp://admin:password@192.168.1.77/ISAPI/Streaming/channels/101/HighResolutionVideo
rtsp://admin:password@192.168.1.77/Streaming/Channels/101
rtsp://admin:password@192.168.254.5:554
rtsp://admin:password@192.168.254.5:554/Streaming/Channels/101
rtsp://admin:password@192.168.254.5:554/Streaming/Channels/101/
rtsp://admin:password@192.168.254.5:554/Streaming/Channels/102
rtsp://admin:password@192.168.254.5:554/Streaming/Channels/102/
rtsp://admin:password@192.168.254.5/ISAPI/Streaming/channels/101/HighResolutionVideo
rtsp://admin:password@192.168.254.5/Streaming/Channels/101
rtsp://admin:password@192.168.254.5/Streaming/Channels/101/
rtsp://adminassword@http://192.168.1.77:65001/Streaming/Channels/102
rtsp://adminassword@http://192.168.1.77:65001/Streaming/Channels/102/
rtsp://camuser:password@192.168.1.77:554/Streaming/Channels/101/
rtsp://camuser:password@192.168.1.77:65001
rtsp://camuser:password@192.168.1.77:65001/Streaming/Channels/101/
rtsp://camuser:password@192.168.254.5:554/Streaming/Channels/101
rtsp://camuser:password@192.168.254.5:554/Streaming/Channels/101/
rtsp://camuserassword@http://192.168.1.77:65001/Streaming/Channels/101/
rtsp://camuserassword@http://192.168.1.77:65001/Streaming/Channels/102/
rtsp://http://192.168.1.77:65001/Streaming/Channels/101
rtsp://http://192.168.1.77:65001/Streaming/Channels/101/

Which is every combination I can think of - hitting the camera directly or via the NVR with either the RTSP port or the virtual machine port. Typically, I get error:

[Camera FFmpeg] [Drive Cam FFmpeg] FFmpeg exited with code: 1 and signal: null (Error)

Which almost sounds like it's not connecting to the camera. Have I missed the obvious somewhere?

Any further thoughts guys would be very much appreciated.

 

[Tesla]

You can view the RTSP stream using VLC media player on a PC or Mac so perhaps get that working to prove your RTSP streams are good. You’ll then know the issue is with Homebridge.

Do you have Hik-Connect configured with encryption on the NVR? If so RTSP won’t work, you’d have to switch the encryption off.

 

[dbrewood]

I've tried to validate each RTSP stream using VLC and again nothing displays, so yeah I think the issue is with the RTSP stream itself. Mind you, on some stream URLs I tried in VLC it did state that only some types of RTSP stream were now supported – I didn't catch the exact message.

I've been caught in the past with the encryption, so turned that off ages ago, so it's not that.

I'm coming round to face the fact I'm going to have to change the way the system works so that the cameras are on the main network instead of being on the NVRs network. I'll try changing one camera first in case I mess anything up and test with that.

That has to simplify matters.

 

[Tesla]

The RTSP streams definitely work with the cameras on the "NVR" network, you just change the trailing number to that of the required camera (channel) and stream (main/sub).

I'd focus on getting access to the RTSP streams via VLC with the cameras remaining on the NVR (.254.x) network before adding any additional systems and steps.

Go back to basics first then build from there.

 

[dbrewood]

Right, so based on that and the wizard output from ipconnect and taking into account the virtual machine for the camera the stream should be:

rtsp://admin:adminpw@192.168.1.77:65001/Streaming/Channels/101

As the NVR is 192.168.1.77, the virtual machine for the camera is 65001, and the main channel is 101. So I put this into VLC:

And it fails to open the stream and gives me errors of:

Even more annoying, that Surveillance Station on the Synology NAS has basically the same settings:

and works perfectly.

I'm now wondering if it is a network issue? I did have the RTSP (554) port forwarding to the NVR, I've now tried adding 65001-65003 to the forward as well (I did have that in place earlier but removed it).

Hmmm, still the same error.

Checking settings in the router again I've a static route telling sending Drive Cam (192.168.254.5) traffic to go via the NVR (192.168.1.77), I'll delete that as it should not be needed. Tried again:

I tried both the master NVR password and the 'camuser' login created for the camera still go and I get the same errors. I keep thinking there is something obvious I'm missing but I can't think what. If the 'same' settings work for the SS on the NAS then they should work in VLC?

 

[Tesla]

You don’t need a port number in the RTSP stream when using the default RTSP port on the NVR (554), lose the :65001 from your address.
In this instance the stream is coming from the NVR, not the camera.

Port Forwarding is only for accessing devices from outside of your network, best practice would be to not forward any ports and instead use a VPN. You don’t need port forwarding configured for access ”inside“ the network. This is adding complexity which goes back to my earlier point, simplify everything, get your RTSP streams working in VLC and then granularly set everything else up/switch it back on, testing RTSP at each step. You’ll then find the culprit.

 

[dbrewood]

Thanks for that. I've removed the forwarding rules, as you say they are not needed.

Okay so I've simplified down to using the following, but if I do that how does VLC know which camera it is to access, as they are defined by the virtual machine ports of 65001, 65002, 65003 for each camera?

rtsp://camuser:password@192.168.1.77/Streaming/Channels/101/

For that VLC gives: VLC is unable to open the MRL'rtsp://92.168.1.77/Streaming/Channels/101/". Interestingly enough after I added it in I was prompted to enter login details via a dialogue box.

If I simplify further to

rtsp://92.168.1.77/Streaming/Channels/101/

I then get: VLC could not connect to "92.168.1.77:554".

[Hmm just tried to access the NVR via the web portal and it tells me I'm locked out and to try in 17 minutes......] Which may be slightly positive as it shows I must be connecting somehow with VLC]

Now from reading what you have said above it looks like I'm still missing the (channel) and stream (main/sub). I'll look on the web portal once I can get back in to it and feed back.

 

[Tesla]

Your examples above are missing the prevailing 1 from the 192. IP address.

The number at the end of the stream address determines the channel and stream, 101,102, 201 etc.

Since your connecting to a stream from the NVR you need to use the NVR‘s username and password, if you have a different username and password for the IP Camera that’d explain why your NVR has locked out, since VLC would have been pushing the wrong credentials to it. Which as you say is a positive in sorts as means VLC is attempting to access the correct source.