Initial support for Govee devices
Protocol documented here: https://app-h5.govee.com/user-manual/wlan-guide.
Unfortunately, this officially documented protocol only supports a single color applied across the entire device, not per-LED or zone-based control for devices with multiple addressable zones. I have used this protocol to implement "Static" mode in OpenRGB.
Luckily, the Govee devices support a "secret" protocol used by Razer Synapse's Chroma integration, among other integrations used by the Govee Desktop application. We can use this protocol to implement proper per-LED "Direct" mode.
This is partially documented in the Signal RGB plugin: https://github.com/fu-raz/signalrgb-govee-direct-connect/blob/main/GoveeDirectConnect.js
I think that implementation is missing some protocol details regarding the data size byte though, and I'm still doing some research on LED matrix device control.
For this "razer" protocol, you format the json as so:
{"msg":{"cmd":"razer","data":{"pt":"<base64 encoded binary data>"}}}
The actual command is a binary protocol that gets packed into the json using base64 encoding. The binary protocol uses a packet with the basic format:
{0xBB, 0x00, <data size>, <command>, <data (variable length)>, <checksum>}
The second byte may actually be a second size byte, allowing for more than 256 bytes of data in a packet, but I haven't been able to confirm this.
The checksum byte is calculated by XORing all the bytes.
There are two known commands:
0xB1 - Razer Protocol Enable
| Byte | Value |
|---|---|
| 0 | Enable (boolean) |
Turning on the protocol by setting the enable flag to 1 means that the lighting will respond to the LED data commands. There is a 1 minute timeout, where if an LED data packet has not been received within one minute, the Govee device automatically turns off the Razer protocol and goes back to whatever its built in/app commanded effect is set to.
0xB0 - Razer Protocol LED Data
| Byte | Value |
|---|---|
| 0 | Gradient Mode (boolean) - if true, values are interpreted as a gradient applied across the strip, if false, treated as discrete color segments |
| 1 | Color count - Number of colors in packet, if this equals the number of LEDs on the strip then every individual LED can be controlled |
| 2-end | Color values in RR, GG, BB order. 3 bytes per color. The number of bytes in this section should be <Color count> * 3 |