Suggestions for future bulb versions


#1

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:

  1. Use 2700K LEDs for white. Cold white is not pretty for living rooms.
  2. 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

#2

We are developing the 2nd generation product, the spec is exactly as you wanted.


Yeelight RGB Bulb V2
#3

Wow, great! Any ETA? And I hope it will not cost much more than the current bulbs.


#4

July this year. I’m not clear about the market and pricing strategy.


#5

Alright, thanks!


#6

i would like to add:
integrate music/radio into the bulbs with wifi.
there are many already in the market.


#7

For Color bulb and Strip, it’s already there, please use Yeelight app and goto settings.


#8

what other new feature the rgbw bulb will include compared to the actual?


#9

no i dont mean the music mode. for example like this https://www.amazon.com/Tenergy-Propel-Music-Bluetooth-Speaker/dp/B00GU1OCXO

better ones have wifi (besides bluetooth) and can link up with spotify account, soundcloud, etc and the bulbs have built-in speakers.


#10

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.


#11

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/


#12

possible to make smaller yeelight bulb? say, half the size of current bulb. still using E27, smaller yeelight bulbs to fit into smaller shade/casing.


#13

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.


#14

Thanks for your comments and feedbacks!

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.


#15

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.

Thanks for taking the time to answer!


#16

Thanks for your understanding and support!


#17

Is there any news on the new bulb?


#18

No comments. :smiley:


#19

Since July is over now, any updates you can share?


#20

I’ve seen around on some online shop a supposed Yeelight Color Bulb II, which seems to be 9w (instead of 8w I guess). Is that something?