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..)
1 Like
"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.
1 Like
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).
Here is one way you could do that:
1 Like
Still doesnt work and turns on red again when the bulb is turned back on. Added a delay in to see if that helped but it didnt. This what i've got
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.
ok so only using the hubitat device page 
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.
