I had trouble with my ADC-V510 camera, so I deleted it and reset the camera. I can access the camera on my network by IP and login to the default interface, but when I try to add it to my account, it tells me it failed. The log output on the camera shows the static routes being created. Is there some inbound port I have to forward to allow you to configure the camera?
What kind of trouble did you have (just in case it might explain this)?
So in the steps to add a camera, the camera is recognized by ADC as an unregistered new camera, you are able to start the process but the remote connection fails?
In this circumstance, I’ve been told it helps to power cycle your local network. Your camera may be having trouble connecting to the internet through your LAN initially.
- Power cycle your router. (power down 30 seconds, power on)
- Power cycle the camera. (power down 30 seconds, power on)
- Do you get a solid green light on the camera after a couple minutes? Try to add the camera normally through ADC.
The trouble I had was related to the wireless connection - the original SSID is no longer in use, so I just reset the camera assuming it would be easily added back to my account.
I’ve reset/rebooted the camera several times. I’ve also rebooted my router several times and disabled all security on it just to make sure I wasn’t blocking something.
I can access the camera just fine, and it can get out to the internet just fine. It’s failing during the bootstrap with the alarm.com servers, and I can see openvpn errors related to missing parameters. Here is the log from the camera (with sensitive information removed):
Dec 9 20:59:07 syslogd 1.4.1: restart. Dec 9 20:59:15 [DRM Service]: Starting DRM service. Dec 9 20:59:23 [VPN WATCH]: Current IP is 0.0.0.0! Dec 9 20:59:26 [DDNSC]: Service provider: ALARM.COM DDNS Dec 9 20:59:26 [DDNSC]: Update successfully. IP: 0.0.0.0 Dec 9 20:59:28 [LinkDetect]: [mii API]eth0: link up! Dec 9 20:59:29 [SYS]: Serial number = xxxxxxxxxxxx Dec 9 20:59:29 [SYS]: System starts at Wed Dec 9 20:59:29 UTC 2015 Dec 9 20:59:29 [NET]: === NET INFO === Dec 9 20:59:29 [NET]: Host IP = 192.168.x.x Dec 9 20:59:29 [NET]: Subnet Mask = 255.255.255.0 Dec 9 20:59:29 [NET]: Gateway = 192.168.x.x Dec 9 20:59:29 [NET]: Primary DNS = 192.168.x.x Dec 9 20:59:29 [NET]: Secondary DNS = Dec 9 20:59:29 udhcpc: bound Dec 9 20:59:29 udhcpc: IP 192.168.x.x broadcast 192.168.x.255 netmask 255.255.255.0 Dec 9 20:59:30 udhcpc: router 192.168.x.x Dec 9 20:59:30 udhcpc: dns 192.168.x.x Dec 9 20:59:31 [EVENT MGR]: reload config file Dec 9 20:59:36 openvpn[858]: OpenVPN 2.0.9 (1.0.0.0) arm-unknown-linux [SSL] built on Feb 6 2010 Dec 9 20:59:36 openvpn[858]: IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port. Dec 9 20:59:36 openvpn[858]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Dec 9 20:59:37 openvpn[858]: WARNING: file '/ovpn/client1.key' is group or others accessible Dec 9 20:59:37 openvpn[858]: ******* WARNING *******: null cipher specified, no encryption will be used Dec 9 20:59:37 openvpn[858]: Control Channel MTU parms [ L:1525 D:138 EF:38 EB:0 ET:0 EL:0 ] Dec 9 20:59:37 openvpn[858]: Data Channel MTU parms [ L:1525 D:1450 EF:25 EB:4 ET:0 EL:0 AF:14/25 ] Dec 9 20:59:37 openvpn[858]: Local Options hash (VER=V4): 'xxxxxxxx' Dec 9 20:59:37 openvpn[858]: Expected Remote Options hash (VER=V4): 'xxxxxxxx' Dec 9 20:59:37 openvpn[858]: UDPv4 link local: [undef] Dec 9 20:59:37 openvpn[858]: UDPv4 link remote: xxx.xxx.xxx.xxx:1194 Dec 9 20:59:37 openvpn[858]: TLS: Initial packet from xxx.xxx.xxx.xxx:1194, sid=xxxxxxxx xxxxxxxx Dec 9 20:59:37 openvpn[858]: VERIFY OK: depth=1, /C=US/ST=VA/L=Vienna/O=Alarm.com/CN=videovpn.alarm.com/emailAddress=support@alarm.com Dec 9 20:59:37 openvpn[858]: VERIFY OK: depth=0, /C=US/ST=VA/O=Alarm.com/CN=videovpn.alarm.com/emailAddress=support@alarm.com Dec 9 20:59:38 openvpn[858]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Dec 9 20:59:38 openvpn[858]: Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication Dec 9 20:59:38 openvpn[858]: Control Channel: TLSv1, cipher TLSv1/SSLv3 AES256-SHA, 1024 bit RSA Dec 9 20:59:38 openvpn[858]: [videovpn.alarm.com] Peer Connection Initiated with 216.36.42.121:1194 Dec 9 20:59:39 openvpn[858]: SENT CONTROL [videovpn.alarm.com]: 'PUSH_REQUEST' (status=1) Dec 9 20:59:39 openvpn[858]: PUSH: Received control message: 'PUSH_REPLY,route 10.39.0.0 255.255.0.0,route 10.41.0.0 255.255.0.0,topology p2p,ping 25,ping-restart 80,ifconfig 10.35.48.85 10.35.48.1' Dec 9 20:59:39 openvpn[858]: Options error: Unrecognized option or missing parameter(s) in [PUSH-OPTIONS]:3: topology (2.0.9) Dec 9 20:59:39 openvpn[858]: OPTIONS IMPORT: timers and/or timeouts modified Dec 9 20:59:39 openvpn[858]: OPTIONS IMPORT: --ifconfig/up options modified Dec 9 20:59:39 openvpn[858]: OPTIONS IMPORT: route options modified Dec 9 20:59:39 openvpn[858]: TUN/TAP device tun0 opened Dec 9 20:59:39 openvpn[858]: /sbin/ifconfig tun0 10.35.48.85 pointopoint 10.35.48.1 mtu 1500 Dec 9 20:59:39 openvpn[858]: /sbin/route add -net 10.39.0.0 netmask 255.255.0.0 gw 10.35.48.1 Dec 9 20:59:39 openvpn[858]: /sbin/route add -net 10.41.0.0 netmask 255.255.0.0 gw 10.35.48.1 Dec 9 20:59:39 openvpn[858]: Initialization Sequence Completed Dec 9 20:59:40 [VPN WATCH]: Update VPN IP information to 10.35.48.85! Dec 9 21:00:00 [DDNSC]: Service provider: ALARM.COM DDNS Dec 9 21:00:00 [DDNSC]: Update successfully. IP: 10.35.48.85
Did you just change the SSID of your network on the original router this camera was connected to, or did you switch to a new router?
Either way, what model of router is it connecting through?
The logs are a little strange, as it appears the camera is actually able to communicate with Alarm.com back-end and receive DDNS updates, etc.
The router didn’t change (ASUS RT-AC68U). I actually had this thing on my guest network and just turned guest off. I turned it back on and the camera wouldn’t work (even after rebooting), so that’s why I just reset it in an attempt to restore default config and apply my private SSID.
I’m pulling my hair out since it seems like the camera is communicating properly to me as well. Alas, Alarm.com continues to give me the generic failure message when I try to provision the camera.
Are you trying to make any configuration changes to the camera prior to the pairing process?
If you are logging into the camera prior, try defaulting the camera and just immediately connecting to Alarm.com once it’s LED is green.
Alright, got a follow up from ADC after some testing. Looks like V510 cameras might be affected by this right now in general when trying to learn them in. They are seeing a few more reports and have done some testing to confirm.
You can try a full reset, then power cycle, wait for green led, then immediately attempt to pair. (sounds like you’ve already probably done this, but wouldn’t hurt once more) If this does not work, it looks like it would be related to the issue above.
No ETA on it, as they’ve only had a few reports today (older model camera, so not as common to be adding one) but they are addressing it now.
No dice. Fresh reset, immediately attempted configuration via Alarm.com after green light.
This camera isn’t THAT old. I’ve had it about 3 years, and it’s going to be VERY popular with customers switching from Vivint. If it’s not commonly added, it’s probably because most people with it don’t normally delete and re-add the camera to their account. Hopefully they get this figured out soon, as I’m dead in the water right now.
All my cameras were/are Vivint branded (e.g., V610PT, V510, V520IR)
Try doing it manually by MAC. I had a similar issue, Vivint V520IR camera kept failing, and I couldnt add it.
Manually adding it via MAC worked. In my case, the Vivint cam required a firmware update.
Since the camera was detected, the MAC method isn’t even an option. It already shows the camera in the list. As SuretyDIY support has already mentioned, this is a known issue with provisioning this specific camera on alarm.com.
Thanks for the suggestion, though.
I had that cam, and had no issue adding or provisioning. Check the firmware version.
Since the firmware is controlled by Alarm.com, there is nothing I can do in that regard. This camera was working prior to Dec 1st on my account with current firmware. I’d wager if you remove yours from your account now and try to re-provision it, you’ll have the exact same problem with the ADC-V510.
I gave away my x10 series (discontinued back in like 2011) V510 long ago, as it is a subpar camera. Vivint likes to offload overpriced discontinued products to their users.
Did they announce discontinuation of support for the V510 somewhere? Ceasing sale of the camera does not mean it is unsupported.
It worked fine until 10 days ago, and that was seemingly because of changes I made to my network. Now, they have known issues with provisioning. Since they are looking into it, I think it’s safe to assume the camera is still supported.
X10 cameras haven’t been offered by alarm.com for years. You want an x20 series camera. The old x10 series are not even compatible with the streaming Video recorder.
ADC doesn’t include any x10 series camera in their lineup, or even offer it for sale to their Dealers anymore. The V510 was replaced years ago with the V520.
I want my v510 to work, because it still suits my needs. I don’t care if it’s an old turd of a camera. It functions well enough for a specific purpose, and I don’t feel I should buy a new camera just because this one is “old”.
I know Vivint rips people off; that’s why I’m here. The v510 has worked for me for several months since I switched to Surety.
I’ll wait to see what Alarm.com can find out here, as they’ve already stated they know of the issue. I’m not buying a new camera, so if that’s the resolution then I’ll take my business elsewhere.
I appreciate the suggestions, but buying a new camera isn’t on my list of acceptable solutions.
The v510 worked fine with the video recording functionality.
Again, not for sale and not supported are two entirely different things. They are not exclusively mutual.
You shouldn’t have to buy a new one. I still myself use an x10 series cam (V610PT). Just keep in mind, that cam has been long ago discontinued and rendered obsolete. ADC doesn’t even try to male the x10 series Vivotek gear compatible with new equipment (e.g., ADC-SVR). Don’t expect too much.
And if you have it online with ADC, ask them to check the firmware, and update it if applicable OTA.