Eveything I read was that this was a half decent Company but no WEB PC acess is just ridiculous!!!
The only real “solution” right now is to download something like Bluestacks and an APK of the Android app. It doesn’t work great for me, but it’s an option.
I’m currently working on a website that would allow you to view the camera’s stream directly. The main limitation is that you would need to be connected to the same local network as the camera. The advantage is that, if the camera provides a usable local stream, the video could be accessed directly over the local network rather than having to communicate with AOSU’s cloud services.
Another possible approach is screen/stream mirroring. I haven’t researched that method as extensively yet, but it should be possible. The downside with a solar-powered camera is that prolonged live viewing could potentially cause the camera to remain active more often and therefore drain the battery faster.
The more difficult part with the mirroring approach would be creating an interface that can communicate with the AOSU system and reliably retrieve or relay the camera’s video.
So, for me, the local-network approach is the one I’d prefer to pursue first, assuming the camera exposes a usable local stream. It would be simpler, avoid unnecessary cloud dependence, and could potentially give you a clean custom interface for viewing the cameras.
If you’d like, when I make a breakthrough I can share the website with you. It will only work for cameras connected to the same network the device youre using to inquire is on though. The downside is if anyone else have the network password and knows about the website they can view your cameras…or perhaps i can make a generic password entry to the platform which still runs the risk if the password is shared around by many in your area
Great Idea!
This sounds like a very interesting project, but I think the first thing to establish is whether there is actually a usable local video path before spending much time on the website itself.
Since the T2 series does not expose standard RTSP/ONVIF/NVR access, I would probably focus on the AOSU app <—> aosuBase communication, rather than trying to find a normal camera stream URL.
A useful first test would be:
- Keep the local Wi-Fi/LAN running, but disconnect the router from the Internet/WAN.
- Open the AOSU app and try Live View.
- See whether Live View still works.
If it does, that would be a strong indication that the actual media stream can travel locally.
If it stops working, that still would not necessarily mean the video itself is cloud-relayed. The app may simply require cloud authentication or signaling before establishing a local connection.
The next step I would take is packet capture while starting Live View. Find the local IP of the aosuBase in the router’s DHCP/client list and compare traffic with Live View OFF vs ON.
The important question is:
Does the phone start communicating directly with the local IP of the aosuBase or camera when Live View starts, or does all of the traffic go to external servers?
If you see a substantial local connection to the aosuBase, that is probably the most promising thing to reverse-engineer.
Even if the stream is proprietary or encrypted, that would still give you a direction. At that point the real project may not be the website itself, but a small local bridge/service that understands the AOSU protocol, receives the stream, and then converts it into something a browser can display, such as WebRTC or HLS.
I would personally leave screen mirroring as the fallback option. It should be possible, but it is much less elegant: you would need an AOSU app session running somewhere, then capture and relay its output, with additional latency and processing. On a battery/solar camera it may also keep the camera awake much longer.
One other thing: I would not rely on a simple “generic password” implemented only in the webpage for security. If you eventually build this, authentication should be handled by the local server/backend, and I would avoid exposing it directly to the Internet with port forwarding. Remote access through a VPN would be much safer.
So if I were approaching this, my order would be:
WAN-off test → packet capture → identify app/aosuBase local traffic → reverse-engineer that protocol → build the web interface last.
If you find that the app is already pulling Live View directly from aosuBase over the LAN, that would be a very promising breakthrough.