ColorTemperature on TUYA lamps

Devices & Integrations
1

Greetings all!

In my quest for nice adaptive circadian lighting, I have noticed that color temperature on my Tuya ceiling lamps always looks off.

Turns out it actually is, confirmed by the vendor (Ledvance/OSRAM), because of the way Tuya implemented this. From what I found so far, again confirmed by vendor:

The Tuya cloud API represents white color temperature as a value between 0 and 1000, where - and here’s the problem - this range is relative to this particular lamp’s supported range.

So if you have a ceiling lamp with a range of 3000K to 6500K, then an API value of 0 produces 3000K and 1000 produces 6500K.
If you have one of the nice “Sun@Home” lamps with a range of 2200K to 6500K, then a ColorTemperature value of 0 produces 2200K and 1000 produces 6500K.

Now the way SmartThings uses the API makes this worse than it already is. ST values for ColorTemperature are 0 to 10000, in absolute K. Now on a Tuya lamp, this value goes straight into the Tuya API with no translation (just divide by 10 for scale). Set to 3000K and the Tuya lamp will receive “ColorTemperature 300”, which sets it to the 30% value in its own specific range.

In my above examples, when trying to set to 3000, the ceiling lamp will actually set to 30 percent in (6500-3000) which is 4050K. The Sun lamp will set to 30 percent in (6500-2200) which is 3490. The actual range of either lamp remains unreachable; trying to set to 6500 will produce 65% which actually turns out to 5275K and 4995K respectively, setting to 3000 or 2200 respectively will end up producing 4050K and 3146K.

Frustration!

I realize Tuya lamps do not run on a loadable driver; also the lamps do not export their particular range at all.

Can we invent something to fix this? Like, could each such lamp have user settings for min/max color temperature, and have ST linear-map this to Tuya 0-1000 range?

Y’alls thoughts please.

best regards,
Peter

2

Since it’s a cloud integration, the issue seems to be the way Tuya is using SmartThings API, not the other way. All that internal mapping is responsibility of Tuya in their servers.

Does not surprise me though, Tuya has a habit of using attributes in strange ways leading to integration issues, we’ve seen it in Zigbee and Matter too.

3

Not sure we can word it like that. The disconnect is quite straightforward.

Tuya API documentation specifically says 0-1000 is relative to the range of the lamp.

ST calls this API with the expectation that 0-1000 is absolutes in 10K steps.

4

SmartThings does not call Tuya API, do they?

If it’s a cloud integration, it’s Tuya integrating with SmartThings API and SmartThings Schema. What Tuya does when SmartThings sends them a “temperature 4000 K” is up to Tuya.

5

… and that’s the thing. There is no “temperature to 4000K” call, just a “temperature to X% in lamp’s range” call.

6

Being a cloud integration, SmartThings sends Tuya a JSON with the SmartThings capability name, command and arguments. By specification, the argument to set temperature is in Kelvin, there is no other interpretation.

If Tuya servers receive a 4000 from SmartThings servers they have to make the light 4000 K, if they do not it’s because they have a bug in their servers and they have to fix their internal profile for that specific model so it is mapped correctly.

7

Ah, I get it now. So Tuya is hooking into ST APIs not the other way around.

I’ll take my findings back to Ledvance then, their latest feedback implies they are at least close to the root cause.

Namely, it seems that lamp manufacturers can optionally add an absolutes-to-relatives mapping to their device, according to this page:

So now we know where this should be solved … yet still, is it thinkable to have a workaround implemented on the ST side?

8

No, that’s probably something trivial for the vendor to fix and as soon as they do it will apply automatically.

I mean, you can create a virtual light with some routines so you control the virtual light with correct values and then the routine changes the temperature of the actual light with the “wrong” values. But that’s just a hack while they fix it and given you want it for adaptive lighting it’s not practical at all.