I just reduced the ‘Up to’ speed to 54Mbps to see if that is of any value
I am assuming that the LED is not indicating any special condition, correct? The Skybell LED is just solid green (or the color you have chosen instead) indicating connected and ready throughout these tests?
Yes
Oh well. No difference. I just tried to start the video from my phone over ATT and it took four retries.
I still find quite interesting is that there is essentially no delay from a motion-triggered recording or doorbell-press triggered recording streaming to ADC, and only a few seconds from trigger to the receipt of the text message on my phone.
The issue appears to be getting the stream to the phone when I tap the screen to start video. I can’t help thinking that the issue is on ADC’s end; either their server or the Android app. Do you have any contact with SkyBell or ADC to troubleshoot this? Also, is there any way to start and view video other than the phone app? Is there a browser-based method?
I’m getting a replacement doorbell.
The issue appears to be getting the stream to the phone when I tap the screen to start video. I can’t help thinking that the issue is on ADC’s end; either their server or the Android app. Do you have any contact with SkyBell or ADC to troubleshoot this? Also, is there any way to start and view video other than the phone app? Is there a browser-based method?
There is no browser based connection for the stream. It is intended for use through the app.
One thing that I am curious about, probably going to be a bust due to the supervision issue, but have you always tested from that same mobile device?
Yes, we contact ADC for support. The Skybell Slim is an ADC only product.
I understand the temptation to point to the app, but the failed pings are extremely suggestive, and once again, this is not the expected behavior. Any installation can experience delays in connection due to network hiccup, but routine delays like you are seeing are aberrant.
It’s the only mobile phone I have. I test both via a wifi connection and via AT&T cell data.
Regardless, lowvoltagesupply.com, where I purchased the bell, is shipping me a new one and emailing me a return shipping label for the old one. Really super nice people on the phone to deal with, by the way. They sell these things for $129.00.
If the new bell has the same issues, I am at a loss on how to proceed.
If the new one shows the same, then we have more ammo to dig in with product support as well to find more esoteric problems.
I would recommend replacement at this time though. We’ve exhausted standard troubleshooting I think.
Thank you for all of your time and help, Jason. I definitely appreciate it.
One more thing I will try: The EX7000 has been in extender mode rather than access point mode; I didn’t realize this. I just reset it so I can put it an AP mode (only way to change modes), but discovered I can’t configure it when it’s in factory fresh condition unless I’m on a computer physically plugged into the device, so it will have to wait till I get home.
Good catch. Try setting as an Access Point. And make certain that the 2.4 network SSID and key is unique, not the same as the main router’s 2.4.
We don’t want to isolate the Skybell from other household devices necessarily, we want to isolate the Skybell from the further connection point.
I know I might be beating the proverbial deceased equine, but I just want to make sure it is clear for troubleshooting purposes.
The current diagnostic numbers do sort-of look like when you had it connected directly to the main router.
The main router is a wired Cisco RV325 rack mounted device without wireless.
The main wireless AP is an R7000 NightHawk (in AP mode) which has its 2.4 radio disabled. The only 2.4 radio enabled in the house is the EX7000. It has (or, will again after setup) the SSID “ADC” and is not the same as the 5.2 network from the R7000. Thus, the SSID is unique, it is a 2.4 radio, and the only 2.4 device in the house to connect to it is the SkyBell
The only 2.4 radio enabled in the house is the EX7000. It has (or, will again after setup) the SSID “ADC” and is not the same as the 5.2 network from the R7000. Thus, the SSID is unique, it is a 2.4 radio, and the only 2.4 device in the house to connect to it is the SkyBell
That’ll do it.
Are you resetting the Skybell Slim to factory default each switch?
“Factory Reset
Caution: If you initiate a Factory Reset, the Doorbell
Camera will need to be re-connected to Wi-Fi and resynced
with the account.
Press and HOLD the button until the LED begins a
Yellow rapid strobe flash. The reset could take up to 2
minutes.”
No. I’ve simply assured the network has the same ssid and password each time
Hmm. Alright, I would try a factory default, I think we assumed that was tried earlier but if you’ve only been matching the SSID and network key each time it would be a good thing to try out.
I did a factory reset of the doorbell. I assured the EX7000 is in access point mode. It is positioned within 4 feet of the doorbell and the signal strength reported on ADC is routinely between 98 and 100%.
There is no change in the behavior.
Things I know to be true in this context:
Doorbell to ADC as evidenced by SMS arriving within seconds in response to button or motion --> PERFECT
Video stream to ADC, evidenced by video clip availability starting from 10-15 secs prior to above event --> PERFECT
Video stream to my phone on AT&T --> FAIL!!**
**If stream is initiated by me without a bell-triggered event -> Random time from a few seconds to over a minute of retries. If stream is initiated by me as a result of a an SMS (which means that ADC is now storing a clip while supposedly echoing back to me) --> HAS NEVER WORKED!! The video will not start. Period. I have to wait a couple of minutes and try to initiate again, which is probably after the recording has stopped.
These symptoms are not a network issue in my house. They are not a network issue with AT&T (speed tests from my phone on cell data are upwards of 60 down, 10 up). The issue has to be at ADC.
The video stream that I see when monitoring live, whether connected by wifi or by cell is flawless; the bell is streaming well, which means the network is stable as well. For whatever reason, ADC has an issue sending the stream out. I know this because I used WireShark. What I can see is that, with my phone on home wifi, if I initiate a stream, i can see the request from the phone go out of my network. I see incoming traffic to the bell occur quickly and the bell responds in under a second and begins streaming out. Nothing comes back to my phone for seconds or up to a minute.
Unless there is some kind of network issue between ADC and the hops to my house, that does not explain why the same issue exists wehn I’m using cell data or wifi 250 miles away from my house.
Please contact ADC. Thank you.
Thank you for following up. It looks like the diagnostics are now showing 100% across the board for supervision in 24 hours, signal strength, and signal quality. With all the troubleshooting we’ve done, I can certainly push this again to video folks at ADC to dig deeper into the traffic.
There is certainly something bizarre about this if you are seeing heavy delays like this. We’ve definitely hit the limit of local troubleshooting though.
Did you by chance test this with the replacement Skybell? Or has it not yet arrived?
No new skybell yet. Thank you for pursuing this.
Just for the heck of it, are there any specific ports that need to be open in my router? While I can see what is coming in to my network, I don’t know if ADC tries numerous ports after timing-out on closed ports. This could be a cause for delay. For instance, from ring.com: https://support.ring.com/hc/en-us/articles/205385394-What-Ports-Do-I-Need-to-Open-in-My-Firewall-for-Ring-Doorbells-and-Chimes-
Ring uses the following ports:
TCP 80
TCP 443
TCP & UDP 15063
UDP range between 16500-32768
UDP 51504/51506
Ring Chime also requires certain ports. If your Chime is not ringing, ensure that the following ports are open outbound as well:
TCP 80
TCP 443
TCP 9998
TCP 9999
The client applications also use the following outbound ports:
TCP 7078
TCP 9078
p