I’ve used this to get a Melpo RGB Floodlight working with an RPI3 running Octopi on my 3D printer.
I did run into an issue with how you’ve written the code, though… it wasn’t clear until I read the man page for gatttool that the double braces you’ve used around the “mac_addr” to indicate that this is a variable. It would be way more clear if you just drop the braces and just write it like the bash variable it is:
mac_addr="mac address of BT device to control"
gatttool -i hci0 -b $mac_addr --char-write-req -a 0x0009 -n cc2333
I wrote up a script for my own use case with the unique parts defined as variables so you can easily replace it with your own values:
Thank you @mainmachine for the feedback.
Indeed when I have put here the command I copied the line from the config file.
In the meantime I have swapped the BT controllers of the LED and replaced them with WiFi ones, from Shelly. It is much better and they are way more flexible.
I had not get that type of error in my tests.
It looks like the BT device is used by another program.
Have you checked if the BT device is up and running? Is the device address correct?
If not done yet, you could try in interactive mode to see where it gets stuck (below an example):
I successfully integrated my device thanks to your integration, but I can see it as a simple “light”, without any setting for RGB or brightness.
How can I manage colors and brightness?
The tricky bit I had to work around was the bulb expecting brightness between 1-100, but in hex which I solved in my bash script. Then Home Assistant wants to use 1-255…
I’m not sure what proxy you refer to. If your home assistant has bluetooth like Bluetooth - Home Assistant - that. Then most likely yes.
My script is very much customized for my bulb though. Don’t try just copy pasting it.
Ah I just found out about this - ESPHome Bluetooth Proxy - very cool and yes I think this would work but I don’t suffer from an overabundance of space.
Everything I’ve done is in the post you replied to.
That said, the first Melpo I got works with the above quite nicely, but as we’ve seen with the majority of these “generic” tier smart products, they can vary wildly from one batch to the next. Since the first one was working I bought 3 more, but these three won’t do any color but a weird bluish white!
I am toying with the idea of gutting one of the half-dozen dead RGB bulbs I have sitting around and frakensteining the ESP boards into the Melpo’s as I would rather have WiFi control than BT. That plan hinges on being able to salvage part or all of the smart bulbs boards… I’ve autopsied a couple - having worked with electronics repair professionally for 20 years, my first suspicion is failed capacitor(s) in the power circuit, and while I haven’t gotten further than visual assessment, they sure look like the kind of caps that like to keel over dead in gear like this. I would just repair the bulbs but reassembly with the A16 screw base is really sketchy as of course these are not designed for serviceability, sadly.
I can’t seem to get your custom component to find my led strip, it came with my desk but it has the ELK-BLEDOM brand when I tried to find it with Bluetooth Serial on my Android. I’m not sure if it’s my computer not wanting to connect to the device or what exactly
I have installed the ELKBLEDOM component, but when I add the integration using my MAC address BE:96:C2:00:00:52 and a name, I get an “Unknown error occurred” with the following error posted in in HA System Log:
*Logger: aiohttp.server
Source: /usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py:403
First occurred: 12:17:45 PM (1 occurrences)
Last logged: 12:17:45 PM
Error handling request
Traceback (most recent call last):
File /usr/local/lib/python3.11/site-packages/aiohttp/web_protocol.py, line 433, in _handle_request
resp = await request_handler(request)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
*
My ELKBLEDOM led strip has UUID: 0000fff0-0000-1000-8000-00805f9b34fb
Please let me know how I might be able to resolve this.