Weird issues after > 6 devices

[baudneo]

This is just here for any other users.

I started with 3 BT bulbs and 1x wifi/bt plug. I now have added another 2x plugs and 4x wifi/bt 'direct connect full color' bulbs, so 10 cync devices in total.

I am now having some weird issues:

• When status_update is run and [0x01] is written to the notification char to request notifications from devices, not all devices reply, it seems to be a hardcap of 6 devices. It takes 2 calls to get all 10 devices to report back.
• It seems that these devices can only have 5-6 devices connected to them?
  • If I have 6/10 devices on (3x BT bulb and 3x plug), only 5 will report back via BT. The last device (a plug) is on and in range but wont report its status until 1 of the powered off devices comes back online and the last plug joins the BT mesh through the newly powered on device (seems paired).

Just some observations:

• Connecting to devices is weird. The plugs require bluepy, bt only bulbs work with bleak or bluepy.

• It seems like my adapter gets paired to 1 plug. I cant connect to any other plug but I can connect to other bulbs. If i spend some time, I can connect to another plug but then it is paired to that plug and wont connect to other plugs. This means no failover to other plugs.

• When pulling config from the cloud, I have several mesh networks with no devices and access code: 777 - No idea why or what for Example:

  meshconfig:
  354384346:
  access_key: 777
  mac: 786DEBDEF01F
  name: 786DEBDEF01F
  354387276:
  access_key: 777
  mac: 786DEBDE978B
  name: 786DEBDE978B

I have done a deep dive on the code and tried all sorts of stuff, nothing is changing for the better.

Potentia/Completedl fixes:

• I added basic logic to update_status() to write to the notification char times based on how many devices in config, not elegant.
• The device max connection is out of my control, just thought mesh connections would be more robust.
• The device not pairing to another plug instead of a bulb issue may have a fix.
  • Delete all devices (or just 1 of the problem devices)
  • Add the mains powered devices first
  • Add bulbs and other devices that will lose power last, one by one.
  • After adding a new bulb and testing, turn it off so only the mains powered devices will be hubs when another device is added.

[juanboro]

For the device max connection - with bluepy at least - it may be difficult to reliably connect to more than one at once. The way I wrote it for both - it pretty much assumes just one connection into the mesh. This should work.

The yaml file/config does let setting the priority of devices or excluding devices to try to attempt to connect to. Keep the ones that are not close to the bt dongle from attempting to connect to.

It should not be having troubles with more than 6 devices in the mesh (I recall previously a few other people have said they have >20 --- I myself have only approx 5 max at anytime). But... a problem can be it does take all the devices in the mesh awhile sometimes to get their status response back (multiple hops across the mesh). I'm wondering that with the way i have the notifications handled with bluepy (which is kind of hacky) - if it's dropping the subsequent updates that are slowly coming in.

I added basic logic to update_status() to write to the notification char times based on how many devices in config, not elegant. This may be be a good solution if needed in the bluepy case. That might be the best workaround. If you can send me that as a PR, I'll merge it in. My recollection was that I made the periodic task to refresh the status always try multiple times to get the status of the devices that were known to be online to get an update --I'll have to refresh my memory of how that works.

Connecting to devices is weird. The plugs require bluepy, bt only bulbs work with bleak or bluepy. I think that's kind of expected. The plugs you have are the newer telink chips with the advertisement issue that bluez doesn't like. I know it's hacky --- but if you can have a bulb always on near the bt dongle and connect with bluepy always to that bulb --- it probably will be the most stable.

[baudneo]

Hey thanks for the insights. I have completely deep dove the code and on status update, it sets all devices offline and sends a notification char to gatt_write one time. The default wait time for status updates is 10 min. I changed this to 1 min while testing, to get "zombie" devices to be reported "offline" or "unavailable" than staying in zombie state of showing last recorded status.

I have put in logging that follows the data as it crawls down the callbacks but haven't found good docs on telink mesh packet structs. I have a few pdfs from their site but I haven't found structs and meaning yet.

Your hypothesis for the plugs needing bluepy might be right. I got 4x direct connect wifi/by bulbs and they are all the older MAC and can be connected to via bleak/bluepy.

Now, with all that said, I haven't given up yet but I have also been working on a cyncLan port to python. I have the cync lan server working and talking to devices/phone app. The plan is to add mqtt after I get device status and device control packet structs figured out. Then possibly add bt support (not sure on bt support yet) but it would be interesting to see if they built their web app kind of like temesh. The http messages seem to read and write to a "queue Id" (service), which also has a msg id/chain Id (characteristic).

I have device status pretty well figured and am moving onto device control soon. There are some quirks when the phone app connects and it gets chatty. I may be deep diving to hard and try to understand everything rather than brute forcing status and control.

Any help on that front would be great. I'm pretty close to having local only http control. You can also control bt only bulbs via http calls. The devices seem to bridge commands from wifi to bt and you can control via device id.

Thanks for your work, I wouldn't have stayed on cync devices at all if it weren't for your repo.

https://github.com/baudneo/cync-lan/tree/python

Edit: Only dep rn should be uvloop. its all contained in 1 file src/cync-lan.py for now, I will build a lib for it after I get it working. To install, you can create a venv, activate it and install uvloop into it. run the create_certs.sh to create the self-signed certs. Then DNS redirect; older devices need cm-ge.xlink.cn redirected while newer devices need cm.gelighting.com.

You can use unbound and 'views' to selectively DNS redirect for certain LAN hosts instead of DNS redirecting network wide.

Example unbound config that redirects domain cm.gelighting.com to 10.0.1.9 for device 10.0.1.167. In OPNsense this data is put in Services>Unbound DNS>Custom Options.

server:
access-control-view: 10.0.1.167/32 cync-override

view:
name: "cync-override"
local-zone: "homelab" static
local-data: "cm.gelighting.com. 90 IN A 10.0.1.9"

Note: You cant run socat and cynclan at the same time on same host as they bind to port 23779. socat is used to MITM traffic between devices/phone app and the cloud server. See the README for socat command.

[baudneo]

I've got a beta test ready if you're interested. Just follow the README.