I ordered the SkyBell SlimLine Trim Plus ADC. It came in two days using their cheapest shipping method (they’re in Utah, I’m in NJ). I was scared I was about to be screwed because it was so cheap, but the “real deal” arrived and I had no issues installing it and adding it to my account here at sDIY.
Observations are as follows:
During configuration, the ADC app told me that the wifi signal is weak. I purposefully put a dedicated wifi extender about 10 feet from the doorbell. Standing in front of the doorbell, speedtest.net shows 100Mbps down/ 41Mbps up. The ADC website control panel for the doorbell shows a signal strength of 94% and firmware version 3034 which is the current version according to the site.
Video is crystal clear as is the audio. A good 15 or more seconds of video is captured prior to a doorbell press, which is absolutely fantastic! You can also just begin streaming to your phone from the doorbell whenever you want, just for the hell of it, without uploading any video to count against the max permissible monthly uploads which appears to be 400.
The only issue I have is that there is a delay that varies between two seconds and 45 seconds including having to press the retry button on the phone screen after it times out before audio/video begins to appear on the phone. This is pretty bad. I dropped the video quality on the web site to 480p (the lowest quality) to see if it made a difference. It doesn’t.
I’ve only seen this kind of behavior when a network device enters sleep mode of some kind in order to save power. Just guessing if this is the case here. If so, please tell SkyBell or ADC to get rid of this “feature” because I really don’t need power saving feature here; the bell is hard-wired. This random delay really needs to go.
I have to say it has been fun screwing with the neighborhood kids who come to the door looking for my kids:
(doorbell rings)
(doorbell) “I see you Landon”
(Landon) “Who are you?”
(doorbell) “I always see you Landon”
(Landon) “Where are you?”
(doorbell) “I’m under your bed every night Landon. I’m always watching, Landon. Sleep well, Landon. Where are you going Landon?”
(Landon, running into the distance, but still easily seen thanks to the exceptional wide-angle lens of the SkyBell. You can almost make out the fear pee in the distance.)
Ha ha ha! You wouldn’t believe how much that messes with the head and ability to ever sleep again for a typical six year old boy! Lots of laughs!
You can also just begin streaming to your phone from the doorbell whenever you want, just for the hell of it, without uploading any video to count against the max permissible monthly uploads which appears to be 400.
Max uploads would be determined by the Alarm.com video add-on chosen. Doorbell only video add-on clip limit is 400, correct. Skybell HD also falls under Alarm.com Cloud Video levels, and the clip limits apply to it. You can compare add-ons here.
I’ve only seen this kind of behavior when a network device enters sleep mode of some kind in order to save power. Just guessing if this is the case here. If so, please tell SkyBell or ADC to get rid of this “feature” because I really don’t need power saving feature here; the bell is hard-wired. This random delay really needs to go.
Is the delay when trying to access the Skybell without it being locally pressed, or after someone rang the bell?
I do like accessing from the app to just watch the street in front of my house.
What I experience is that I get a text message within a few seconds of a doorbell button press. I tap on the received sms notification’s “Answer” link on my Galaxy S8+ which takes right into the ADC app with a swirling ‘wait’ arrow. The random delay is here as well, even experiencing a time-out where I have to tap the ‘retry’ button. This really has to be addressed.
As an example, while I’m typing this, I just tapped the “Start Video” in the ADC app. There was a delay of less than five seconds till video displayed. Next going with the assumption that there is a power saving feature in the mix, I ended the stream, waited about ten seconds and started again. This time, the delay was long enough to get the time-out with the retry button.
The ADC site currently shows a connection strength of 92%.
If there was a network issue, I would expect dropping-out of video/audio. I have let it stream for an hour straight this morning without a hiccup. If there was so much as a single dropped frame, I certainly didn’t see it. It really seems to be an issue with the doorbell simply not responding for some reason.
There are some expectations and requirements of the video doorbell that are often surprising at first, but I think you are seeing network issues in this case.
As soon as we request details of the link quality I am seeing a poor signal to noise ratio and a poor overall link quality. Signal strength and quality is fluctuating pretty quickly.
The Skybell HD is showing as having made 63% of recent supervision attempts.
So, some things to consider:
I would re-check the speed test to be sure, 41 mbps upload speed is pretty enormous and not common. There may be an error here, except for maybe Fios.
Is the Skybell mounted to a metal door frame?
Do you have the same wifi SSID and network key being used on the closer wifi access point?
Since it is fluctuating I am curious if the Skybell may be connecting and reconnecting between two access points.
The wifi extender uses an SSID which is unique and is unused by any other devices in my network
This reminds me of a bug: I found that when I set up the extender with a hidden SSID, even though the ADC app allows for the manual entry of such an entity, the configuration would not go past 10% complete. As soon as I had the extender broadcast the SSID, the ADC app could properly complete the configuration.
And again, I can stream live for as long as I like with no issue. It’s only the initial connection that seems to be problematic
I can stream live for as long as I like with no issue. It’s only the initial connection that seems to be problematic
Well, we can test this fairly quickly. Can you engage the doorbell and view a live stream? Let us know when you are doing so and leave the stream open. We’ll check the reported link quality/signal.
Thank you. In roughly 30 second increments we checked, link quality first dropped after the stream began from 89% to 85%, then up to 89%, then dropped to 87%, then rose to 91%, then dropped to 88%. Closing the stream has had no effect and it is at 87%. 30 seconds later, 90%.
I’ve measured the same rough fluctuations before the test. Most of the results (and the overall average) would be 85% - 90%, which for this camera is a poor quality rating. I’ve measured it dipping to 84% and up to 92%.
Over 90% sustained is necessary for the best quality. Under 85% will typically cause major issues.
This is all indicative of a more general network issue. What model of access point are you using for the Skybell HD?
The network results look more akin to a more distant router connection rather than a close-by dedicated access point.
The extender is a Netgear WN3500RP.
It is communicating with my R7000 NightHawk on the 5g band and to the doorbell on the 2.4g band.
The R7000 is straight-line distance of approximately 20 feet away from the extender via a wooden floor in a wood-frame house.
The extender is ten feet away from the doorbell through an outside wood and sheet-rock wall with fiberglass insulation within.
A speedtest.net run I did an hour ago to the extender while standing on my front lawn about 15 feet further away from the extender than the doorbell gave me 83 down/ 37 up.
It would seem that the radio in the doorbell is quite weak.
The stream looked quite good during the test you monitored. I could see cars going by quite easily in the background. They did not look like a cartoon flipbook.
My issue is not with the stream. It is with the random difficulty in actually starting the stream.
Upload/download is a separate concern, and in this case not a concern. 37-40 upload speed is way more than would be needed.
The up/down speeds do not speak to the actual quality of the wireless signal between the WN3500RP and the Skybell.
Do you have 2.4ghz disabled on the R7000? If not, can you try manually setting different, non-overlapping channels for the two 2.4ghz networks on the R7000 and WN3500RP? Any change over a day or so?
If no change, would you mind trying to connect the Skybell HD to the R7000 2.4ghz network temporarily and unplugging the WN3500RP? I am curious to see if we get the same quality fluctuations or if it is more steady, regardless of the overall value.
Judging from the speed of the replies I’m guessing that was before any additional troubleshooting and more of an exasperation? Or had you switched the wifi channels? Definitely let us know the results of the tests. We can take a look at the back end diagnostics again. I am very interested to see if the changes affect the fluctuations we are seeing.
I didn’t realize that I had an outlet to plug the extender into which is about two feet from the doorbell. I have it plugged in there. The ADC site says signal strength is 100%
I have disabled all the 2.4 radios in the other access points I have in the house, leaving only the extender’s 2.4 radio active, with a unique SSID and with the doorbell as the only device connected to it. The 5.2 radio of the extender is connected to the R7000 which is in access point mode, which is connected via Cat 6 cable to my Cisco RV325 rack mounted router in the basement, which is in-turn connected via Cat 6 to the Arris cable modem to Optimum.
The extender is so close to the doorbell that they may as well be in the same box. ADC site says the signal strength is 100%. The random difficulty in starting video is no different than yesterday. Once it starts, the video stream flawlessly and as long as I care to watch.
What I’ve noticed is that when I ring the doorbell I get the text message in seconds, so at least that part works; the bell clearly has a network connection and can notify ADC that the event occurred and ADC sends the SMS. I’m wondering if the issue is really on ADC’s side.
I don’t have time this week or weekend to check with WireShark to see the series of network events. My working hypothesis is that the sequence of events is a) User sends a message to ADC to begin streaming by tapping the “Start Video” button in the app b) ADC receives the message c) ADC connects to the doorbell and initiates the stream d) the doorbell streams to ADC e) ADC echoes this stream to the user’s app.
The question is, between which items, ‘a’ through ‘e’, is a delay introduced? Perhaps ADC does not have enough infrastructure to handle the growing number of skybell streams they need to support? It would stand to reason there are a finite number of simultaneous streams they can handle, thus needing to enqueue the stream requests awaiting availability. This is, of course, more than problematic because in this venture immediate availability is the only acceptable solution – no small part of the appeal and usability of this doorbell is the ability to interact with the person at the door. If this is hit-or-miss because of the time for the stream to start, then what’s the point?