Auth password and RTSP

[SirLouen]

I've been following all your steps, and I've tried to move a little further without much success (towards being able to open RTSP)
It feels that your cam it's almost the same as mine because at least the 8090 authentication is exactly the same

I've created this repo to document my specific cam model (and all related/equivalent models)
https://github.com/SirLouen/zs-gx1s

I think it would be wonderful to have RTSP with this cam, as https://github.com/guino was able to do with his multiple cams (I've tried his methods, but they don't work)

The only thing that I was wondering: How did you find those credentials?

User: PpStRoNg

Password: #%&wL1@*tU123zv

[youribonnaffe]

Hello,

I found the credentials in this issue guino/BazzDoorbell#35. I was testing all the username/password I could find from this repository and others and that one finally worked :).

[SirLouen]

I found the credentials in this issue guino/BazzDoorbell#35. I was testing all the username/password I could find from this repository and others and that one finally worked :).

Nice, I'm finding some light. I'm wondering if I could modify the firmware to set up a RTSP access from there

[SirLouen]

@youribonnaffe were you able to touch the camera firmware files? Or you just analysed the CloudEdge's app?

[SirLouen]

I've seen that your cam has the similar fashion as the ones from @guino like BazzDoorbell so technically you should be able to access the /proc/ endpoint in your side

After doing a quick check to your firmware, I clearly can see in the initrun a reference to ppsapp. Maybe if you send your ppsapp to guino he can help unlocking it.

[youribonnaffe]

I wanted to avoid messing the firmware as I was a bit afraid to brick the device. So the only things I did was trying to reverse engineer it with Ghidra but without much luck (well lack of skills probably, I'm not too familiar with the tool).

So I mostly focused on the CloudEdge app indeed.

[SirLouen]

So I mostly focuses on the CloudEdge app indeed.

Check CloudEge API, I saw that there is an ONVIF parameter to be activated. Reading some comments in several forums I see that certain models have an option in their CloudEdge App called "Advanced Options -> Enable ONVIF". Not sure if yours has it. Mine certainly not.

In my case I don't care bricking the system, because technically for me the cam as is right now, it's completely useless. I had it as a gift, but I cannot take use of it because it's not working with my Home Assistant system without a stream protocol open.

[jonwedell]

@SirLouen - Did you see this comment? From it, I was able to see that http://xxx/devices/snapshot works for my camera, which I suspect is very similar to yours. It's no RTSP, but at least it's something, and enables me to add the camera as a low frame rate camera in Home Assistant.

Hoping you have more success finding a way to enable RTSP though!

[SirLouen]

@SirLouen - Did you see this comment? From it, I was able to see that http://xxx/devices/snapshot works for my camera, which I suspect is very similar to yours. It's no RTSP, but at least it's something, and enables me to add the camera as a low frame rate camera in Home Assistant.

Hoping you have more success finding a way to enable RTSP though!

Looks really interesting the snapshot thing.

Following the little trick of @youribonnaffe I've been able to start both CloudEdge + Factory mode with 8090 open, so it's not amazing, but at least it renders the cam something useful

I was discussing this topic with @guino and basically I can say that the quest for RTSP is extremely complex for me at this point

guino/Merkury720#23

Although I think I'm going to install the cam "as-is" (and this little tweak maybe makes it more usable home-assistant wise) and maybe in some months I will uninstall it and continue a little bit further with a programmer or something (or maybe luckily someone is able to find a wifi-driver for this chipset to fully support OpenIPC.

For what I need for the next 3 months, the cam will be ok: maybe taking some snapshots every 1 second for 60 seconds after my garage door opens and having a real-time view in case I need it.

What I'm not sure if I would be able to achieve with Home Assistant is having a motion detection enabled system that stores directly on my NAS instead of the SD of the cam. I know that Home Assistant has different cam modules, which is your low frame rate config that works? Generic Camera Platform?

[SirLouen]

Configured as Generic Camera integration

And seems working fine (lagging but not much more than default app). SD quality image I've also noticed (not 1080).

I remember that @guino reported this by default and had to tweak it, but in this case, I seriously doubt that much more can be done.

I'm more than happy with this integration, lost all the hope in this cam

[youribonnaffe]

Even with the SDCard workaround for the ppsFactoryTool I still have issues to fully use the CloudEdge app (local recording was not working anymore). So I preferred not to use and rely on the app.
Starting recording remotely would have been nice. Then I would have coupled it with my home alarm to start recording and keep recording when an intrusion is detected by the motion sensors.

[guino]

There is probably a way to use the snapshot url (low res, slow frame rate and no audio) with ffmpeg and/or a script and serve it as a RTSP stream but it would require running it on a 3rd device (i.e. computer/pi board) so you could use it as a standard RTSP source and record it onto NVR, etc. Again not much of a solution, but could help if all you can do is use RTSP -- MJPEG is most definitely possible with a script and simple web server as we used to do it on the tuya cameras directly (before I wrote an application for it).

[SirLouen]

I've found the idea instead of introducing the snapshot system in Home Assistant, I would fully control it through MotionEye, which has more I would expect from a Camera management system, and then I would use an integration with HA for MotionEye. Also AFAIK, there are some API calls that indicate some important parameters like battery and other aspects of the cam worth being monitored now and then. I think with the snapshot + other API calls I won't ever need CloudEdge app more, and I don't truly need a RTSP stream. a JPEG Camera is more than fine and I believe this cam is designed to work in this mode exclusively.

[SirLouen]

Testing all this now, I've found a tremendous issue I have not realized before: on factory mode, the battery discharges extremely fast. Not sure why, probably the sensor is permanenty active. Not sure how CloudEdge app was able to detect motion without having the sensor permanently active though.

Also another issue: if the cam restarts with the SD inserted, it will go into factory mode and permanently drop the CloudEdge connection. To have a stable cloud edge connection it's required to insert SD way before the CloudEdge has been configured, kind of weird.

But if I do the other way around: I insert the SD and instead of leaving it I remove it and restart the cam, what works is the app, not the factory mode.

One or another, not the two at the same time after a restart.

[jonwedell]

Yeah, I just discovered this same issue myself: the battery dies within a day when in factory mode. I suspect you are correct that the sensor is permanently active. I haven't yet had a chance to check what Home Assistant is doing - is it possible it's getting a snapshot even when you aren't using the interface? If so, I could easily see that draining the battery.

My understanding is that the camera has an IR motion detector built in and then only activates the camera when the IR motion sensor detects motion. IR motion detectors use very little power.

[SirLouen]

Yeah, I just discovered this same issue myself: the battery dies within a day when in factory mode. I suspect you are correct that the sensor is permanently active. I haven't yet had a chance to check what Home Assistant is doing - is it possible it's getting a snapshot even when you aren't using the interface? If so, I could easily see that draining the battery.

My understanding is that the camera has an IR motion detector built in and then only activates the camera when the IR motion sensor detects motion. IR motion detectors use very little power.

Make sense, probably the cam has a passive IR sensor, it has IR embeded for sure for all the night vision and that. In that case maybe it also has a signal to wake up the camera and put it to sleep. I saw this 2 endpoints:

/sys/active/
/sys/sleep

I went for lunch and left the cam configured with the CloudEdge. When I returned, the cam was off.

Within cloud edge there are two parameters for battery saving: Shooting interval and Maximum Shooting Time.

[guino]

@SirLouen most battery operated cameras stay in 'sleep mode' and only wake up when there's activity (app access or motion detection) otherwise the battery dies quickly -- it is unlikely you'll find a battery operated camera suitable for RTSP/ONVIF (continuous streaming) the battery would just drain very fast, that said: you could probably wire up a power source if you wanted to use it continuously.

[SirLouen]

My understanding is that the camera has an IR motion detector built in and then only activates the camera when the IR motion sensor detects motion. IR motion detectors use very little power.

Just for research purposes, I've been able to do the biggest botched job in the history of cams:

First I set up this snapshot cam in HA as a generic cam. For some reason HA has the ability of creating a MJPEG stream out of a JPEG still image. I've researched like many systems like mjpeg-streamer, gstreamer and motioneye and any of those were able to create the MJPEG stream I was looking for

The only problem of HA MJPEG stream I have not been able to solve yet, is that I access the stream with a temporary token through API. An URL like this:

http://localhost:8123/api/camera_proxy_stream/camera.zsgx1s?token=ac0f1f916217f6ee9d27a545c2f4174066ff5a17c428774b53a8e848204d0e0b

The problem is that this token expires after a time, so I have to regenerate the token now and then. Is not a permanent solution, just for testing purposes.

Theoretically the right method to access this stream API is via Authentication with a Bearer Token problem is in the next step

After testing every single system out there with Docker images, I've found out that Frigate is simply amazing. I used in the past a lot ZoneMinder and I even developed for that DVR software. But Frigate is the real deal nowadays, hyper simple, but at the same time, extremely sophisticated.

But obviously the problem is that Frigate cannot process the MJPEG stream from the API with a Bearer auth (at least to what I know). So I have to test this temporary solution with that temporal token URL I mentioned above.

And also unfortunately, Frigate cannot process a single still snapshot HTTP URL like HA Generic cam does. I don't see a bright future for my battery shitty Wifi cam so I've recently bought an Amcrest cabled cam, that is seemingly full compatible with this kind of Frigate DVR.

But it has been interesting (and time-consuming) playing with this shitty ieGeek cam and trying to do something almost useful beside CloudEdge's world.

wire up a power source if you wanted to use it continuously.

BTW I could not manage to use the integrated PIR detector. Now I have it wired to the USB cable permanently. It will never probably see the light because I will keep it in the workbench to see if at some point someone is able to free it a little bit. At this moment I don't really see an advantage of activating RTSP at all.

To simply accepting the situation and working with what we currently have, I think that the idea of @youribonnaffe was pretty neat considering what we have in the table: interacting with the CloudEdge's API to perform very basic actions like closePush