Support for controlling Reolink Floodlight #324
Comments
|
Not familiar with android, we just use the offical app and client from a laptop with wireshark to grab the packets. You might be better of with having some sort of packet capture on the router rather then the android. Have you seen our documentation about the protocols in dissector? I've listed all know messge types in neolink/dissector/messages.md and one of them might control your floodgate We have a branch that should be able to control LED state already in motionStream. Which you can use on that branch like this: neolink status-light --config=config.toml CameraName onI think it only does LEDs not flood lights but it might be a good place to start |
|
Thanks - I forgot that it would be trivial to capture emulator traffic by just running Wireshark on the emulator host, so I have a packet capture that I'm playing with. Woohoo! From what I can tell there are a few new message types. To start, it looks like message type Example: Shows up as: |
|
The newer xml traffic is AES encrypted, we know the key but wireshark dosent' have a decent AES decryption module built into it. The easiest thing is to usually use an older client (like two years ago) before AES was added. |
|
If your curious the AES is 128bit CFB You might be able to find an online decryptor to handle it |
|
Thanks - once I figured out the MD5, uppercase, and substring madness I got some useful messages! The cyberchef tool was useful to iterate fast: Also found that a wireshark filter of Most set events have this meta payload: <Extension version="1.1">
<channelId>0</channelId>
</Extension>Here's a turn-on (288) event... <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FloodlightManual version="1.1">
<channelId>0</channelId>
<status>1</status>
<duration>180</duration>
</FloodlightManual>
</body>Also received a message 291 (status update?): <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FloodlightStatusList version="1.1">
<FloodlightStatus>
<channel>0</channel>
<status>1</status>
</FloodlightStatus>
</FloodlightStatusList>
</body>And turn-off event (again 288): <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FloodlightManual version="1.1">
<channelId>0</channelId>
<status>0</status>
<duration>180</duration>
</FloodlightManual>
</body>I captured a lot more events too, expand to see...Setting brightness, type 290 - this also seems to be used to change the mode from motion to nighttime to schedule, and possibly set schedules: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FloodlightTask version="1.1">
<channelId>0</channelId>
<enable>1</enable> <!-- Seems to be if any of the motion/night/schedule settings are enabled -->
<alarmMode>1</alarmMode>
<preview_auto>0</preview_auto>
<brightness_cur>92</brightness_cur> <!-- default brightness, or only brightness if just motion mode -->
<duration>300</duration> <!-- seconds light stays on, at least with motion -->
<detectType>none</detectType>
<lastAlarmMode>2</lastAlarmMode>
<Schedule>
<startHour>18</startHour>
<startMin>0</startMin>
<endHour>6</endHour>
<endMin>0</endMin>
</Schedule>
<lightSensThreshold>
<lightCur>1000</lightCur>
<darkCur>1900</darkCur>
</lightSensThreshold>
<FloodlightScheduleList />
<nightLongViewMultiBrightness> <!-- night mode with usual/alarm brightness -->
<enable>0</enable>
<alarmBrightness>
<cur>100</cur>
</alarmBrightness>
<alarmDelay>
<cur>10</cur> <!-- seconds for alarm brightness -->
</alarmDelay>
</nightLongViewMultiBrightness>
</FloodlightTask>
</body>received a type 438 from the floodlight, some kind of status report again? <?xml version="1.0" encoding="UTF-8" ?>
<body>
<FloodlightTask version="1.1">
<channel>0</channel>
<alarmMode>1</alarmMode>
<enable>1</enable>
<lastAlarmMode>2</lastAlarmMode>
<preview_auto>0</preview_auto>
<duration>300</duration>
<brightness_cur>92</brightness_cur>
<brightness_max>100</brightness_max>
<brightness_min>1</brightness_min>
<schedule>
<startHour>18</startHour>
<startMin>0</startMin>
<endHour>6</endHour>
<endMin>0</endMin>
</schedule>
<lightSensThreshold>
<min>1000</min>
<max>2300</max>
<lightCur>1000</lightCur>
<darkCur>1900</darkCur>
<lightDef>1000</lightDef>
<darkDef>1900</darkDef>
</lightSensThreshold>
<FloodlightScheduleList>
<maxNum>32</maxNum>
</FloodlightScheduleList>
<nightLongViewMultiBrightness>
<enable>0</enable>
<alarmBrightness>
<min>1</min>
<max>100</max>
<cur>100</cur>
<def>100</def>
</alarmBrightness>
<alarmDelay>
<min>5</min>
<max>600</max>
<cur>10</cur>
<def>10</def>
</alarmDelay>
</nightLongViewMultiBrightness>
<detectType>none</detectType>
</FloodlightTask>
</body>message id 264 seems to be an audio configuration: <?xml version="1.0" encoding="UTF-8" ?>
<body>
<audioCfg version="1.1">
<channelId>0</channelId>
<timeout>0</timeout>
<audioSelect>0</audioSelect>
<volume>85</volume>
<preAlarm>0</preAlarm>
<pauseAlarm>0</pauseAlarm>
<pauseType>0</pauseType>
<pauseStartTime>0</pauseStartTime>
<pauseTime>0</pauseTime>
<audioListId>0</audioListId>
<linkageCtrlEnable>1</linkageCtrlEnable>
</audioCfg>
</body>Setting the motion sensitivity (type 213) is a bit different: <?xml version="1.0" encoding="UTF-8" ?>
<Extension version="1.1">
<rfId>0</rfId>
</Extension><?xml version="1.0" encoding="UTF-8" ?>
<body>
<rfAlarmCfg version="1.1">
<rfID>0</rfID>
<enable>1</enable>
<sensitivity>1</sensitivity>
<sensiValue>16</sensiValue> <!-- 11 is 90? this doesn't seem like a straight-up value to set... -->
<reduceFalseAlarm>0</reduceFalseAlarm>
<timeBlockList>
<timeBlock>
<enable>0</enable>
<weekDay>Sunday</weekDay>
<beginHour>0</beginHour>
<endHour>23</endHour>
</timeBlock>
<timeBlock>
<enable>0</enable>
<weekDay>Monday</weekDay>
<beginHour>0</beginHour>
<endHour>23</endHour>
</timeBlock>
<timeBlock>
<enable>0</enable>
<weekDay>Tuesday</weekDay>
<beginHour>0</beginHour>
<endHour>23</endHour>
</timeBlock>
<timeBlock>
<enable>0</enable>
<weekDay>Wednesday</weekDay>
<beginHour>0</beginHour>
<endHour>23</endHour>
</timeBlock>
<timeBlock>
<enable>0</enable>
<weekDay>Thursday</weekDay>
<beginHour>0</beginHour>
<endHour>23</endHour>
</timeBlock>
<timeBlock>
<enable>0</enable>
<weekDay>Friday</weekDay>
<beginHour>0</beginHour>
<endHour>23</endHour>
</timeBlock>
<timeBlock>
<enable>0</enable>
<weekDay>Saturday</weekDay>
<beginHour>0</beginHour>
<endHour>23</endHour>
</timeBlock>
</timeBlockList>
<alarmHandle>
<item>
<channel>0</channel>
<handleType>none</handleType>
</item>
</alarmHandle>
</rfAlarmCfg>
</body>I can add these to https://github.com/thirtythreeforty/neolink/blob/master/dissector/messages.md - unfortunately I didn't save the full bytes, but can go get them if that's useful for something |
|
Go ahead and add them to the messages.md. We should be able to work up a PR for controlling the floodgates from here. However ThirtyThreeForty hasn't merged many PRs lately (I think mostly he's moved on from neolink with other life things). I have limited write access to this repo from the days when ThirtyThreeForty was more active. (Cannot merge my own PRs). If you want it in master here you'll have to work up the PR yourself or you I can work it into my own fork which has other features like statusLED etc in it |
|
Sounds good, PR here: #327 Would be happy to have it in your fork as well. My goal ultimately is to control this via Home Assistant, so the MQTT support added in your fork is really interesting! |
|
I see. I have an mqtt in one of my branches. If you can work up the controls we can add it to there and then home assistant can send the command over mqtt. |
|
I'm working on a rewrite on my branch though and master is currently in a non operative state. Maybe be best to merge in to my fork after that is done. |
|
Yeah, for sure - happy to work on support over in your fork. To clarify, do you think I should wait until you're done with the rewrite to even start taking a look at adding support? Or are you just saying you'd like to wait until your rewrite is done before putting a PR up / merging the change? Either way is fine with me, just want to make the best use of my time! |
|
My changes are all happening in the rtsp folder so as long as you mostly working elsewhere it will be easy to merge in. So go ahead and get started if you want. Just need to warn you that rtsp functionality is currently non operative until after I've finished up but others should still work fine. |
|
Any chance progress has been made on this? I checked in @kevin-david branches and it looks like progress stopped in January. Wish I could help but I have never touched rust. |
|
Yep, my latest update is over here: QuantumEntangledAndy#14 (comment) Because my ultimate goal is to get it into Home Assistant, I started this discussion as well: starkillerOG/reolink_aio#20. But I think the better approach is going to be modifying Neolink, because porting that code is going to be a ton of work. That said @nmbgeek, if you know Python well, it might be viable to get something basic working. Unfortunately I haven't been able to prioritize taking another look at it for a while, and I am also very, very new to Rust so it's been slow going when I'm able to. In the meantime I'd recommend sharing feedback with Reolink about adding HTTP support for the floodlight in case they can trivially add that. |
|
I don't own one yet but did drop a message to their support and pre-sales consulting about adding HTTP to the Floodlight. Home Assistant is my goal here is as well. I currently have Sengled Motion PAR38 (zigbee bulbs with motion detector built in) but they don't seem to work 100% with ZHA and I would like to add more exterior lighting without having to run 120v. |
|
Thanks to some heroic efforts by @QuantumEntangledAndy, the floodlight is now supported in his fork: QuantumEntangledAndy#14 I'm planning to take a look at MQTT discovery next to get this wired up to home assistant easily, in addition to putting the MQTT version of the app into the shape of a home assistant addon. |
|
Thanks @kevin-david I had actually checked in on his repository yesterday and saw there was more activity. Do you happen to know if the PIR is directional or if there would be any other issue "ceiling" mounting it under my eave? |
|
@nmbgeek Not sure - I would recommend asking Reolink about it, since mine is mounted "normally" on a deck post. I can say the PIR is pretty sensitive at least, and it works much better than camera-motion-based detection. |
https://reolink.com/product/reolink-floodlight/ - is a relatively new device that after some reverse engineering appears to use the same protocol as the cameras do, unsurprisingly.
I hacked up a little test function and it doesn't seem like it'd be hard to at least get a few things working:
Things controllable via the app:
I'll keep hacking away as I get time but if anyone wants to collaborate, that'd be great!
Side note: any recent guides to getting a pcap file off an Android device? I used mitmproxy with an emulator, which worked but doesn't work well with binary data.
The text was updated successfully, but these errors were encountered: