Use camera's motion detection

QuantumEntangledAndy commented 3 years ago

Some camera's come with motion detection. I would like to have some way for neolink to signal that motion was detected.

For now I think just printing to std-out but ultimately I am thinking of some sort of control interface (maybe a rest API) would be good. I envisage we can add command and control to this control interface, PTZ turning the camera on and off etc etc.

Here are the relevent wireshark packets for motion detection

motion.pcapng.zip

It is just a BC packet of the msg-id 33:

Motion start

<?xml version="1.0" encoding="UTF-8" ?>
<body>
<AlarmEventList version="1.1">
<AlarmEvent version="1.1">
<channelId>0</channelId>
<status>MD</status>
<recording>0</recording>
<timeStamp>0</timeStamp>
</AlarmEvent>
</AlarmEventList>
</body>

Motion stop

<?xml version="1.0" encoding="UTF-8" ?>
<body>
<AlarmEventList version="1.1">
<AlarmEvent version="1.1">
<channelId>0</channelId>
<status>none</status>
<recording>0</recording>
<timeStamp>0</timeStamp>
</AlarmEvent>
</AlarmEventList>
</body>

digiblur commented 3 years ago

Excellent and no rush! Looking good.

QuantumEntangledAndy commented 3 years ago

I have a build with the LWT and the new connection status setup, will take about an hour for it to publish to docker but you can test after that :)

QuantumEntangledAndy commented 3 years ago

@digiblur Ok so I have a working LED status light change over MQTT.

Please try the latest docker

docker pull quantumentangledandy/neolink:mqtt

The control done via is:

topic: neolink/CAMERANAME/control/led
message: on or off

This is not perfect yet but it seems to be working... p.s. so many changes to our protocol were required!

digiblur commented 3 years ago

Been a few days since I've been able to circle back due to storm issues.... So the LED control kind of works. That's the status LED, the little one. There's another flood LED on the Lumus. Maybe a LED2? But it does indeed turn the little blue LED on and off.

I'm not sure if you got the LWT going yet, I don't see that one working yet.

QuantumEntangledAndy commented 3 years ago

Do you mean the red circle ones? Those are the IR lights, I have only ever seen the official client set thoses to "auto" or "close" so auto or off (close and off are the same things in some Asian languages). I can send it an "open" but since I have never seen the offical client send that it may not work

QuantumEntangledAndy commented 3 years ago

Also LWT should be up and working

digiblur commented 3 years ago

Do you mean the red circle ones? Those are the IR lights, I have only ever seen the official client set thoses to "auto" or "close" so auto or off (close and off are the same things in some Asian languages). I can send it an "open" but since I have never seen the offical client send that it may not work

Nope. Not the IR. I guess technically the Lumus has 3 LED types. The IR LED, the Blue status light and the 2 white flood lights. Guess it would be hard to snag the commands it sends without the camera itself in hand.

I will check the LWT maybe I am missing the topic.

QuantumEntangledAndy commented 3 years ago

Well if your willing to use wireshark and a desktop reolink client you can snag the packets for me and send me the dump

digiblur commented 3 years ago

Will do. Question on LWT, I was looking at the code quickly. Is the LWT topic and payload getting configured and sent at connect?

QuantumEntangledAndy commented 3 years ago

Yes its done on line 86 of mqtt.rs

        // On unclean disconnect send this
        mqttoptions.set_last_will(LastWill::new(
            format!("neolink/{}/status", name),
            "offline",
            QoS::AtLeastOnce,
            true,
        ));

Unless I have misread the docs on this

digiblur commented 3 years ago

I am not familiar with that library. I will have to read up on it. I know on the Arduino code side I had to set the will options. Set the topic and death message so the MQTT broker knows what to publish if the client falls off. On connect I had to send the birth message to the same topic.

QuantumEntangledAndy commented 3 years ago

Yep yep thats how I am doing it, birth message is sent on line 204 after the client receives conack from the broker

QuantumEntangledAndy commented 3 years ago

Birth message starts off as disconnected but swaps to connected right after reolink connects to the camera (which dosen't take long) it will swap to disconnected if the camera goes offline but neolink stays online.

digiblur commented 3 years ago

Ok at initial connect with the camera disconnected. I see two retains...the disconnected and motion off. That's good to see both of those agreeing.

Plug in the camera and wait for it to reconnect.

I can see the motion going on/off but the status is still disconnected.

brgavino commented 3 years ago

@QuantumEntangledAndy Just wanted to check in on this, since I'd like to use the PR as a base for an ftp event. I have a Lumus I'll be using for this test. Does it look like this will be merged to main? Or needs more testing?

QuantumEntangledAndy commented 3 years ago

@brgavino Do you mean my #78 PR? I think it will need some more work really, this is why it is a draft. I am also not sure how thirtythreeforty feels about binding neolink with mqtt. I also think that #83 or something like it that restructures the message BC structures should be completed first aswell. Perhaps we should ping @thirtythreeforty for his comments.

brgavino commented 3 years ago

@QuantumEntangledAndy Yeah #78 was what I was referencing. What dependencies do you see with #83 that are outstanding to close? Adding a general event forwarder interface could decouple mqtt, but the ability to send motion events is a big value add to the features here. If we have a plan for these PRs, I can pull in the right code to test ftp. Otherwise, I'll just take your last commit as a start and see what I can do.

digiblur commented 3 years ago

@QuantumEntangledAndy Yeah #78 was what I was referencing. What dependencies do you see with #83 that are outstanding to close? Adding a general event forwarder interface could decouple mqtt, but the ability to send motion events is a big value add to the features here. If we have a plan for these PRs, I can pull in the right code to test ftp. Otherwise, I'll just take your last commit as a start and see what I can do.

That would be great as not everyone wants MQTT, but for the ones that do, it's a game changer.

PieterGit commented 2 years ago

If you have problems with compiling this branch/PR, see https://github.com/thirtythreeforty/neolink/pull/78#issuecomment-894662456

sumade123 commented 2 years ago

I realise there are some commands implemented but not sure of the limits so far. Can the light of e.g. Reolink Lumus be controlled using a command from Neolink? I.e. turn on motion activation of LEDs, or turn off LEDs completely, without using Reolink app.

QuantumEntangledAndy commented 2 years ago

@sumade123 I want to add this kind of LED as it was requested some time ago. However the camera I use only has a status LED and IR LEDs not this flood light LEDs. It would be really good if you (or someone else) could send me some wireshark dumps that capture the packets that the official client sends to activate the lights.

petergam commented 2 years ago

You can find a dump from my Lumus attached @QuantumEntangledAndy. Frame 99 and 435 is turning the LED on and frame 255 and 572 turned the LED off.

Looks like the messageId is 288.

I hope this helps. Let me know if you have something that needs testing. Really looking forward to you getting some of your great PRs merged.

Lumus_led.pcapng.zip

QuantumEntangledAndy commented 2 years ago

@petergp thank you for the dump unfortunately this is using the newer AES firmware. It is AES encrypted and not easy for me to decrypt.

Assuming it is encryption mode 02: To decrypt it I would need the NONCE that is send in the login msg_id 1 and the password for the camera.
If it is encryption mode 03: To decrypt it.... we don't know at the moment that's on the todo list.

The easiest way to make it readable is to use an old reolink client that was released last year and record those packets. This should force it to use encryption mode 01 which is trivially breakable without any passwords.

petergam commented 2 years ago

Right, that explains why I wasn't able to make anything from the body.

I've included the dump from running an older version of the Reolink Android app in an Emulator. That version works a little different than the Reolink iOS app since the light will turn off after 180 seconds however this is configurable in the body as seen below. There must be a value for the duration that will turn it on permanently.

Turn on:

<?xml version="1.0" encoding="UTF-8" ?>
<body>
<FloodlightManual version="1.1">
<channelId>0</channelId>
<status>1</status>
<duration>180</duration>
</FloodlightManual>
</body>

Turn off:

<?xml version="1.0" encoding="UTF-8" ?>
<body>
<FloodlightManual version="1.1">
<channelId>0</channelId>
<status>0</status>
<duration>180</duration>
</FloodlightManual>
</body>

The relevant frames are 319 and 500.

Lumus_led_unencrypted.pcapng.zip

QuantumEntangledAndy commented 2 years ago

Thanks very much, I am going to finish of my PR motion based streaming then I'll try this one

thirtythreeforty / neolink

Use camera's motion detection #58