Set color temperature not working as expected

🛎️ Get Help Integrations
1

Here's an interesting issue. A bit of back story: I had a radio go out on my C-4 hub so I picked up a C-7 hub and am in the process of migrating many devices and applications to the new hub. My Zigbee lights are on a c-5 hub and connected via Hub Mesh. I'm taking the opportunity to redesign some of my flows.

For one of these I am setting a common color temperature and light level for some general lighting depending on the current mode. I have three hub variables setup to track this (color, level, duration). So far I like it but when the motion rules execute they often do not work. The lights will turn off but rarely will they turn on. I spent quite a bit of time removing and adding lights, adding repeaters to the mesh, testing lights manually, etc.

It turns out that they don't like to have both the temperature and level adjusted in the same command. I was setting up rules like this:

image
image1050Ă—242 13 KB

Things started working as expected when I separated the command:

image
image759Ă—263 14.6 KB

Independent color and level commands works every time.

I don't know if this is related to the command, the Hub Mesh, Rule Machine, or something else. I don't mind it being two commands. I wanted to report what I'm seeing as it definitely isn't working as expected.

2

I had a similar experience with some outdoor ZigBee lights - blamed it on mesh/range, but they would not reliably turn on AND change color at the same time. If I turn them all on, then change color, all is well and works every time.

3

I have color temperature change when the mode changes, with color prestaging enabled. Then I just send level commands to the lights to turn on. I don’t think this works with Zigbee 3.0 bulbs, if that’s what you’re using.
Although, I do have a couple button controller rules set up with ct and level being sent together, but mostly just to groups using Zigbee group messaging. This has worked well in my case.

4

What devices are these, and what driver are they using? If it's a community driver, my guess is that it needs to be updated to match the new-ish spec for the setColorTemperature() command that changed in firmware 2.2.6.

1 Like
5

It’s a mix of Sengled and Sylvania bulbs. They are all using the generic driver that was assigned when they were added years ago. The hub is on the latest firmware version.

image
image1284Ă—491 110 KB

image
image1284Ă—690 94.6 KB

6

That's interesting, then. For the Sengleds, you could probably try one of the Sengled-specific drivers that have been introduced since then, but the Generic ones should still work--for both, though the new "Advanced..." drivers might also work with Sylvania. Not sure why they wouldn't be working for either as-is, though. You could try re-pairing if you haven't (don't delete the device first, at least not if you don't want to re-do all apps they are in use by).

A "Configure" can't hurt but would be a more likely fix for Zigbee devices that aren't reporting as expected. But it still can't hurt, and if you do switch drivers, you'll want to do it then as well.

1 Like
7

I’ll take a look at the newer drivers. Everything has been working so long I hadn’t followed the device specific drivers. I just let the updates do their thing. While troubleshooting I did multiple re-pairs and hit the configure button more times than I would like to admit.

Taking a look at the old rules I was using a different command. Previously, on the C-4, the rules were connecting to the lighting hub via HubConnrct. Now on the C-7 I’m using Hub Mesh. Instead of using set color temperature I was using set by mode.

image
image1284Ă—1233 201 KB

So the set by mode worked fine but I didn’t want to do all that configuration for each rule. The global setting simplified the rules considerably. I just have to do it in two steps.

8

I guess the first thing you should try, which I didn't mention above, is to rule (ha...) out an app issue. If the commands don't work directly from the device page, they won't work from any app, including Rule Machine, either. But if they do, you may have narrowed something down with the app.

Rule Machine 5.x is using the "new" setColorTemperatre() command here, the one that lets you specify more than one parameter (color temperature plus level and/or transition time, rather than just color temperature). I think even Rule 4.1 did this, but I can't remember exactly when this changed. Previously, it would have done setColorTemperature() with just the color temperature, followed by a separate setLevel(). In your case, specifying the first two parameters as something like 6500 and 40 (and leaving the third blank) would be how I'd test this on the device page with the "Set Color Temperature" command/button. That should be what RM is doing.

If that works, then something could be odd with the Rule; if it doesn't, then at least you know where the problem is...even if I'm not sure why that would be a problem.

1 Like
9

Set temperature with color and level has been there at least since RM 4.0. On a mobile device the UI doesn’t show the version. Out of curiosity I’ll take a look when I go back inside so see what those old rules are running under.

I just ran a Sylvania light thought its paces from the device page. Those are the only ones I have outside. I’ll try the Sengled later.

image

The only time it failed is when I entered a value outside of the acceptable range (1111). Even then the level change worked. I did notice that the level change would happen first and then the color change. So if there was a default fade on the device one parameter would fade then the other so it would take twice as long for the transition.

So perhaps in RM it is doing the color change first but not triggering the level change? That could be an issue with either the app or the device. It might be some sort of a race condition.

Just to be clear, I’m not too worried about it since I have a workaround. I am happy to troubleshoot the issue if it will help HE improve the product. A couple of years ago I put in quite a bit of effort to stabilize my system and that is when I added a second hub just for the Zigbee lights and some repeaters. That hub hasn’t changed in this round of updates other than switching from HubConnect to Hub Mesh.

And finally, on a possibility related note, my outdoor lights are behaving a bit janky as well. When they transition from color temperature to RGB it stutters quite a bit. In this case I’m not using RM but a custom app that is a copy and paste from what was happening on the old hub. The logic has changed but the way it sets the lights hasn’t changed.

For example, turning on white lights:

def turnOnSecurityLights() {
groupAll.setColorTemperature(6500)
groupAll.setLevel(100, 0)
groupAll.on()
switches.on()
}

Turning out a scene:

case "2":
log("••• Set scene to blue •••")
groupOdd.setColor([hue: 66, saturation: 100])
groupOdd.setLevel(50, 0)
pauseExecution(100)
groupEven.setColor([hue: 33, saturation: 100])
groupEven.setLevel(40, 0)
echoScene1.on()
break

I had errors back in the day with color temp so at a root level this probably isn’t a new issue. I can likely remove the pause but I haven’t looked into yet as I’m still porting my old system over. At least my triggers and overrides are working much better as I cleaned up the code. I wasn’t too worried about a janky transition as long as it switched. :wink:

Anyway, thanks for all the input so far.

10

Right; what I meant is that the implementation of the action changed.

So with the new command, groupAll.setColorTemperature(6500,100,0) should do the same. If not, there is an issue with the device or driver. And if you have to do this bit at all:

then I'd make sure you don't accidentally have any of the pre-staging options enabled. A setColorTemperature(), setColor(), or setLevel() should turn the bulbs on if they are off without needing an explcit on()--that should only be needed if you're prestaging. Maybe that's the issue?

11

That’s only on the exterior lights. None of the interior lights use a custom app nor an explicit on function. It may be redundant but I want to make sure the security lights come on no matter what state they are in. They have been running fine for a couple of years like that.

I’ll be revisiting those lights eventually but for now they are running even better since the port the c-7. My old code had some edge cases that were a bit funky. The rewrite has everything working beautifully. I just need to figure out the hiccup between white and RGB transitions.

I’m not too worried about that yet as it only happens when I turn on or off the party scenes. So those would be on for hours at a time and only I would see the problem.

On a positive note I got the XMCosy RGB string lights hooked up to my custom lighting code.

image
image1512Ă—2016 781 KB

I’ll let you know as I make more tests on the color temp issue.

12

I have about 14 of the Sylvania lights you posted. I’ve never seen this. I use the Generic Zigbee rgbw driver with color prestaging enabled.

1 Like
13

So I ran some more tests. As we noted before having both the color temp and level in the rule failed most of the time. Splitting it into two steps works reliably.

Using the new color temperature control on the device screen works when setting one value or both of them.

Using groupAll.setColorTemperature(6500,100,0) in my custom app works. It even behaves well when switching between RGB and color temperature modes. I'm going to update the rest of the app and see how it behaves. There are a lot of conditional changes depending on state variables.

So it would seem that this issue is related to rule machine. The lights are a mix of Sengled and Sylvania bulbs with the latest firmware. I'm running 2.2.9.146 and using RM 5.

What does your rule look like? What version RM are you using?

14

I also updated the color settings to a single command:

case "2":
	log("••• Set scene to blue •••")
	groupOdd.setColor([hue: 66, saturation: 100, level: 50])
	//groupOdd.setLevel(50, 0)
	//pauseExecution(100)
	groupEven.setColor([hue: 33, saturation: 100, level: 40])
	//groupEven.setLevel(40, 0)
	echoScene1.on()
break

I'll see how this runs over the next couple of days. It already looks to be better than it was a couple of years ago when I wrote the original version.

Too bad there isn't a fade time associated with this command. Or is there?

15

Rate for setColor()? It's not official, but most stock drivers implement a rate key you can pass in
color olor Map and have it act in the same way. As far as I know, however, it's not formalized, so your luck may vary by driver.

Regarding the new command, I think RM puts null instead of nothing for "missing" parameters (always providing three), so you might want to test your device/driver to see if it works that way. You'll have to do most of this with custom code, since the UI will only provide null for inputs if it's a "middle" parameter that you're missing (e.g., the second but you specified a third).

16

Isn’t that what you have set to 0?

I used to do this with rm4 (set color temperature per mode), but now use Adaptive Lighting through Home bridge. I still use rm4.1 to set just CT with mode changes for a few lights. I changed this so lights would come on to the correct CT whether using a button controller, Alexa, or Siri.

image
image1170Ă—2532 440 KB

17

That’s for the color temperature command. I was saying it would be nice for the RGB command too.

That’s just setting the color temperature. I had trouble when trying to set the color temperature and level in the same RM command. When I split it into two it worked fine.

I might try that sometime. It really isn’t a big deal for this implementation. I only set the color scenes once when I have company. They stay on until I turn them off. It overrides the motion activated security lightning at the same time.

I did have a couple of failures where the even group didn’t come on when I set it to the orange scene. If I triggered it a second time it was ok. I also have a time or two when it didn’t transition back to white from the blue scene. It was just the even group so I might have to put that 100ms delay back in. I’ll keep an eye on it.

18

No, it's both CT and Level

19

I only see temperature.

image
image1170Ă—2532 468 KB

20

That’s a rule I currently use. I just use a custom command to only send CT that changes by way of the global variable. I used to use the other but it was too complicated to make everything work the way I want with Alexa and Siri in the mix.