Local Bluetooth control of Cync / C by GE devices, as a Home Assistant integration. No DNS redirection. No cloud in the loop at runtime.
Warning
Early. Setup has been run against a live Home Assistant install; nothing
past it has. Config flow, coordinator, and switch/light platforms exist and
pass their own test suite. The config flow has been exercised on a real
install — which is how the cloud-client rewrite below was found — but no
device has yet been controlled through this integration end to end. No colour
temperature or RGB control - not confirmed over this transport, see below.
No confirmed live state readback - every entity assumes the last command it
sent succeeded, not anything read back from the device (see ARCHITECTURE.md's
local_polling section for why). The coordinator does opportunistically try
the same subscribe the real apps use, on the chance it holds, but this has
never been observed to succeed on a local Bluetooth adapter - assume the
assumed-state behaviour is what you'll actually get. Not yet submitted to
HACS or home-assistant/brands.
The sibling of cync-lan, which
controls the same devices over TCP by impersonating the vendor's cloud server.
This one talks to them directly over their Bluetooth mesh instead.
cync-lan requires DNS redirection: you point the xlink.cn hostnames at
Home Assistant on your router, and devices connect to it thinking it is the
cloud. That works well and keeps everything local, but it is the single biggest
setup obstacle and the cause of most support traffic.
Bluetooth needs none of it. The trade is a Bluetooth adapter within range of your mesh — or an ESPHome Bluetooth proxy, which Home Assistant supports natively and which this integration is deliberately designed to work with.
cync-lan |
this | |
|---|---|---|
| DNS redirection | required | not needed |
| Needs a mains-powered bridge device | yes | no |
| Bluetooth in range | no | yes (proxies count) |
| Cloud at runtime | none | none |
| Feature coverage | broader | narrower to start |
Neither replaces the other. cync-lan covers more device types and more
platforms; this one is far easier to set up.
Everything below was verified against real hardware, not inferred from a
decompiled app. Where something is unconfirmed it says so, because this project
inherits a strict rule from cync-lan: a plausible-looking wrong opcode is the
worst failure mode available, since it fails silently.
| over Bluetooth | |
|---|---|
| session handshake, mutual auth | confirmed |
| mesh relay — one connection reaches every device | confirmed |
| on / off | confirmed |
| brightness | confirmed |
| colour temperature | not confirmed |
| RGB colour | not confirmed |
| inbound status updates | received and decrypted — but at the cost of the connection |
| the exact meaning of those updates | partially decoded, one capture only |
That second-to-last row is the real limitation, and it is a Linux Bluetooth stack
problem rather than a device one. BlueZ will not hand over notifications unless it
subscribes, and this firmware rejects the subscription in a way that drops the
link. On a local adapter you can send or receive, not both — so the manifest
says local_polling.
An ESPHome Bluetooth proxy uses its own Bluetooth client rather than BlueZ and may well not have this problem, which would make pushed state available again. Nobody has tested that yet; it is the most useful thing anyone with a proxy could report.
Setup asks for your Cync account once, to retrieve the Bluetooth mesh credentials from the vendor's API. After that there is no cloud involvement — every command is local.
The mesh password grants control of every device on the mesh. Treat it as a password: it is stored in the config entry, redacted from diagnostics, and should never be pasted into an issue.
ARCHITECTURE.md records the decisions and why they were
made — the single-session model, why the library is never allowed to create its
own Bluetooth client (it is what makes proxies possible), why the domain is
cync_ble rather than cync, and the intended route to
home-assistant/core.
The protocol work behind this is a chain of earlier projects, and it would not exist without them.
- juanboro/cync2mqtt — its
acyncmodule is a working Bluetooth mesh implementation, and cross-checking against it byte-for-byte is what gave confidence in the crypto here. Apache-2.0, itself descended fromgoogle/python-dimondandpython-tikteck. - baudneo/cync-lan — the async rewrite and the origin of most of the protocol knowledge.
- iburistu/cync-lan — the original demonstration that these devices could be controlled locally at all.
MIT.