However everytime the motion sensor is triggered between midnight and 6am, the lights first go up to 100%, and then back to 20%. So while I'm at my desk the lights repeatedly go to 100% then back to 20% every few seconds (while I'm sitting at the desk the motion sensor will often go inactive and then active as I am not moving). Logs for one of the lights in the scene below show it being set to100% then back again:
I've tried adjusting the rule to set each light directly to 20% rather than through a scene but the same thing happens. Any advice as to what I might be doing wrong would be appreciated.
All hues are linked to a Hue bridge then to Hubitat.
[Edit: Just a quick note that there are no other rules changing the lights. E.g. If I "pause" the above rule, the lights no longer turn on]
I may be having a similar issue, but mostly for one down light. I'll read through your post in more detail and do some investigation of my own before reporting back
I have mine paired to the hue bridge and integrated with he through the advanced hue integration. I'm pretty sure I am triggering a scene on the hue bridge, bud will need to double-check
My Hues are also on the hue hub but the rule is running in RM5. Its an old rule running on 4.1 and has been working fine up until recently. However I am a constant tinker of rules so I am always changing them.
ya weird.. if it went to 100% in the middle of the night that would be annoying.. are you sure it is not coming on with the last brightness the bulb was at before dimming, that coiuld be expected..
If so you may want to write a rule to set the dimming level whenever they are turned off.
In my experience, this is normal with Hue bulbs when controlled via the Hue API, as any Hubitat integration uses. The exception is when recalling scenes, which the Hue app or third party Hubitat integrations (not the built-in one) can do--that seems to be the only way to get them to turn on directly as configured without a brief hint of their previous level.
What I'm not sure of, then, is the implication that this ever worked as described above. I wrote my own integration and no longer use Hubitat's, but the API calls are similar and probably won't affect the outcome...
I've done a little more problem solving and it appears it is being caused by something in the rule. I've paused that rule and made the following simple rule in RM5.1 and it is working fine - turns on at the 20% level rather than flashing bright to 100% then going to 20%. I'll rebuild the entire rule in RM5.1 and see if it goes away.
Maybe I’m misunderstanding, but using your Hue integration I don’t see this happening with my Hue lights. I only have one area left in my house that is using Hue scenes, the rest are setlevel commands in BC and ML apps (with Apple’s Adaptive Lighting for CT transition). I never see them do anything but come on at the requested level.
I don't think I used the "and" "or" condition correctly. In the circled area my intention was that to trigger if the following two conditions were met:
Any of the motion sensor and vibration sensor active; and
time between 6:01 and 23:59,
then set the lights at 100%.
However I think the condition instead operated as follows:
Motion Sensor Active; or
Vibration Sensor Active and time between 6:01 and 23:59,
then lights 100%.
Then the rule would go on to the 20% setting as that condition was also met.
So it appears that the culprit is my poor understanding of the use of and/or in conditions.
Thanks everyone for your assistance and advice. It helped me to not only identify the problem, but also improve my understanding of conditions.
The parentheses conditional in RM is your friend and it seems that it must be explicitly utilized (RM in my experience does not seem to follow arithmetic rules of how functions are executed). I had to go back at one time and make sure all my rules had the conditions explicitly grouped by (xxx OR yyy) AND zzz which works differently than xxx OR (yyy AND zzz) as I was having similar problems when I first started using RM.
Am I misinterpreting my use of parentheses in my conditionals? I thought that my two examples would exhibit different logical characteristics. Please clarify. Thanks for the info!
Your first example, (xxx OR yyy) AND zzz, should be the same with or without parentheses. Your second would be different, which is the part I could see tripping some people up since in many programming languages, AND has precedence over OR (but again, not in RM--it's just left-to-right by default).
I wrote my own integration and no longer use Hubitat's, but the API calls are similar and probably won't affect the outcome...
