I hesitate to even call this a work in progress with how little I’ve accomplished so far, but I’ve been doing a bit of reverse engineering trying to get my Govee BLE lights working with HA. So far all I’ve got is a template switch setup like the following. (The loop is necessary since the devices are pretty flaky, even with the official app.) Replace BT_ADDR with the address of your device. So far I’ve tested this with the H6181 and H7311.
I’d like to eventually get proper state reporting as well as brightness and color control where available, but I know next to nothing about Bluetooth so it’s been slow going. Hope this might be useful to someone anyway.
switch:
- platform: command_line
switches:
light1:
command_on: bash -c 'for i in {1..5}; do gatttool --char-write-req -b BT_ADDR -a 0x0015 -n 3301010000000000000000000000000000000033 && break || sleep 0.5; done'
command_off: bash -c 'for i in {1..5}; do gatttool --char-write-req -b BT_ADDR -a 0x0015 -n 3301000000000000000000000000000000000032 && break || sleep 0.5; done'
friendly_name: Light 1
PS - I don’t really know what the specific values mean. I just sniffed them from the Govee Android app and they work for me.
If you want to improve code quality when you set up multiple lights, set up a shell command, make the Bluetooth address a changeable input in service data, and then use template switches.
Hi, I also played a bit with Lights over BLE … may be of interrest:
Are we allowed to use that BLE directly, as it isn’t official (well, I know I am allowed in Austria, but I don’t know the reverse engeneering rules worldwide).
Thanks! I searched for existing code but somehow didn’t find this. It doesn’t seem to work for me immediately, but at the very least I expect there’s some useful info I can get from there as they seem to have implemented a number of useful features. As far as the legality, I believe it’s generally legal for the purposes of interopability which is all I’m doing here.
I thought of an abstracted library which uses bluetooth and api. Both encapsulated in their own library but used from my integration and a meta library. I didn’t find the time for it jet.
@LaggAt, I have played with the https://github.com/chvolkmann/govee_btled library , interfacing it to mqtt for home assistant to use. I used a separate raspberry pi to talk directly to the govee bluetooth bulbs.
I was mostly successful making it work, though there are many times when it times out when creating the BluetoothLED object referenced in the library.
@michaelmior, I suspicion that is why you have the 5x loop around gatttool to turn on and off the bulb in the example beginning this thread. to make certain that it worked.
Here is a section of the configuration.yaml that gets the info from mqtt in the light: section.
@michaelmior, I’m thinking I might use the example command line stuff you show in the initial post using gatttool in my code to handle all the bluetooth activity in lieu of the chvolkmann bluetooth library stuff to set colors, brightness, etc as in the configuration.yaml.
Hi, I also remember having random errors, needed to reconnect regularly. As the Govee App works very well they must do something different.
It would be really great to have an integration supporting both, BLE and WIFI/API, which decides on it’s own what to use. With that instabilities this is a very hard task to do. Oh, and I have never tried to access the BLE on my RPi4 from within the container. No idea if that works
I’m very interested in your progress here and will listen closely. Thanks so far.
In my case, the Govee app doesn’t work very well either. It often disconnects and I have to retry. So I assumed this is just flaky hardware. In any case, having the loop doesn’t really bother me. I would like to get notifications set up though so I can do proper state reporting.
Accessing within the container has been working fine for me. I first tested using the SSH add-on and I had to install gatttool, but it’s already installed in the container actually running HA, so no issues there.
What I’m saying is that using the official Govee app I find things to also be unstable. In any case, the retry adds minimal delay and I’d rather just do that than be constantly broadcast the keep alive.
One thing I noticed mentioned with the chvolkmann and pygatt library was it was kind of a kluge getting confirmation that a connect was established with the bluetooth bulb.
I am guessing that in @michaelmior s original was that he did a loop around the gatttool command to make sure it worked .
From what I have read, the command line gatttool has been deprecated, though it is still on the buster version of raspbian OS.
there is a pygattlib different from the library above that does not use the gatttool command line for transmitting data. so that may be something I am going to look into sometime in the future.
Also, as mentioned by @p1ranha, a keep alive packet needs to be sent at least every 2 seconds, and I plan to implement that in the code I am working on.
You’re correct that the loop is because the command doesn’t always succeed. As for the keep alive, it doesn’t need to be sent. Things are working perfectly fine for me without it. There is a sometimes little bit of latency in responding to commands which might be removed if I implemented keep alive. But given that I am controlling the devices fairly infrequently, I don’t think it’s worth the hassle for me.
I have modded my python script to account for the 1.5 second ping, and it is now working very well with no issues while the bulb is powered on.
When the bulb is turned off, or is out of range of bluetooth with the Rpi that i am using to be the bridge from the bluetooth bulb to mqtt, the bluetooth library errors, so I have wrapped a shell script around it that restarts the python script waiting for a new connection to the bulb.
All the shell script does though is just a while loop around the python script.
Thanks!