Support devices without HTTP API (such as Reolink Floodlight)

[kevin-david]

I know this would be a lot of work - but mostly wondering if you're open to a contribution if I find some time, and what approach would be acceptable.

As of today, this would require supporting the "Baichuan" protocol which is best understood by looking at this repo: https://github.com/QuantumEntangledAndy/neolink (and the one it's forked from) along with the blog post here: https://www.thirtythreeforty.net/posts/2020/05/hacking-reolink-cameras-for-fun-and-profit/

I took a stab at implementing this with the existing neolink tool here: QuantumEntangledAndy/neolink#14. But it's still a bit of a mess.

More context and previous ideas I had here: fwestenberg/reolink_dev#599 (comment)

[starkillerOG]

I will not have time myself to work on the "Baichuan" protocol.

A disadvantage will be that this is not a official API and that in the best case it can break when Reolink makes some changes or implements it diffrently in future models, and in worse case Reolink could actively try to protect their "Baichuan" protocol better by changing encryption keys or encryption protocols.
We can also not ask Reolink to inform us about these things since this "Bauchuan" protocol is not ment to be used outside of Reolink, they have their HTTP API for that. So they will probably not be willing to help us with it.

That beeing sad, I am open to Pull Requests that would include the "Baichuan" protocol as a backup to the HTTP API.
I do want to have it seperated as much as possible, so the 2 approaches that would be acceptable to me:

1. have a seperate reolink_baichuan pypi library (or use the neolink library if it is maintained) that exposes easy commands much like this reolink_aio library. This reolink_aio libary could have the reolink_baichuan library as a dependency and use it as backup for the HTTP API.
2. have a seperate baichuan folder inside reolink_ai folder of this library in which there is a baichuan.py file which has a class that exposes the baichuan protocol as simple commands (much like the "Host" class of this library). That class can then be used as backup in the Host class.

Possible use cases:

• _login_try_ports when both the HTTP port 80 and HTTPS port 443 fail first, use the baichuan protocol on port 9000 to get the NetPort settings, if needed enable the HTTPS and other required ports and look up the correct port numbers to use. After that, go back to the HTTP API using the port just enabled/looked up.
• Have some decorater for functions in this library (@baichuan_fallback or something) that will make sure that if the HTTP protocol is not supported by a device (seperate floodlight for instance), that it will fall back to the baichuan protocol implementation of the same function that will need to return/set the variables in exactly the same way as the current function, but then using the baichuan protocol implementation.

I will review PRs to this libary and try to help if you @kevin-david have the time to implement something like discribed above.

[starkillerOG]

I just saw that neolink is not written in python, which makes it much harder.
It would need to be completly ported over to python...

[xannor]

tempting.... That was one of my goals with the prior code I was working on, to have a base reolink api and a baichuan and rest variants. However what I think may be a bit more practical, is an addon similar to what neolink does, that pushes events into HomeAssistant. This would work around some of the ONVIF shortcomings, and handle other client/device driven events that are not strictly motion, i.e. PTZ updates and light/storage statuses, etc. I might try to tackle that once I have the media playback in some form of stable state.

[kylepyke]

Is this still in the works?

[starkillerOG]

@kylepyke I don't think any current progress is beeing made.
However Reolink just anounced a "Home Hub" at CES, that is a kind of NVR for battery powered cameras.
It will provide battery powered camera's with the HTTP API through this "Home Hub" and schould therefore make battery powered camera's compatible with Home Assistant.

However it is still unknown when this "Home Hub" will be available for purchase, probably later than Q1 2024...

[ncul777]

@starkillerOG I just received a Homehub to which I will connect some battery cameras (currently Argus 3E and eventually the battery doorbell when available), and while I have find the HTTP api v8 pdf , I'm not not sure that applies when using the Home hub. Would you be able to point me in the right direction? Thanks

[starkillerOG]

Yes the HTTP api v8 pdf does apply for the HomeHub.

Moreover the HomeHub will work perfectly fine with this reolink-aio library. Including the battery camera's connected to it

[ncul777]

Great work! I managed to capture snapshots from 2 cameras (Argus 3E and Lumus) via the homehub, using your library.

[kylepyke]

Yes the HTTP api v8 pdf does apply for the HomeHub.

Moreover the HomeHub will work perfectly fine with this reolink-aio library. Including the battery camera's connected to it

This is good news! Any idea if the Reolink PoE floodlight will work?

[starkillerOG]

@kylepyke at the moment likely not, but I can probably get it to work now in HA using the build in integration with not too much issues.

I am planning on getting a Reolink PoE floodlight to implement the code. But at the moment I am way too bussy with bug fixes and other improvements. But it is on my too do list.