QuantumEntangledAndy
Mqtt battery draining
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
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
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.
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.
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.
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.
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
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.
PhoneType has a typo, it should be "Android" although I am sure this is not the problem. Just warning
That's just the selection option. What matters is the reo_fcm bit
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)
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.
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
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.
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
Thank you @QuantumEntangledAndy for the detailed clarification! This puts the puzzle pieces together.
Great work so far!
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.