ESP01_SHTW1C_31 color temperature range defined incorrectly

wingedseed commented 3 years ago

I recently purchased two Wiz tunable white recessed lights for testing. The custom component works great, but when I was doing some color temperature automation flows in Node-Red, I noticed that the color temperature in mireds tops at 370 and can not go higher.

I ran the UDP request and found out that the model number of my lights is ESP01_SHTW1C_31 (I bought these lights in Taiwan, the short model number used locally online is "PW003", the full product description on the box is: "WiFi TW/17W RD6" D150/827-65 WV 12/1CT 9290025607"), and on the web site it says the color temperature range is 2700K-6500K.

I then checked the "bulblibrary.yaml" file, the min kelvin value was set to 2200K instead of 2700K. I changed it to the correct value and reload the HA core, now the color temperature range in mireds goes from 153~370 and everything works as expected.

Not sure if this color temperature range is unique to the Taiwanese model or was incorrectly defined, just wanna report this finding, and hope this can be updated in the future release.

Great component BTW, thanks for the wonderful work.

ChrisLizon commented 3 years ago

I am curious if @vodovozovge would be able to chime in on this one. I think he hinted over in the pywizlight issue tracker that there may be more to the model number mappings than first expected. From what I've seen in the bulb report submissions it seems that the same identifier can be used across multiple products. Perhaps there is a way that we can poll the bulbs instead of relying on a database.

I believe @bleeisme also has a bulb with the same identifier (from issue #31), perhaps they can verify if the advertised color range on their bulb is in fact 2200K-6500K as is recorded in bulbconfig.yaml.

vodovozovge commented 3 years ago

👋 @ChrisLizon you're right, the string "ESP01_SHTW1C_31" is not enough to figure out all the capabilities of the device ESP01_SHTW1C_31 just defines the basic hardware settings for the bulb. There is some logic in it: ESP01 -- defines the module family, WiFi only bulb this case SH -- Single Head light TW -- Tunable White, as in can only control CCT and dimming, no color 1C -- Specific to the hardware -- defines PWM frequency + way of controlling CCT temperature 31 -- Related to the hardware revision

As you can see, there is nothing about CCT range supported by the device and indeed we have models with different CCT ranges with the same config string.

To get the actual range you need to send getUserConfig command to the bulb. For example here is the response received from one of the bulbs I have at home

{
  "method": "getUserConfig",
  "env": "pro",
  "result": {
    "fadeIn": 1000,
    "fadeOut": 500,
    "fadeNight": false,
    "dftDim": 100,
    "pwmRange": [
      0,
      100
    ],
    "whiteRange": [
      2700,
      6500
    ],
    "extRange": [
      2200,
      6500
    ],
    "po": false
  }
}

As you can see there are 2 ranges -- whiteRange and extRange. White range defines what temperature the light can achieve using purely warm and cool LEDs. Extended range is done by adding red / blue color to the white LEDs to extend the available CCT range. Obviously it's available only on Color bulbs, that's why they can go to 2200K.

wingedseed has Tunable White bulb, so no way to get the range extended -> min is 2700K

ChrisLizon commented 3 years ago

Oh very fascinating! I had noticed that when my bulbs are set to 2500K, turned off, and then turned back on, that they glow red for a very short time before becoming a warm white color. I guess since 2500K falls in side the "extRange" this behavior is likely the driver for the red LEDs coming on before the warm white LEDS. Now to change my node-red flow to bring the bulb on at 2700 and then lower it down to 2500... hmmm

{"method":"getUserConfig","env":"pro","result":{"fadeIn":3000,"fadeOut":5000,"fadeNight":false,"dftDim":100,"pwmRange":[0,100],"whiteRange":[2699,6500],"extRange":[2200,6500],"po":false}}

vodovozovge commented 3 years ago

I had noticed that when my bulbs are set to 2500K, turned off, and then turned back on, that they glow red for a very short time before becoming a warm white color. I guess since 2500K falls in side the "extRange" this behavior is likely the driver for the red LEDs coming on before the warm white LEDS

yep, red LEDs (actually any color LEDs) are turned on first. And there is a reason for that -- apparently to meet power regulations there is some circuit on each type of the LEDs. Essentially some kind of capacitor (I'm not a hardware guy, so could be terribly wrong here). And to start emitting the light we need to charge the capacitor first. The capacitor is smaller on the color LEDs than on the white ones (white ones are way more powerful) and charges faster. As soon as it is charged -> LED turns on. That's what you observe -- color LED turns on a bit earlier

sbidy commented 3 years ago

I'm currently investigating the color temp. managamnet in HASS. For mapping this temperature better in the next versions I'll implement the getuserconfig to map the Kelvin range dynamically.

sbidy commented 3 years ago

@vodovozovge I currently implementing the "auto" mapping. I assume the following:

If the TW was in the name: Tunable White - the extended white range is not supported - is not an RGB bulb - only some effects will work.
if the RGB was in the name: All features are supported - the extended white range will used (2200k to 6500k)
if the DW was in the name: Only brightness will supported and the normal kelvin range (2700k - 6500k) but this will never used because of missing color.

Is this assumption "correct" 😉

Important is the fact that TW will only supports 2700 to 6500k and only the RGB will support the full range from 2200k to 6500k. DW is a "normal" bulb without CCT, effects and color.

I've done a implementation based on this assumption: https://github.com/sbidy/pywizlight/blob/9eddd7db7bd6c6a07b34bda8c0c0dbfee0920851/pywizlight/bulb.py#L281

And one other point: Effects 🚥 ... what effects/scenes are supported by TW bulbs? I don't get this in your GitLab repo 😉

vodovozovge commented 3 years ago

@sbidy

if the DW was in the name: Only brightness will supported and the normal kelvin range (2700k - 6500k) but this will never used because of missing color.

DW - Dimmable white, doesn't support CCT, only dimming + some effects(we name them "light modes"), there is a link in the end of the reply Some DW filaments have 1800K CCT value

important is the fact that TW will only supports 2700 to 6500

unfortunately it's a bit trickier. this one is true for the majority of models (by volume), especially for the light bulbs.

But the rule breaks for filaments: for example this one https://www.homedepot.com/p/Philips-Soft-White-ST19-LED-40W-Equivalent-Dimmable-Smart-Wi-Fi-Wiz-Connected-Wireless-Light-Bulb-555557/310289025 goes from 2200K to 5000K

RGB usually supports full range, but for some models partners decide to go with the reduced range, like 3000K to 5000K

And one other point: Effects 🚥 ... what effects/scenes are supported by TW bulbs? I don't get this in your GitLab repo 😉

yeah, udp lib doesn't check the type of the bulbs. I did some writeup for our pro api here https://docs.pro.wizconnected.com/#light-modes , it lists available light modes according to the product type

sbidy commented 3 years ago

@vodovozovge

My decision tree is the following:

All bulbs can be dimmed - this will be true for all
Get the whiteRange from the getUserConfig to define the max and min kelvin value (also for the DW lights)
Check if the type contains "RGB" if yes - goto 3.1 // if not - goto 4. 3.1. RGB bulb has all features - light modes, CCT and color. The CCT values will be read from the extRange property.
The bulb is a non-RGB and should be a "TW" - CCT and (some) effects are supported but no color. Use the whiteRange values,

In short: DW = whiteRange TW = whiteRange RGB = extRange

If TW and filament (like the Philips) will return in the whiteRange 22000 and 5000? Or this values are also in extRange? I'm little bit confused when what value will used 😉

I don't have one of these because here in Germany it is really tricky and expensive to get these type of bulb 😞 (we don't have a homedeopt ... unfortunately)

XRyu commented 3 years ago

Hey Stephan, we can get the Filament-ones here in Obi i think (i got my E14-Filaments there): arent these? https://www.obi.de/weitere-smarte-leuchtmittel/wiz-smart-led-leuchtmittel-wifi-filament-amber-c35-e14-5-5-w-eek-a-/p/7884851

Am Di., 9. Feb. 2021 um 19:43 Uhr schrieb Stephan Traub < notifications@github.com>:

@vodovozovge https://github.com/vodovozovge

My decision tree is the following:

All bulbs can be dimmed - this will be true for all

Get the whiteRange from the getUserConfig to define the max and min kelvin value (also for the DW lights)

Check if the type contains "RGB" if yes - goto 3.1 // if not - goto

3.1. RGB bulb has all features - light modes, CCT and color. The CCT values will be read from the extRange property.

The bulb is a non-RGB and should be a "TW" - CCT and (some) effects are supported but no color. Use the whiteRange values,

In short: DW = whiteRange TW = whiteRange RGB = extRange

If TW and filament (like the Philips) will return in the whiteRange 22000 and 5000? Or this values are also in extRange? I'm little bit confused when what value will used 😉

I don't have one of these because here in Germany it is really tricky and expensive to get these type of bulb 😞 (we don't have a homedeopt ... unfortunately)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/sbidy/wiz_light/issues/96#issuecomment-776155241, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABAHG4CX3VTKPIIUM7QRV3S6F64DANCNFSM4W3OZ44A .

vodovozovge commented 3 years ago

@sbidy

In short: DW = whiteRange TW = whiteRange RGB = extRange

you can just use extRange everywhere, extRange = whiteRange for DW and TW and extRange >= whiteRange for RGB

for example for the TW (happened to be filament :D) {"method":"getUserConfig","env":"pro","result":{"fadeIn":500,"fadeOut":500,"fadeNight":false,"dftDim":100,"pwmRange":[5,100],"whiteRange":[2000,5500],"extRange":[2000,5500],"po":false}}

for the DW (filament again) {"method":"getUserConfig","env":"pro","result":{"fadeIn":500,"fadeOut":500,"fadeNight":false,"dftDim":100,"pwmRange":[5,100],"whiteRange":[2500,2500],"extRange":[2500,2500],"po":false}}

for the RGB (BR30, Philips-WiZ) {"method":"getUserConfig","env":"pro","result":{"fadeIn":450,"fadeOut":500,"fadeNight":false,"dftDim":100,"pwmRange":[0,100],"whiteRange":[2699,6500],"extRange":[2200,6500],"po":false}}

sbidy commented 3 years ago

@sbidy

In short: DW = whiteRange TW = whiteRange RGB = extRange

you can just use extRange everywhere, extRange = whiteRange for DW and TW and extRange >= whiteRange for RGB

for example for the TW (happened to be filament :D) {"method":"getUserConfig","env":"pro","result":{"fadeIn":500,"fadeOut":500,"fadeNight":false,"dftDim":100,"pwmRange":[5,100],"whiteRange":[2000,5500],"extRange":[2000,5500],"po":false}}

for the DW (filament again) {"method":"getUserConfig","env":"pro","result":{"fadeIn":500,"fadeOut":500,"fadeNight":false,"dftDim":100,"pwmRange":[5,100],"whiteRange":[2500,2500],"extRange":[2500,2500],"po":false}}

for the RGB (BR30, Philips-WiZ) {"method":"getUserConfig","env":"pro","result":{"fadeIn":450,"fadeOut":500,"fadeNight":false,"dftDim":100,"pwmRange":[0,100],"whiteRange":[2699,6500],"extRange":[2200,6500],"po":false}}

That's great! This makes it so much easier 😉 . Thank you 💙

sbidy commented 3 years ago

Should be fixed in the 0.4. - the bulbs and kelvin ranges will be now auto detected.

wingedseed commented 3 years ago

Just tested 0.4 and it seems to be able to detect the correct range. Thanks!

sbidy commented 3 years ago

I'll close the issue. Please create a new one if other issues coming up.

sbidy / wiz_light

ESP01_SHTW1C_31 color temperature range defined incorrectly #96