Sengled Color Temp Setting

💡 Lighting
1

I bought one of these bulbs on sale on Black Friday, but only just got around to messing with it.

Sengled Zigbee Smart Bulb

When I set the color temperature using the command on the device page (or the custom command action in rule machine) the actual setting value comes through in the current state values higher than the setting.

The offset differs depending on the setting. For 2700 it stops at 2703...for 2750 it's 2755. Does anyone know why this is happening, and how to prevent it?

2

Mine do the same thing. Honestly, if you can tell the difference +/- 5 degrees K, your eyes are better than mine. I've just learned to ignore the discrepancy.

3

@bertabcd1234 had explained many CT mysteries in the past... Maybe he has info to share in this case as well. :slightly_smiling_face::+1:

4

I get the same thing. I just set the value I want and ignore the discrepancy. It is annoying on an emotional level but works on a realistic level. :man_shrugging:t3:

5

Adding more context...the reason I ask isn't due to the visual, but an automation. I'm working on one to store/restore the setting from a variable. It's on a "semi-dumb" switch/timer that cuts power at a specific time. If I change things up with the setting while it's on, I want it to restore to the new setting the next time the switch turns on (eventually I'll replace the switch).

If I set 2700, but it goes to 2703, then it captures 2703 for the next cycle. Then 2703 becomes 2710...and so on. Without a way to stop that, it will run away and keep getting higher every day.

2 Likes
6

That is trickier...i don't have a "solution" but i might have a workaround. Create a local variable with number (not decimal) as the type. Capture your color temp to that variable, then use variable math to divide by 100 then multiply by 100. That should "truncate" any minor discrepancy in the actual CT.

1 Like
7

I think this is usually the result of rounding errors, mostly due to the fact that most (all standard?) Zigbee bulbs use mireds, not Kelvin directly, for this. These units are also called "reciprocal megakelvins" because the conversions look like this:

  • 1000000/4000 = 250
  • 1000000/2700 = 370.370...

So, with something like the latter, you're likely to get 2700 K rounding to 370 mireds, so 370 is the "real" value. Then, conversion back to Kelvin gets you 1000000/370 = 2702.702... ≈ 2703.

Using 2703 from the get-go might avoid this problem, but depending on how the driver and the device deal with rounding (or perhaps some devices do less than whole-number precision on mireds; not sure on that), you may eventually find values slightly different from what you send due to the above.

5 Likes
8

See, I knew that you knew more than me. :wink: Thanks!! :slight_smile:

1 Like
9

You made those words up.

4 Likes
10

I've seen similar behavior. I'd not heard about mireds, but I'd figured the bulb just had certain granularity of values it could produce. It receives a command for 2700, goes to the closest supported value (2703), and sends back a status update with the new actual setting.

I haven't seen the ramping up, personally, because I don't try to take the value from one and send it back to it. What I have is:

  • A virtual CT bulb, which can take whatever value I tell it to
  • A rule which copies that value into a variable whenever it changes

Then everything else either points to the virtual device or the variable.

11

This looks to be exactly what is happening. 2700 does become 2703, which becomes 2710, which stays 2710 because it's nearly exactly 369.00 mireds or whatever. So any CT that cleanly converts to mireds and back should work. And any other value may "migrate" a few degrees until the next higher stable value is reached.

I would try your automation as-is and see if it really does run away as you suspect. I think you'll find it may work just fine.

1 Like
12

This is why I never regret selecting Hubitat as my smart hub. The people on this forum always seem to know an answer/how to find a way to make things work.

This is interesting - something like hertz (Hz). Like a frequency of the light, which in a geeky physics way makes sense about light.

This seems like it can work to negate the mireds conversion.

This also seems like it can work (perhaps combined with the last), and I think this may make a lot of sense as I plan to expand to multiple bulbs. I can use the single virtual bulb to manage the setting of all of them - instead of trying to manage the mireds conversion on each separate bulb (:upside_down_face: I imagine that could get messy if they got out of sync with each other).

:rofl:

Thanks all!

2 Likes
13

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.