Are there currently any integration for Xiaomi Monitor Light Bar?
https://www.mi.com/global/mi-computer-monitor-light-bar/overview
It includes a “2.4-GHz wireless” remote (but I’m not sure if it’s wifi or zigbee).
I can’t seem to find any documentation to get it into some sort of pairing mode
+1
Integration would be great, especially that the included remote is not the most handy remote ever.
+1
It’s based on the “TLSR8516EP16” (The main control of 2.4G wireless mouse)
sources:
Sorry for being late to the party. I’m writing down some notes for anyone looking for a way to control this light from their system. I am in no way able to provide a reliable integration for the light as it requires capturing the on-air traffic with an additional hardware for 2,4 GHz wireless communication - this is only a set of random notes if anyone has more time and energy to make something useful out of them. 
So, the device uses Telink chip combo for communicating via a proprietary 2,4 GHz wireless protocol. Luckily, the protocol can be listened to and rather reliably replayed by using a cheap nRF24 device from AliExpress. The device must be connected to a host controller via SPI bus - I haven’t tried connecting it to a desktop computer, but it can be used on a Raspberry Pi, Arduino, ESP8266/ESP32 or any similar SPI-capable controller.
On-air protocol is structured and I haven’t tried reverse engineering it. What I was able to do is to configure nRF24 device to be able to read and send (replay) compatible packets although not according to nRF24’s own proprietary protocol. I did try using nRF24’s protocol with various configuration options (address lengths, ShockBurst protocol on/off, CRC settings) but was unable to find a working combination. Probably due to different CRC polynomials that are used in the check protocol. It would be theoretically possible to statistically find them but this is an overkill for my intentions (just turning the light ON when I unlock the computer).
nRF24 configuration that works for me is as follows:
I was able to record several data packets for turning the light on/off by configuring nRF24 device according to the parameters above. Because I am using sync preamble (0xAAAAAAAAAA - bits 101010…101010) as an address, nRF24 will capture practically any 2.4 GHz device in viscinity transmitting on the same channel so a bit of statistical analysis and well-timed testing is needed to extract the packets from the light’s remote. Payload, as reported by nRF24, therefore contains the device’s address, and an actual payload according to the manufacturer’s settings. Particular structure of the manufacturer’s payload is of no significant importance if you just want to replay the stream to turn the light on or off.
One thing to note - the remote uses the same packet for turning the light on and turning the light off. Obviously - it uses the same button and the remote does not track the state of the light and change the packets. Button press works every single time and toggles the lamp, regardless of the state the lamp is in.
Now, one thing became obvious during my tests - the light and the remote do use an 8-bit counter somewhere in the protocol to avoid reacting to duplicate packets (I assume the remote uses frequency hopping or packet retransmits and sends the same packet on different channels and/or retransmits it on the same channel several times).
Consequently, I have to replay every packet from my list of captured packets at least 16 times to get the light to react to it - especially if I am turning it on and off with a remote in between as well. 16 times is enough according to my tests.
Additionally - due to the aforementioned counter - the light refuses to react to the same packet after it has already been “used” until a different packet has been acknowledged. In practice, this means that you can either turn the light on or turn the light off with a single packet but you cannot reuse the same packet later to toggle the light’s state if you haven’t used the remote in between and changed the internal packet counter. I am therefore using two packets and just cycle between them on every on and off action.
Similar method could probably be used for replaying other signals the remote sends to the light (brightness, light temperature, …) but I haven’t tried it as I don’t need it.
***edited to add, these are the packets that work in my case. I don’t know whether every device has its proprietary address or all bars share the same one, so these may work for you.
{0x67, 0x22, 0x9B, 0xA3, 0x89, 0x26, 0x82, 0x40, 0x37, 0x2C, 0x1F, 0xEF, 0x20, 0x20, 0x07, 0x0E, 0x10},
{0x67, 0x22, 0x9B, 0xA3, 0x89, 0x26, 0x82, 0x40, 0x37, 0x2C, 0x1F, 0xE2, 0xC0, 0x20, 0x11, 0xE5, 0x50},
{0x67, 0x22, 0x9B, 0xA3, 0x89, 0x26, 0x82, 0x40, 0x37, 0x2C, 0x1F, 0xE3, 0x40, 0x20, 0x1F, 0x49, 0x60},
{0x67, 0x22, 0x9B, 0xA3, 0x89, 0x26, 0x82, 0x40, 0x37, 0x2C, 0x1F, 0xE4, 0x00, 0x20, 0x1F, 0x05, 0xE0},
{0x67, 0x22, 0x9B, 0xA3, 0x89, 0x26, 0x82, 0x40, 0x37, 0x2C, 0x1F, 0xE4, 0x40, 0x20, 0x12, 0xC9, 0xE0},
Thank you for this information.
Can you explain, How you get it work?
Maybe Electric circuit and programm code 
@akomelj Have you had any further progress with this? Otherwise, I’ll take another look at it with an nRF24 module I have laying around.
I used the information in @akomelj 's post to put together a small program for an arduino nano that manages to replay captured messages and, so far, manages to reliably switch the light on and off. Perhaps it’ll prove useful to someone
Does your program still work for you? How have you integrated it into HA?
I would really want to buy this device in contrast to the way more expensive Yeelight one.
Are there any updates on this topic? I got your code to work (Well, I just hit compile. Thanks a lot for your code!), but I am more interested in reading the signal rather then sending it. At the moment, I can only read a signal with some luck, I am missing most of them. Does anyone have any ideas how to capture them more reliable?