Spoke too soon, if the light is in an off state it turns on, goes red then stays on when the contact in closed when it should turn back off
What did "switch" say under "Current States" for the light(s) at the moment before your Capture action took place in RM? My guess is that the state is not getting updated correctly in Hubitat (again, could be due to changes made outside Hubitat and the next scheduled poll/refresh having not yet happened; the device page will tell you the same information RM sees).
under the current states it reports the state almost instantly for either open or closed
I think we've established that the contact sensor is reporting fine at this point. My concern is only for the bulbs:
This would give you an idea of what RM is capturing and, in turn, trying to restore.
Sorry! Yes, its not reporting correctly for the bulbs at all. Def where the problem is
So we're back to the questions:
- Are you making the changes outside Hubitat?
- If you make the changes outside Hubitat, are you waiting for the next scheduled poll to happen before relying in capture to work correctly? The default is 1 minute (so that's the longest you should have to wait to see a change made outside get reflected inside Hubitat, and it would usually be less time); you can check or change this in the Hue Bridge integration app.
My recommendation for right now would be to manipulate the bulbs only from Hubitat. You can turn them on or off, set their color or color temperature (shades of white), and set their level all from within Hubitat by using the device page (or a Dashboard if you have one set up--my recommendation if you want to manually control them on a regular basis). Using the Hue app to make changes and then testing capture/restore is a recipe for disaster at this point if you don't wait for the polling.
-
No changes outside hubitat - webcore and smar things no longer running rules on the light.
-
Even after waiting for more than a minute it doesnt work as expected.
Feel I've gone backwards here jumping to hubitat haha
What is your Hue Bridge polling interval set to?
That being said, something seems odd. If you change the bulb (or group) in Hubitat, the bulb state should change immediately. It does not wait to "hear back" from the Bridge, so something is wrong if it doesn't. Are you sure the bulb is actually getting changed in Hubitat?
I'll be no help here but want to share anyways; this was the first "fun" automation I tried to setup. I was using Core on ST with Osram BR30's. Those lights drove me nuts. They would change to Red just fine, but would always restore to some muddy/pink non-color. It seemed the more times I tried the worst the restored color would look. I gave up eventually, this thread has inspired me to see if HE is any better at taming my Osram's. Thanks for the inspiration.
Ha. So the rule seems straight enough.
I first tried setting the color to Red by selecting Red off the drop down. The light changed to a pale green. Changed it to a custom color using 1/100/50 for my values. That got me a nice ruby red. When restored those Osrams don't let me down; Emerald Green!
I reset them to color temperature 2600. Open door; RED. Close door; GREEN.
Maybe it's not the bulb; be right back... So I manually changed the light to Yellow. Opened the Door; Red. Closed Door; Yellow. I think since the bulb type is Color RGB, the capture is capturing whatever color was last set instead of the Temperature setting that I want.
That makes it a RM issue and not my bulbs I would think...
1 Like
@bertabcd1234 Its set to one min
@michael.l.nelson That makes me feel better knowing its RM and not me! So what do we do now? I bought hubitat to run the webcore rules faster and more advanced. Don't really want to install webcore as i might as well go back to Smart Things as it did just work.
Thanks for the help so far!!
There is a known issue with certain lamps (mostly any lamp out side of the US it seems). All of my lamps osram, aurora and Philips you can't change the colour or temperature unless the lamp is on. To get over this you 1st need to call the on then about a 0.2 second break then the colour or temperature. If you try splitting up the commands to the lamp does that help?
i've always had a 0.5 delay in the code. i've changed the hue hub to 10 second updates and it seems to of helped on some of the odd behaviour.
IF (Bi Fold Door open(F) [FALSE]) THEN
Capture: Office lamp
Delay 0:00:00.5
Set color: Office lamp ->Red ->Level: 50
ELSE
Restore: Office lamp
I can now get the lamp to turn on when off, then go red, then turn off when the contact sensor closes. However when the light is turned back on it isn't remembering the last colour it was and goes back to red. I'm tempted to install webcore to the hub as it worked flawlessly, shame hubitat has failed at the first hurdle!
Any other ideas that anyone can think off?
The delay would need to be here.
Set lamp level 50
Delay 0.5 s
Set colour RED
ELSE
Restore
This also isn't a good idea, just don't control your lights with the HUE app only control them in HE and your be golden.
This wouldn't help it's the driver it doesn't handle 90% of lamps correctly. Basically unless your lamp supports pre staging you have to work around it. It actually happened in ST as well but because it was so slow you just noticed sometimes it didn't work. HE is fast so the device is just ignoring the command.
Your restore is calling a OFF so that's what it hears 1st, it's then getting told to go to white but it's too late its OFF so it's not taking it.
A prove test would be to have the light white and ON then trigger the rule, hopefully it will go red then go back to white on the restore.
Well just for fun. I went back to my rule and added a few more bulbs. A Sengled RGBW and a Hue RGBW connected through a Hue Hub. The Sengled and Hue work correctly. The OSRAM does not. So it's RM and OSRAM that don't interact correctly. If your Hue bulb isn't working you should double check your rule. Are you closing out the IF .. Then .. Else with an END IF?
1 Like
So the work around for crummy OSRAM bulbs is to use variables. I used local variables in this rule. Works as intended. Door Open; RED / Door Closed : [restored to correct CT and Level].
The Hue lights should be working with capture/restore. If they aren't you can always go the local variable route.
1 Like
hmmm no matter how i alter the rule odd/different behavour keeps going on. Sometimes it turns off sometimes it does't. Other times it changes the colour back other times not. Could there be something wrong with the hub? never had these problems with smarthings
The public opinion here seems to allude to HEās local processing speed exacerbating build issues with some devices such as lights and locks.
@BorrisTheCat has outlined some good steps and Iād go further and suggest you get your rule working stably with only 1 parameter (colour OR level ) before adding another.
Just work to get the troublesome light working reliably and simply, then add colour or level.
Stick with it 
1 Like
