@slashgob Thanks for the support, if I can think of anything I’ll let you know.
I had a quick chance the other night to try and get Xiaomi paired with the GW4C and while I could get it to connect with the china server it does not add the devices to your account but let’s you control them using AI voice commands which is not helpful. Hopefully I can get some more technical assistance on GitHub to try and port the protocol to Bluetooth
hey guys… not sure if this the right thread or not but it is the best match I could find. I have a couple LED floodlights that connect through the BRmesh app (so communicating via bluetooth). Do you know any way to integrate those type of devices to HA? I was thinking there should be a way to connect via bluetooth directly to the devices but can seem to sort out how…
I have spent my evening on analyzing the things, and here are some points:
BRmesh is basically a facelifted version of Broadlink BLE Light App, original app works too! BroadLink BLE App
Apps really use BT Mesh to talk with the lights, so iOS bluetooth tracing would not work, requires h/w analyzer, if anyone wants to go this path No, it is a fake “mesh”.
As a possible approach to understanding the protocol one can try reverse engineering these 2 Android apps (think JADX, produces nice, clear code)
I guess some kind of SDK exists, as the package inside both apps is called “cn.com.broadlink.blelight”
TLDR: Integration is very doable, app contains all the required structures and code, easy reversable. Someone, who is good in bluez mesh coding should take a look.
Fastcon BLE is not compatible with mentioned BT mesh implementations.
BLE scanner app won’t even see my lights, as they do not broadcast any services.
Broadlink Fastcon is something completly different and it uses “advertisment” frames for comms, no fancy UUID based stuff at all. I guess it is not a “bluetooth mesh” in classic understanding (and I have no idea if devices retransmit frames)
As we have (presumably) working Rust code, can re-implement it with something else, may be MQTT connectable.
ADDED:
It seems a quick dirty hack might be possible:
Use Android phone to setup your “mesh”
Use adb logcat to see which key was generated for it (key btw is just 4 bytes, not very secure imho)
Use Moody’s code (or rewrite it) to build BLE advertisment packets
Send them using system(), invoking btmgmt add-adv -d hexdatahexdata...... 1
I would try that on the weekend.
I can confirm that sending commands to the light using btmgmt works.
I was able to replay a packet, changing LED’s color.
I hope someone adapts it to a pretty HomeAssistant plugin, that would use DBus to communicate with the BT adapter. Or use ESPhome’s ability to broadcast advertisment frames. For now I’m using shell to invoke btmgmt, which is a very dirty solution.
Time permitting, may be I would do it myself. Thinking about something like Zigbee2MQTT, as things like mesh config, device grouping, etc would require it’s own web interface, unreasonable to do it inside HA instance.
As a note: there are LEDs that come with brLight app, while the App UI looks exactly the same as brMesh (may be designed by the same team) - the underlying BT comms are not compatible. Lights that come with brLight app really DO advertise as full fledge BT Mesh devices, but they are not fastcon and as such are not handled by this gateway.
the code below is a working example for the ESP32 compiled with Arduino IDE. It turns one light on/off once a second.Tested with this light → Amazon.de
The code is based on java script code of @ArcadeMachinist.
Maybe this code helps finding a solution available in Home Assistant or ESPHome (maybe derived from BLEAdvertising class).
I’m not an expert in Home Assistant or ESPHome, so I can’t do it, sorry.
Nice. I would make a dedicated ESP32/MQTT node for sending these broadcasts.
Now I run my Python code on the same machine with HA.
brMesh is advertished as mesh, but in fact it is not. So if HA host with BT stich is too far away - it won’t work.
Placing dedicated ESP32 sender near the far away lights would solve the problem.
This looks very promising indeed. Will that implementation work with any of the lights that are using the BRmesh app or is it specific to the brand you tried it with? I have a set of these lights and am hoping that there is a path to get them in HA eventually… https://www.amazon.ca/dp/B01N6PKKBP?psc=1&ref=ppx_yo2ov_dt_b_product_details
Any lights, that are supported by brMesh.
In fact I have just installed 2 of the lights, you are mentioning above, today.
(amazon.com/dp/B09QHQBZC9)
Works perfectly.
hey there… so your instructions looks like they are using Android phone to figure out what the key is. Is there a way to do that using the iPhone app (or a different way by using the Debian box directly?)
Not a way that I know of.
Also iOS app does not expose the key in logs.
But you can borrow Android from someone then, do “Share home” from your iPhone via QR code to Android and then get the same key, so you won’t have to re-learn all the lights again.
The whole thing can be theoretically done from the gateway, but I do not have time to code it right now.
Ok so I have an android tablet. I installed BRmesh on there and can control the light. I installed adb on it but when I run that command I get waiting for device but nothing happens. I switch to BRmesh and do some different commands etc but when I go back to the terminal window it is still just sitting there on waiting for device. I must be missing something… is there something else I need to do?
Thanks. I did go through that previously and turned on USB debug. Do I need to reboot the tablet after turning on USB debug? It didn’t seem to make any difference for me.
oh sorry so maybe that is where I am not getting it. I have not used adb before. I was trying to run the adb command on the same android device in a terminal window. So I am supposed to connect android to a separate computer via USB and the run adb command on that other computer?