H6159, H6008, H6003 BLE Support

[ddavidebor]

Thank you, I also have H6159, I tried other similar models but they are not compatible, please add support

[sagaciouszu]

I've got two H6008s but am unsure how to provide the correct information.

[ddavidebor]

I ended up chopping the cable and replacing the controller with a Zigbee one, had enough !

[treysu]

If anyone has any information on how to extract or construct these JSON files, I would love to take a shot at adding the H6008. I have several of them and would love to remove them from the cloud and control them locally.

[Fefedu973]

@treysullivent I have already done some of the reverse engineering work for h6159 and h6008 please check here to see how the Bluetooth packets are done https://github.com/Fefedu973/Universal-Govee-Bluetooth-control

[gparent]

I own both H6006 and H6008. I'm reading the JSON files and I only see scenes and special effects, nothing bluetooth protocol related. I do wonder if adding the empty file with no scenes would add preliminary support for these. I am otherwise going to return the H6008 and just use the 6006.

[gparent]

I was able to look at the Universal Govee Bluetooth Control code and some Bluetooth captures of my lights. The color control in that project is correct when the light is in RGB mode.

However, in the Govee application, when you are choosing white colors, you get to pick a color temperature between the 2700K and 6500K range*. When you do that, there are 5 additional bytes that are sent along with an initial RGB value, and these values are neither sent by the Universal Govee Bluetooth code nor this integration.

I think this is why choosing warm white/cold white with the H6006/8 can result in a lower brightness than if using the Govee app - the additional 5 bytes are dropped, and these seem to be the bytes that tell the (presumably CW/WW) LEDs in the bulb to do something.

Here's an example of me playing with the lights, in case somebody smarter than me can figure out what the meaning of the 5 bytes are.

In my testing, the btatt.value starts with 0x33 0x05 0x0d as documented, and the light sends a brightness packet right before the color one. Following the 0x0d bytes, here's the rest of the packets ([...] indicates N zero bytes):

['red', 'green', 'blue', UKN1, UKN2, Red2,Gren2,Blue2, [...], 'checksum'],
[ 0xFF,    0xAE,   0x54, 0x0A, 0x8C, 0xFF, 0xAE, 0x54, [...], 0xBD], # 0xFFAE54 # WW (10, 140)
[ 0xFF,    0xF9,   0xFB, 0x19, 0x64, 0xFF, 0xF9, 0xFB, [...], 0x46], # 0xFFF9FB # CW (25, 100)
[ 0x88,    0xFF,   0xC4, 0x00, 0x00, 0x00, 0x00, 0x00, [...], 0x88], # 0x88FFC4 # Green
-------------------------------------------------------------------
At this point I'm playing with illumination color but don't know which command is which.
-------------------------------------------------------------------
[ 0xFF,    0xFF,   0xFF, 0x19, 0x64, 0xFF, 0xF9, 0xFB, [...], 0x44], # ??
[ 0xFF,    0xFF,   0xFF, 0x0A, 0x8C, 0xFF, 0xAE, 0x54, [...], 0x47], # ??
[ 0xFF,    0xFF,   0xFF, 0x17, 0x70, 0xFF, 0xF4, 0xED, [...], 0x45], # ??
[ 0xFF,    0xFF,   0xFF, 0x0B, 0x54, 0xFF, 0xB6, 0x62, [...], 0xB0], # ??

Above, I have named them UKN1, UKN2, Red2, Gren2 and Blue2. I suspect the two unknown values have to do with warm white and cold white control, and maybe the last bytes are the RGB light settings but in color temp mode.

*Range according to the Govee application

[gparent]

The two "mystery bytes" are simply the color temp in hex facepalm.

It seems the RGB value is also sent along, I am not sure if this drives the LEDs or if it's complementary.

Cold White = (hex) 1964 fff9fb Warm White = (hex) 0a8c ffae54

[treysu]

I was able to look at the Universal Govee Bluetooth Control code and some Bluetooth captures of my lights. The color control in that project is correct when the light is in RGB mode.

However, in the Govee application, when you are choosing white colors, you get to pick a color temperature between the 2700K and 6500K range*. When you do that, there are 5 additional bytes that are sent along with an initial RGB value, and these values are neither sent by the Universal Govee Bluetooth code nor this integration. ...

@gparent This is a great start! Especially now that you've identified some piece of data that is not being sent by those integrations that seem to have trouble controlling the H6008.

Based on a somewhat low understanding of the different configurations of LEDs in the bulb, it sounds like the code is setup for a RGB bulb when instead we should have it set up as an RGBCW light. Now the question is, what is the simplest way to send along those extra bytes using this existing communication code.

I am new to any kind of BT or BLE sniffing, but I can't imagine it is so different than any kind of network communication. I don't have a spare Android, but I do have some ESP32 devices that might be able to help me.

[gparent]

I was able to look at the Universal Govee Bluetooth Control code and some Bluetooth captures of my lights. The color control in that project is correct when the light is in RGB mode. However, in the Govee application, when you are choosing white colors, you get to pick a color temperature between the 2700K and 6500K range*. When you do that, there are 5 additional bytes that are sent along with an initial RGB value, and these values are neither sent by the Universal Govee Bluetooth code nor this integration. ...

@gparent This is a great start! Especially now that you've identified some piece of data that is not being sent by those integrations that seem to have trouble controlling the H6008.

Based on a somewhat low understanding of the different configurations of LEDs in the bulb, it sounds like the code is setup for a RGB bulb when instead we should have it set up as an RGBCW light. Now the question is, what is the simplest way to send along those extra bytes using this existing communication code.

I am new to any kind of BT or BLE sniffing, but I can't imagine it is so different than any kind of network communication. I don't have a spare Android, but I do have some ESP32 devices that might be able to help me.

You're in for a treat today.

https://github.com/Beshelmek/govee_ble_lights/compare/master...gparent:govee_ble_lights:H6006-stock

This branch enables color temp control for H6006 and H6008. It probably has lingering bugs, but it's a start.

I need to check the licensing for that color temp conversion code and see if it can be replaced by an HA function instead.

[treysu]

@gparent Are you just converting temp to RGB? Typically I think these lights actually have different LEDs inside for RBG and Cool/Warm, so even if this looks really good, it may not be fully utilizing the bulb's features.

It really seems like just sending dummy bytes for RBG and then send the proper values for CW would be the solution, specifically based on what you discovered with the BT communication.

[gparent]

What I'm sending matches what the application sends for H6006/H6008. It seems to utilize the different LEDs unlike this repo's master branch.

I'll update the code further, but it will mean making my own personal branch and dropping support for everything I don't personally own. So I moved my original attempt in the H6006-stock branch.

[treysu]

@gparent I just installed this in Home Assistant using HACS, and it is not exposing any entities for each device. Is there some alternate way you are controlling the bulbs?

[gparent]

No, however I am using an ESP32 BLE proxy and I have not touched the API implementation, only BLE.

Also you have to make sure you are installing the H6006-stock branch.