Forcing same SSID for direct connect

beta

#1

Hi there-

Wondering if anyone else is running into this. My home network is controlled by a pfSense (DHCP, firewall, VPN, etc) appliance. Off that I have a series of wifi access points. They purely provide connectivity onto the network, not any other network services. This means that anything that connects via my APs are on the same subnet - meaning that direct connectivity between devices on any published SSID works.

Wyze has apparently decide to check to make sure that the camera and app are on the same exact SSID, instead of testing for actual connectivity. I have two different SSIDs (2G and 5G) that connect based on where in the house I am and the strongest signal (there is networking religious debate on whether to do this or not…I’ve clearly chosen to do it). It means that sometimes I end up having to force change my SSID when I want to talk to my cameras directly from the app. It’s annoying…and unnecessary.

Anyone else run into this? Seems like an easy fix to just test for direct connect instead of name of SSID.

Thanks!
Sean


#2

I have my 2.4GHz and 5GHz on separate SSIDs (same router). I have no trouble communicating directly with my cams when my phone is on the 5GHz SSID.


#3

Is it using wifi to directly connect, or going out via the cloud service the same as if you were on LTE? Mine seems to take the extra time it usually does when not direct connecting.

I just went through a bunch of different things on the app - can’t seem to get back to the message I used to get fairly regularly that said something like ‘must be on the same wireless network’…


#4

This is with my modem unplugged.

The only time I’ve seen the message “you must be on the same network” is when trying to download a time-lapse video. For that you need to be on the same local network (but not necessarily the same SSID).


#5

This has not always been the case. I stopped trying to do certain things (and forcing some of my devices to connect to the slower 2G network in the house) because it always threw that error at me. I just tried to record and download a timelapse while on my 5G home network - and it worked like a champ. Yeah, Wyze! For sure, this hasn’t always worked. I had a conversation with them about it awhile ago. Cool.

When I tried yesterday to view while on 5G, it was slower than me trying to view it on “the same” 2G network as the camera. I assumed it was connecting to the Wyze cloud service to view.

Sean


#6

It seems like the Timelapse download function is more intelligent or less restrictive than the general live streaming and control functions.

I have my cameras on a separate private routeable subnet, and the Wyze app is able to figure out that it can reach the cameras to download the timelapse, perhaps because it just simply tries. However for live streaming & control it always relays through their cloud services, wasting my bandwidth & their server resources.

I guess it’s good that it works for the timelapse, otherwise there’d be no practical way to get it other than climbing up and pulling SD cards. Still, would be nice if there was an option to test for local connectivity, or define a subnet range in the app that was considered local.