I own a Yeelight color bulb and for the price it is pretty good.
However for future versions I’d like to suggest two things:
Use 2700K LEDs for white. Cold white is not pretty for living rooms.
Offer a higher brightness (e.g. 15 W). Although it might not affect everyone, I think the bulb is rather dark to be used as only light source in a room
I am not a fan of it. It might be an interesting idea, but probably conflicts with lighting quality, price and speaker quality. Also the position of the speaker would not be ideal.
yep it’s not for everyone. so this has to be a new and separate SKU and not become the only product line in future, if yeelight wants to/is considering it.
another example: http://www.lumisound.com/
What I would like to see in 2nd generation is more support for the developers.
Yeelight needs to start using actual SSDP and not this custom version. It says in the documentation:
Different from SSDP protocol, we choose to send multicast messages to port 1982 instead of standard SSDP port 1900. This is to avoid excessive multicast messages being received by both smart LED and 3rd party devices. It’s especially important if the 3rd party device is power consumption sensitive (e.g. smart watch powered by battery).
But SSDP already has protections in it to prevent overload from the UDP packets. And abandoning the device description document format and using a custom protocol to retrieve it, breaks the standard significantly. There are countless SSDP libraries out there, designed to help developers not re-invent the wheel every time. But because of the custom protocol Yeelight uses everyone needs to make his own implementation.
The power of Yeelight is that they are basically IoT devices. So if Yeelight builds a big developer community around their products, the better for everyone.
Before we decide to develop the open API, we did some research. The result is: a full SSDP protocol implementation is too heavy for a embedded system, e.g. a WiFi bulb. The resource on a SoC is too constraint, the free RAM is normally around 6~8K in some low-end product. If too much SSDP packages are being received, it will impact the normal lighting control logic.
Suppose we follow the standard SSDP in discovery part, then what about next step? How should we expose our control interface? Normally or per some standard method XML/SOAP or Restful API will be needed to control the device, but all of them are too heavy for us. You may wonder why Hue or Lifx or Wemo can handle this, because they use a much stronger processor with much more resources.
Imagine we can implement Restful API or SOAP in our device, what about next step? Developer still need to check our spec and implement the API defined by us, pass each parameter carefully, which is way different than Hue/Lifx.
So current situation is: there is not a single standard in IOT world that everyone follows, that means developer has to build different handlers to handle devices from different vendors. We hope there will be some standard some day finally, but it will be a long way to go.
Hopefully you can understand my point. Currently, the IOT world is fragmented, we don’t know which standard to follow, so we invented the standard that is most suitable for us.
I see. I was not aware of the hardware limitations leading to the API decisions.
Supporting a well known standard would definitely be the optimal scenario.
Hopefully we 'll see Yeelight and other IoT makers move to that direction.