Individual ports are not detailed in the Skybell device and network settings like other ADC cams, but I will ask the video folks about this and we can try opening/forwarding as necessary.
Thank you
I got hold of SkyBell support. Ports required are Outbound UDP: 5004-5010. Inbound/Outbound UDP 5683-5684. Inbound/Outbound TCP: 443
My router’s firewall had ‘Multicast Pass Through’ disabled. I enabled it.
I un-bound 443 from the IP of my server, and I created routes for the required UDP to the SkyBell.
I’ll let you know.
Thank you for following up. I have not heard back yet, but I will verify those ports with ADC.
Sounds like a good test. Let us know how it goes.
Just tested. I’m at work in Manhattan, using the cell network. My wife hit the doorbell at our house near Princeton, NJ (about 60 miles as the crow flies), then began timing till she heard me answer. This includes the time from my phone vibrating to alert me to an SMS, me swiping to unlock, then tap the SMS notification which then switches to the ADC app and begins the stream connection attempt.
My wife heard me and I could see her. Total time: 14 seconds. Subtract the overhead of my reaction time, phone unlocking, etc., and is easily under ten seconds. We repeated this several times, me keeping my phone screen on in subsequent tests. She could hear me after the doorbell press within 5-7 seconds.
We have a winner!! It was the ports.
My router is a business-class device. The internal firewall is pessimistic by default; it blocks everything unless specific rules and ports are configured. Previously SkyBell/ADC must have been failing-over to routing everything over TCP rather than UDP, which is not a good choice for a media stream and would cause the random delays due to stateful re-transmissions of dropped TCP packets.
This has been a grand voyage of discovery. Thank you for all of your help. I can now say that the device works.
One more thing: I can self-initiate a stream from the ADC app and is starts in 2-3 (!!!) seconds now consistently.
That’s great news!
Unfortunately this is the nature of troubleshooting networking. Consumer networking product and setting variations are pretty wide and can obscure issues.
I would say you should still make sure to have a solid 92-100% signal strength and quality, but now you can test the wireless extender accurately without the underlying issue.
Thank you for following up with this as it may help others down the line.
Jason, I’m having some similar issues to the other David and I think the port settings might fix the streaming but I also have the issue where none of my recordings show the previous seconds prior to detecting motion. Is there some way to fix this?
You need to have the most recent firmware. The new firmware provides the 10-15 second pre-event buffer
Yes, the latest version of the firmware will be needed. You can check this and update by going to the Video Tab in Alarm.com and Video Device settings for the doorbell.
It says I’m on the latest which is 1128.
How have you tested the motion timing? Keep in mind the issue may be more related to the range/PIR capability and when the PIR actually triggers.
Have you tried testing the schedules, or is this based on normal activity? Try standing out of sight of the PIR and walking across the field of view close up. When does the clip start?
In my testing it only starts recording at time of motion trigger. I appreciate the lack of false alarms but it should save the clip with a few seconds before the motion is detected. Attached is an example with the sensitivity turned up to the most sensitive setting.
Thank you for the video example. That does appear to start the recording pretty much on the nose when the motion would be detected. We’ll discuss with ADC and follow up with any troubleshooting suggestions.
Per the latest firmware, pre-trigger recordings should be active.
Is this Slimline 720P video quality or 1080P like the larger one? How is the speaker quality? Im testing a ring pro but it doesn’t work with alarm.com.
From my own experience, the pre-trigger recordings as you’re calling then only work for a door bell button press. Motion doesn’t seem to have this feature. I
It’s 720p or 480. 1080 is not available. The speaker is pretty clear.
For the Skybell HD (the round, 1080P version, the Skybell Slim is 720P and has different firmware versioning) from the latest firmware release notification:
“With the latest firmware upgrade for the Alarm.com Wi-Fi Doorbell Camera, a new firmware upgrade (version 1128) is now available for the Alarm.com Wi-Fi Doorbell Camera SkyBell HD Edition. The upgrade includes the addition of pre-event recording for motion and button-press events.”
The Slim records 10-15 seconds prior to the button press. I see that. Motion trigger does not.
I had two different deliveries today from UPS and USPS where boxes were left on the porch and the doorbell was not rung. I got the motion alerts, but the recordings showed nothing; the delivery person was able to come and go without leaving a single frame in the recordings.
A doorbell press, however, gives the pre-press capture every time. As you said, the firmware is different between the doorbell models.
Alright, after speaking with ADC and going over specs, the motion pre-trigger is still there. The effect will be determined by the nature and speed of the motion.
Motion detection must occur for roughly 7 seconds before a motion triggered clip is started. This is the architecture that Skybell put in place. The pre-trigger recording then was added to bring the start of the motion to roughly be the start of the clip.
The button press has pre-event recording as well, but it starts as soon as the button is pressed.