search

scrool / xled

🎄Unofficial control for Twinkly - Smart Decoration LED lights.
MIT License
203 stars 46 forks source link

Skip discovery to workaround network that doesn't propagate broadcasts #61

Open scrool opened 3 years ago

scrool commented 3 years ago

Discovery is currently implemented as a broadcast. On some networks broadcasts are not propagated. That effectively means Twinkly devices cannot be found. Unicast connections work just fine (e.g. because they are forwarded across networks).

Twinkly app falls back to unicast for each address on the network. It does this only once - when new device is added to the app and then stores information about the device and addresses it directly.

Doing unicast discovery by CLI would be too expensive.

I'd like to mitigate this by ability to skip discovery - probably implicitly when --hostname is specified.

Skip of discovery might require #59.

Emerica commented 2 years ago

Just ran into #69 after installing Hamachi, discovery could not get a beacon back. Disabling the adaptor(s) for the moment worked.

mo8Zomo0 commented 2 years ago

hmm, I was just trying out xled, but my setup is a layer3 network, the IoT wifi stuff is in a separate layer 3 network with its own SSID.

i tried to use --hostname of twinky device, but I do not see any traffic to that IP, only a broadcast to 255.255.255.255:5555

01:09:06.887374 IP xledhost.5555 > 255.255.255.255.5555: UDP, length 9

/usr/local/bin/xled --version xled, version 0.7.0

Is this somehow supposed to work?