Added some more stuff:
-
Max TCP connections: throttle how many wifi cync devices can connect at one time. Useful if you have a large amount of devices. Helps with tuning to get command latency down.
-
IP whitelist: Some devices are better at being TCP ↔ BTLE bridges (the Direct Connect LED light strip controller seems to be the best, with other lights being 2nd best, wired switches not tested yet). So, you can set a whitelist to only allow a certain device to connect.
-
Adjustable TCP command re-broadcasting: When a state change command is issued, the default is to send it to 2 TCP devices. This is useful to tune command latency and device synchronization (when issuing a group command, all lights change close to each other)
The way the WiFi Cync devices work are:
- Device connects to CyncLAN server, handshake and ID exchange
- TCP socket stays open with keep-alive data
- Cync device sends status updates and other data to CyncLAN server
- CyncLAN server sends commands to the device, the device converts the TCP command to a BTLE command and broadcasts it over the BTLE mesh
- BTLE mesh broadcasts means every device ‘node’ in-range of the BTLE mesh will receive the message.
- The device receives every message, even if its not for them and re-broadcasts it. If the message is for them, the device doesn’t re-broadcast, it parses the msg. This could be an individual device ID or a group ID. Which is why BTLE broadcast commands are so fast and usually all devices are in-sync. It’s built in at the protocol level.
There seems to be some latency when the TCP device is converting from TCP to BTLE. Not sure if maybe it needs to connect to another device or something because it should be faster than it is. I’ve been reverse engineering the TCP side of things and dont see any way to make this faster, yet. More testing is being done to see how the Cync App utilizes TCP only and if it has fast, in-sync state change commands over TCP.
Tips
Tuning state change command latency and command syncing
If you only have 1-3 WiFi/BT Cync devices and a LARGE amount of BT only lights, using CyncLAN will probably have some latency and when issuing group commands (HASS light group turned off) you may notice that the lights change state one by one, not in parallel.
What I do is I have 5/45 WiFi devices connected to CyncLAN, and have the TCP state change command re-broadcast set to 3. In a 9 device HASS light group, it takes 2–4 seconds for the all lights to change state and the lights are more in-sync but definitely not perfect. With 2-3 WiFi devices connected and 2-3 command re-broadcasts, the same command takes 3–8 seconds and each light changes one after the other.
No matter what, at this moment CyncLAN does not have instant, in-sync state changes using TCP commands.
Too many devices
Another issue is when too many WiFI devices are connected to CyncLAN. Each TCP device connected to CyncLAN reports each BT devices state. Some devices do things differently than others, but there can be a massive amount of duplicated status packets. ATM, CyncLAN just blindly grabs the status and sends that update over MQTT, this will be improved in the future, but for now, it kind of sucks.
So, if 1 device gets turned off and you have 50 WiFI devices connected, that could be 50-100+ state change messages parsed and then MQTT publishes sent for 1 command to 1 device. Now, if you issue a group command to 10 devices, maybe it’s 500-1000+ parses and MQTT publishes!
That’s what the env var CYNC_MAX_TCP_CONN is for (default: 8).
new env vars
| Variable |
Description |
Default |
CYNC_CMD_BROADCASTS |
Number of WiFi devices to send state commands to |
2 |
CYNC_MAX_TCP_CONN |
Maximum Wifi devices allowed to connect at a time |
8 |
CYNC_TCP_WHITELIST |
Comma separated string of allowed IPs |
Allow ALL IPs |
