Mqtt battery draining - Githubissues

jl1990 commented 1 year ago

Describe the bug MQTT keeps the cameras active and drains the battery

To Reproduce Steps to reproduce the behavior. Example:

Run MQTT
Cameras will never be disconnected and battery drainage will happen

Expected behavior MQTT server should keep running, but cameras should be disconnected when we are not using them. Reconnection could be done when we need to execute a command in any of them.

Versions NVR software: - Neolink software: Last version Reolink camera model and firmware: Argus 3 pro

QuantumEntangledAndy commented 1 year ago

The issue with doing that is, if we are not connected how do we monitor the motion detection. We need to be logged in to get the motion events

Hoppersusa commented 1 year ago

The issue with doing that is, if we are not connected how do we monitor the motion detection. We need to be logged in to get the motion events

Sir, can you leverage the email trigger to avoid needing to stay connected? Maybe using new-tokio-smtp or similar. Sorry if that was asked about previously and did not make sense.

QuantumEntangledAndy commented 1 year ago

Maybe. Id also like to investigate the push messages. I suspect that the camera sends messages to Reolink for that so maybe we can get updates from there.

Hoppersusa commented 1 year ago

Push would be ideal if you can leverage that.

jl1990 commented 1 year ago

Yes, what you guys mention sounds great also and meanwhile something like that is investigated and implemented, maybe it's possible to turn off motion if you don't use it (my case) by config. My main use case is enable/disable the cameras and checking their pir status for the moment. For the motion events I already receive email + notifications from the app.

QuantumEntangledAndy commented 1 year ago

I'll see about making the motion optional and issuing it more as a on demand client instead. Maybe I can put a command for explicit connect/disconnect for the camera. Then you can tell mqtt when to listen and when your done issuing command for now.

QuantumEntangledAndy commented 1 year ago

I'm in the process of reverse engineering the push notifications. I have worked out the messages for my ios device, but I've hit a problem. I can emulate a push receiver for google (andriod) but not for ios. To continue I would need to observe the packets from an andriod to the camera.

For IOS it is this:

<?xml version="1.0" encoding="UTF-8" ?>
<body>
<PushInfo version="1.1">
<token>PHONES_UNIQUE_APNS</token>
<phoneType>reo_iphone</phoneType>
<clientID>SOMEID</clientID>
</PushInfo>
</body>

Does anyone here have an andriod and the ability to intercept packets sent from their andriod to their camera?

I'll try some things like guessing the phoneType as reo_andriod etc and see where it goes but official confirmation would be easier

jl1990 commented 1 year ago

I found some references to:

reo_fcm

as clientType.

QuantumEntangledAndy commented 1 year ago

Thanks I dumped the apk and found that too. It seems to accept the message now. But it is still not sending me the actual push messages. I'm wondering if I need to base64 encode the token or anything.

QuantumEntangledAndy commented 1 year ago

Tracking this in #85

jl1990 commented 1 year ago

PhoneType has a typo, it should be "Android" although I am sure this is not the problem. Just warning

QuantumEntangledAndy commented 1 year ago

That's just the selection option. What matters is the reo_fcm bit

QuantumEntangledAndy commented 1 year ago

But yeah my typos are everywhere

jl1990 commented 1 year ago

Hi,

Any update on this? Can we help somehow?

Thanks

QuantumEntangledAndy commented 1 year ago

Mostly I just don't have a lot of time. I do little things I can here and there.

If you can code your welcome to have a go at getting it started.

Easiest change would probably be adding a command to start and stop the camera and its associated threads. (The eventcam stuff)

QuantumEntangledAndy commented 11 months ago

For anyone coming to this issue. With 0.6.1 we have the the mqtt topic neolink/config you can enable/disable or add/revove cameras in this config through mqtt to force a disconnect and help save battery.

QuantumEntangledAndy commented 11 months ago

WIP disconnect on idle is on the branch feature/push_mqtt current build seems to be working.

Needs the following idle_disconnect = true in the toml

[[cameras]]
# usual options like name and pass
idle_disconnect = true

On no active users/motion for 30s is will disconnect the camera. When an active user OR a push notification is received it will reconnect

You can watch it in the mqtt at neolink/camname/status will swap from connected to disconnected also the last push notification raw json data is dumped into neolink/camname/notification

QuantumEntangledAndy commented 11 months ago

Finally got it to build on github here you might need to install openssl

fsedarkalex commented 10 months ago

So does this mean, the camera will never sleep, when mqtt is connected/enabled right now?

When talking about "active user" does this mean RTMP?

I mean, I am using Frigate and want to send the cam to sleep as long as the PIR is not detecting motion. When motion is detected, the camera should wake up and it's video stream should be analyzed by frigate. But of course frigate keeps an open connection to neolink for this.

QuantumEntangledAndy commented 10 months ago

Ok so the feature for idle disconnect is still in active development, it not in any formal release or on the main branch

The definition of active use depends on your config.

If you run just mqtt and idle_disconnect it will be disconnected 90% of the time unless you send a command over mqtt, inwhich case it will wake up the camera to run your command

If you have rtsp active, then your settings for on_motion and on_client matter, if both motion and clinet are false it will stay connected at all times. if eitehr motion or client are true then it will disconnect if there is neither motion detected or client connected.

Current issues:

Clients dropping us during pause, no frames are send so most clients e.g. frigate will drop up
BI client has a weird gray screen not sure why, don't own a windows to test this
Push notification thread is stopping, we use push notificaitons to wake up on motion, but for some reason the fcm listener stops working after about half an hour

fsedarkalex commented 10 months ago

Thank you @QuantumEntangledAndy for the detailed clarification! This puts the puzzle pieces together.

Great work so far!

fsedarkalex commented 10 months ago

For the BI issue... Maybe I have a similar issue with the branch version on Frigate now.

In Camera overview I can see a single frame and in "Bird View" (which should sho a live stream) the respective frame stays all white. Seems like ffmpeg is crashing.

2023-10-14 22:27:03.279752593  [2023-10-14 22:27:03] frigate.app                    INFO    : Output process started: 424
2023-10-14 22:27:03.279756590  [2023-10-14 22:27:03] frigate.app                    INFO    : Camera processor not started for disabled camera frontdoor
2023-10-14 22:27:03.289736701  [2023-10-14 22:27:03] frigate.app                    INFO    : Camera processor started for einfahrt: 427
2023-10-14 22:27:03.289741490  [2023-10-14 22:27:03] frigate.app                    INFO    : Capture process not started for disabled camera frontdoor
2023-10-14 22:27:03.299281445  [2023-10-14 22:27:03] frigate.app                    INFO    : Capture process started for einfahrt: 429
2023-10-14 22:27:10.606798182  [2023-10-14 22:27:10] frigate.video                  ERROR   : einfahrt: Unable to read frames from ffmpeg process.
2023-10-14 22:27:10.607002706  [2023-10-14 22:27:10] frigate.video                  ERROR   : einfahrt: ffmpeg process is not running. exiting capture thread...
2023-10-14 22:27:23.328616233  [2023-10-14 22:27:23] watchdog.einfahrt              ERROR   : Ffmpeg process crashed unexpectedly for einfahrt.
2023-10-14 22:27:23.328714508  [2023-10-14 22:27:23] watchdog.einfahrt              ERROR   : The following ffmpeg logs include the last 100 lines prior to exit.
2023-10-14 22:27:23.328789087  [2023-10-14 22:27:23] ffmpeg.einfahrt.detect         ERROR   : rtsp://*:*@192.168.XXX.YYY:9999/Einfahrt/sub: Operation not permitted
2023-10-14 22:27:30.753542194  [2023-10-14 22:27:30] frigate.video                  ERROR   : einfahrt: Unable to read frames from ffmpeg process.
2023-10-14 22:27:30.753699620  [2023-10-14 22:27:30] frigate.video                  ERROR   : einfahrt: ffmpeg process is not running. exiting capture thread...
2023-10-14 22:27:33.344056648  [2023-10-14 22:27:33] watchdog.einfahrt              ERROR   : Ffmpeg process crashed unexpectedly for einfahrt.
2023-10-14 22:27:33.344153660  [2023-10-14 22:27:33] watchdog.einfahrt              ERROR   : The following ffmpeg logs include the last 100 lines prior to exit.
2023-10-14 22:27:33.344230053  [2023-10-14 22:27:33] ffmpeg.einfahrt.detect         ERROR   : rtsp://*:*@192.168.XXX.YYY:9999/Einfahrt/sub: Operation not permitted
2023-10-14 22:27:38.471297188  [2023-10-14 22:27:38] frigate.video                  ERROR   : einfahrt: Unable to read frames from ffmpeg process.
2023-10-14 22:27:38.471384282  [2023-10-14 22:27:38] frigate.video                  ERROR   : einfahrt: ffmpeg process is not running. exiting capture thread...
2023-10-14 22:27:43.361065413  [2023-10-14 22:27:43] watchdog.einfahrt              ERROR   : Ffmpeg process crashed unexpectedly for einfahrt.
2023-10-14 22:27:43.361156725  [2023-10-14 22:27:43] watchdog.einfahrt              ERROR   : The following ffmpeg logs include the last 100 lines prior to exit.
2023-10-14 22:27:43.361213110  [2023-10-14 22:27:43] ffmpeg.einfahrt.detect         ERROR   : rtsp://*:*@192.168.XXX.YYY:9999/Einfahrt/sub: Invalid data found when processing input

For reference: My neolink is binding to port 9999 as it's running on the same server as frigate is. I am running it on docker in host network mode using local discovery

I find the "Operation not permitted" error interesting. This is not happening with the release version. It is specific to the push branch.

//Edit: But on HomeAssistant, the stream which I am pulling from Frigate is working. But it is way slower than it used to be. Feels like one frame every two or three seconds. So maybe its reconnecting all the time

//Edit 2: The stream is not stable on VLC, too. It has a huge delay (more than with release version) of about 20 seconds and you can see the stream sometimes hangs fo a few seconds. You see even the timer in VLC hopping sometimes. VLC is running for 5 minutes now and the timer IN VLC only shows 3:30. And it sometimes jumps back 1 or 2 seconds and continues from there. Very weird.

I did all this while constantly having motion in front of the cam. so the disconnects are NOT supposed disconnects.

QuantumEntangledAndy / neolink

Mqtt battery draining #69