3 ms·
It's a neat project, but doesn't having to connect my computer to the zero's wifi-hotspot mean I can't actually use my own network since I would not be routing
by asutekku 6y ago
It's a neat project, but doesn't having to connect my computer to the zero's wifi-hotspot mean I can't actually use my own network since I would not be routing my connection through a zero. That would then make this kind of device kind of useless unless I have a dedicated device to watch the stream from? Or am I missing something?
- diego_moita 6y agoThis is the biggest issue I have, too. Motion[1] has a lot less resolution and it's video is not good. But, at least, I can access the video stream through http. That makes an huge difference when implementing a solution. For non-tech users you can just stick the camera's streaming webpage to a phone home screen and give instant access to the video stream. [1] https://motion-project.github.io/ https://motion-project.github.io/
- coder543 6y agoI haven't looked at the project yet, but... your comment precludes the possibility of your computer having a wired ethernet connection to the internet. Then the camera could be placed anywhere as long as it can get power, and your computer could connect to both the camera and the internet. But, I don't understand why the project would really benefit from the Pi Zero hosting a wifi hotspot... it seems like it would be better for it to just join an existing wifi network.
- INTPenis 6y agoThat step should only be to test and configure the camera. While you're connected you login and configure your own wifi on it. Preferably that web tool should do it for you. Either way, a lot of consumer products have that one step.
- pengaru 6y agoI use Pi Zero W camera kits for security cameras, and they just associate with their own dedicated wifi AP, which puts them behind a NAT firewall and routes to the internet in the usual fashion. Accessing the cameras then is no different than accessing anything behind NAT on a home network. The AP can have holes punched for port forwarding to the cameras, some kind of dyndns solution could be used to give them a persistent name if the AP's public network address is dynamic. There are other solutions in this space as well... My preference however is to not punch any holes and not bother with supporting external connections at this layer. Instead I have the cameras establish and maintain ssh connections w/reverse tunnels on an external server having a static IP on the internet. Those reverse tunnels only listen on localhost ports at the server, requiring a locally executed process to reach the camera tunnels. In the case of my server's configuration, that basically requires logging into the server via ssh to reach the camera tunnels. For an authorized user with ssh access to the server, it's trivial to access the tunnels with a web browser by establishing a SOCKS proxy via ssh and configuring a web browser to use it. I've ~reproduced this setup for some friends/family members, using extremely cheap VPS instances strictly for terminating the ssh tunnels and providing a self-signed cert https proxy w/basic auth to reach the camera tunnels more conveniently using a smartphone's browser. It seems to work fine for them once they get the self-signed cert permanently accepted in their phone's browser, and is more convenient since they're not IT people and won't be running an ssh client anytime soon. The main problem that's come up is reconfiguring their cameras wifi when they upgrade their home network. They forget about the cameras wifi dependency, and by the time they discover the problem it's too late and we're talking usb2serial GPIO console to reconfigure wpa_supplicant time.