The YeeLight Inter-Operation Specification document states:
After the initial announcement, Yeelight smart LED will refresh its state by sending the advertisement message at a fixed interval.
Trying three YeeLight products on two different Wi-Fi networks, these fixed interface SSDP-like messages do not appear to be broadcast. The devices are running the up-to-date firmware as of this writing (1.4.2_0049).
A previous forum post from February (Advertisement feature) noted the absence of notification packets as well. The response to that post suggests using TCP notifications. While TCP notifications do work, they require maintaining an open TCP connection to each bulb. For lightweight client devices, this is not possible for a home using many YeeLight products (there can be a limit on the number of sockets, such as the 4 that the YeeLight products have). The SSDP-like notifications described in the Inter-Operation Specification is a more scalable and efficient way to deliver changes.
Is this feature supported? If not, could it be re-enabled? If no, can the documentation be updated to prevent other developers from being confused?
Thank you for your reply. I see that I am not patient enough.
I understand now that the only purpose of this advertising is a keep-alive message for the bulb. I was perhaps overly optimistic to expect that it could be used to monitor for changes in the bulb state.
That would appear mean that there are two ways to determine when a bulb changes state, (1) maintain an active TCP connection to each bulb to receive notification messages or (2) poll the bulbs by periodically sending a discovery message. If this is incorrect, please let me know.
Currently we expect the client to use TCP_KEEPALIVE socket option to do the heart beat.
If the connection is shutdown gracefully (for example, user turn off LAN control), then the client will receive a return value of 0 on read() call.
If the connection is shutdown abruptly (for example, power cut), then the client will receive a return value of 0 on read() after the defined TCP keep-alive timer fired. Note: Client needs explicitly enable tcp keepalive mechanism after the socket is created.
In conclusion, client doesn’t need to use a poll or periodic discovery to achieve the liveness check of the device.
The original post above notes that “TCP notifications do work” and that “they require maintaining an open TCP connection to each bulb.” It explains that keeping an open TCP connection to each bulb is not feasible for “[for] lightweight client devices” as the maximum number of sockets available is limited. For example, a typical microcontroller is limited to 4 or 8 simultaneous sockets. A home may have several dozen light bulbs.
Because of this, a notification mechanism which does not require an always-connected TCP socket for each bulb is desirable.
