Your capture and color change to red are still happening on the same delay. Some commands take longer to execute than others. You may issue them in a 1.2.3 order but if the first command takes longer to execute than the second one they could be going in a 2.1.3 order. Having the capture and color change timed like that the color change could be registering before the capture.
Refresh the hub, capture on .5s delay, change to red on 1s delay.
If that isn't working than you have network anomalies that are causing things to execute in the wrong order. Time to turn on logging in your rule and trip things while watching the logs until you figure out why this is happening.
Then refresh is NOT your issue as when changes are made in HE the state is changed.
Perfect this proves what I have been telling you. It's not your rule and most of them delays are not needed only the one between the on and the colour change.
What brand of lamp are they and what country are you in?
BTW you can prove all of this by just using the device page. Set it to white turn off the lamp set the colour to red light will turn on but not to red. Now set it to red again and turn it off, now set a Kelvin. Light will turn on but will be red. Now set Kelvin again and it will go to correct Kelvin.
When I set the colour temp it responds and works however when i click in the colour map and then click set colour the bulb doesnt change. Heres the problem! The bulb is a hue gen 2 for info.
ah i though it was like webcore and worked down the list, this makes sense now
I was able to get a Hue bulb on a Hue hub to do everything without the delays or refresh. All of my delay/refresh/local variable -FU has been to make an OSRAM bulb work. Someone on here keeps bringing up the KISS principle. I don't know what a 70/80 heavy metal band has to do with home automation but I found that keeping things simple is best.
It does when you have delays like how you are using them ie they are under the action. There is also delay per action, these delay just THAT action and the rest continues down the list.
As you should, the only time you need a delay like this is to allow the lamp to turn on before you change the colour mode, but only on the lamps that need it. Or you have the driver handle the commands better for that type of device then you don't need it at all.
If you're only making changes from within Hubitat, they should be reflected immediately. It's my understanding that this is what you are doing. A refresh from Hue should not be necessary. Have you verified that everything on the Current States on the device page updates as expected when you manually change something from that page?
do a basic rule and show us with screenshots so we can can also do the same to see if its just your setup.
do a rule with just set colour to red or something, then save it and open it again. You can then use the run actions to trigger it. Then set the lamp to a kelvin and run the rule and see if it still doesn't change.
Fixed all but one problem.......it seems that google home was connected to hue and the commands may of been issued that way when i was testing. I've disconnected hue and added hubitat for control. This seems to of solved all but one of the problems whereby if the light is off, rule kicks in turns on then goes red, if turned back on instead of going to the previous colour it stays red. I've looked through the logs and everything seems to run fine (capturing etc..)
"May have been"? Wouldn't you know this? If you say, "Hey Google, set Light X to white," it was Google Home. The advice above has all suggested manipulating the lights directly from Hubitat for the purpose of testing this rule. Anything else--the Hue app, voice assistants, IFTTT, SmartThings, or any other integration--will go through the Bridge and require a refresh before Hubitat gets accurate data. If you do want to change the lights with something else when testing, either wait for the next poll to happen (again, the default is 1 minute, but you can change it) or do a "Refresh" on your Hue Bridge device in Hubitat first. Basically, make sure the "Current States" section for your light is accurate.
Something else also occurred to me: a lot of Hue scenes that used to be based on CT now seem to get stored in xy mode. Therefore, recalling "Read" or "Bright" may not really set it to 2700-3000K...or it will, but it will use xy mode and not CT mode on the Bridge, which Hubitat can't read. I'm not sure how the stock integration handles this. This would make it even more important to manipulate the device from Hubitat only before your capture. Doing a "Set Color Temperature" to 3000 will ensure the bulb is in CT mode (a state that can be captured and restored by Hubitat) and has accurate data (because you changed it from Hubitat).
I'm not sure there's a good way around this, but since you clearly spelled out the sequence of events here, I think I see a likely source of the problem. Hue bulbs don't support receiving color or level commands (really anything) when off, so Hubitat may have either just captured the "off" state or tried to restore "off" plus color/level, which Hue will blissfully ignore. You might have to work around this by saving the bulb's on/off state yourself first to a local variable, manually turning it on, and doing the capture. Then, keep it on, do the restore, and then finally turn the bulb off if your variable that tracks its switch state does indeed show that it is off.
I see what you're say. I've not dealt with custom variables yet and thought i could do it with some if statements however the bulb now always goes lol. There's probably a lot of mistake but if you can spot one let me know
IF (Bi Fold Door open(F) AND
Office lamp(on) is on(T) [FALSE]) THEN
Capture: Office lamp
Delay 0:00:01
Set color: Office lamp ->Red ->Level: 50
ELSE
IF (Bi Fold Door closed(T) [TRUE]) THEN
Delay 0:00:02
Restore: Office lamp
END-IF
END-IF
IF (Bi Fold Door open(F) AND
Office lamp(on) is off(F) [FALSE]) THEN
On: Office lamp
Capture: Office lamp
Delay 0:00:00.3
Set color: Office lamp ->Red ->Level: 50
ELSE
IF (Bi Fold Door closed(T) [TRUE]) THEN
Restore: Office lamp
Delay 0:00:00.4
Off: Office lamp
END-IF
END-IF
I'd just define a local boolean (true/false) variable, then do basically what you were doing before, except capture the on/off state to this variable (so you know what it was before you changed anything), turn the bulb on and capture its state (so RM gets all color/level attributes, etc.), change it to what you want (red at 50%; I only did 50% in my example because I used a dimmer and not a bulb), then restore it (so it will get all the correct color/level states), and turn it off it was off originally (per your variable).
As always, look at the device page (for Office lamp, in your case) when testing. I'd also recommend making changes before testing from within Hubitat only. At the time of capture, what do you see under "Current States"? For white, you should see "colorMode: CT" and the "colorTemperature" attribute with a value ranging from about 2700-3000K. If you see "colorMode: RGB" and "hue" near 0 or 100, then that is red, so Hubitat doesn't have the latest information and won't capture and restore correctly. (Note that it will always show "colorTemperature" and "hue," but "colorMode" is what matters in terms of which really represents the current settings.) If you're not sure, show a screenshot of this section before and after the restore, and someone can tell you whether it looks right.
Also not sure where you put in the delay; a small delay after the "Capture" before the "Set Color" might help but shouldn't really be necessary. I'm not sure the 200-millisecond delay before the potential "Off" has any use.
turn the bulb on select this colour and then turn off. I then open the contact sensor and the it goes to this
then from this point the contact sensor is closed the bulb goes off however it still maintains the red colour when turned back on. The hubitat device page does not go back to the rgb colour it was at before
watching the device page as the bulb turns on from off i can see the colours change with the delays in. However the restore doesnt seem to work at all never seems to update the page. Almost like the command gets lost
If that first screenshot was indeed created after only manipulating the bulb using the Hubitat device page, I'm not sure how you got there. The bulb is reporting that it's a slightly unsaturated, white-ish green or yellow, not white. To set a Hue bulb accurately to a shade of white, use Set Color Temperature and put in your desired value. I'd suggest around 2700 to 3000 (units are Kelvin, but don't type that) for a warm white. You should see "colorMode: CT" instead of "colorMode: RGB" after that, and your "colorTemperature" attribute should reflect what you put in.
That is probably not directly related to your problem, but if you really did the above and don't see it reflected on the device page, it would certainly be indicative of some problem that might cause others. As mentioned in the other thread (this is getting confusing--you might want to pick one and stay with it), I'd be curious what RM is really capturing, which can help you verify whether its restore is really successful or where the problem may lie.
however when i click in the colour map and then click set colour the bulb doesnt change. Heres the problem! The bulb is a hue gen 2 for info.
