Color Philips Hue bulb turning on to default HSL and not per the executed rule

Hello,
Trying to have RM serve my Sylvania Lightify dimmer remote so that an on press (button 1) sets the bulb's HSL values based on the time of day. For some reason, even though the logs show the rule executing upon button press, the bulbs are set to their default full brightness, soft white state and it's not until second press that they take the HSL values that the rule assigns. This also applies to my "off" rule for button 2; if I hit button 2 while the bulbs are already at an HSL of 0,0,0 i.e. off, it sets their HSL values to default full brightness, soft white, and upon second button 2 press it goes back to 0,0,0 (off). Any help would be appreciated. Pretty green with HE and HA in general.

Even though the rule registered and is what actually changed the HSL value of the bulbs, you can see the default hue/saturation values are what was assigned to the bulb around 07:55:32.356 pm plus or minus two events. Only after the second press of button 1 did they take the appropriate color.

Additionally, at the top of the log (latest entries) I can't explain the hue/saturation values. I don't have those h/s values anywhere in my rules. The lights did indeed appear to turn off though.

image

Here's my "off" rule:
image

Here's my "evening" rule:
image

Your off rule is setting a custom color rather than turn the device off #1. You also don't need a time restriction if button 2 is always used to turn them off. #2, why are you doing thisin so many rules? You can set the color of the bulb per mode (i assume you have all those times of the day broken up into mode). Or you can use conditional logic to have it all in one trigger based on the button press. That would be a lot easier and you help understand why that's happening. Showing only one of the on rules isn't going to help. You'd have to show all of the rules related to that button.

I was going to say the same as @Ryan780 your rules can be a lot simpler. For the off also just use a trigger rather than a trigger rule or the button controller.

But all this isn't the issue, where are you based because I think I know the problem depending on where you are.

I'm in Wisconsin near Milwaukee. I did update the HE's time if that's what you're thinking (had to do this again after it defaulted to 2014 when my toddler hit the off button on the router/HE power strip). I did notice the sundown time is pretty far off though.

@Ryan780 Thanks for the input.

It's setting HSL to 0,0,0, i.e. off which is what I read someone else doing in a Smartthings forum I think it was for "off". I'll look for the off state and change it.

I couldn't find a good condition to basically say "always do this". First I had the condition set to "if the light was on" but then if the light wasn't on as far as HE was aware, like if the physical switch was accidentally used, then the off rule didn't execute.

I have one rule per time period since there's no "else if" functionality in a rule that I saw. Each time period sets the bulb to different HSL values. If there's a way to do it less rules I'd love to learn how.

Sorry, mode? I'm just setting HSL values explicitly in each rule.

So you're saying I should add all my time-periods as conditions in a single rule. When I do this, how do I correlate one specific condition with one specific set of HSL values?

I showed screenshots of the only rules that had their conditions evaluated to true in the logs I posted. All my other rules are identical except for the time range and the HSL values. I can post them if it would help.

I would just turn the switch for the device "off" by using the switch capability. But that's how I would do it.

I would just use a trigger instead of a triggered rule.

There is in Rule 3.0.

@Ryan780 Thanks again for your ideas.

Not sure exactly where this is but I will look for it. This is RM rule functionality, correct?

Again not sure exactly where this is but I will look for it. Sorry, I'm very green with HE.

I just installed the app last week. I'll check the version I'm on and look for this functionality.

Sounds like in general I need to poke around RM more to find this stuff.

You need to have the latest firmware update to get RM3.0

Yeah modes a basically true global variables, HE already has some built it but you can create more. For example when your away you put the hub into "Away" mode this would set HSM to armed-away then you could you have "home-AM" Home-PM" ex. I have home away evening, night, night-sleep and some others then depending on the mode the lights come on at certain levels and Kelvin. This is a much better easier way to do things for everyday. Then on top of that you can restrict thing by time where needed.

Nope not that, it shouldn't effect you then as your in America. Over the pond there seems to be differences between ZigBee lamps and the react differently. They have to be in there ON state before they will except a colour or temperature command. So you could test this by using the device page send a off then a colour it's not on and see if it goes to it.

I'm embarrassed to admit there is a FW update I was neglecting in my haste to get my bathroom lights working! Will check asap.

Cool. Where can I find/set these?

Settings location and modes.

Didn't get much time to work on this tonight other than doing my FW update. Looks like I need to recreate all my v2.5 rules from scratch? It doesn't look like there's a way to update existing rules.

Yes, existing Rule-2.5 child apps will remain as such, while new ones will be created as Rule-3.0. However, most of your rules could probably be greatly simplified with the features in RM 3.0, possibly all or mostly in one rule with conditionals in the actions, so I'm not sure if being able to upgrade individual rules would be of much help here. (I'd also recreate that triggered rule as a plain trigger if you already haven't.)

I've been strapped for time to work on this, but I have noticed that my [v2.5] rules are setting the "L" component of the HSL properly upon first execution; it's just the "H" that is not being set until the second execution.

Though I understand my approach wasn't the best, through my experience I've come to believe that what I've set up does have proper logic and should work, which leads me to conclude that this is a bug in RM 2.5. I looking forward to finding out if this was fixed in 3.0, though I'll be re-implementing my rules using the methods suggested here rather than my previous one so I'm not sure I'll get a definitive conclusion on said bug.

While I still really like HE being locally based and more hacker-friendly than other hubs, I'm starting to fear it will become a big time-suck, albeit a somewhat fun, tinker-y one, but ultimately not a very productive use of time. It is seeming a little more beta than anticipated, and though normally I like that sort of thing, I am up to my gills in more productive projects right now and thought this would be a bit more user friendly. This is just a fear; the jury is still out, but I have to imagine other hubs like Samsung and Wink for the general public have more user-friendly UI's that are just quicker to get stuff done in, though obviously with their own drawbacks that HE does not have.

Yeah, this is flat out wrong, it's setting the color to red, the saturation to 0, and the level to zero.
Net effect being the device will be turned off, however the next command will end up transitioning from white to the intended color, most likely in an unpredictable way.
If the intent is just to turn off the device, use the off command, it doesn't dink with any of the previous color or level values...

Additionally, sending a color command like that will generate 4 frames, off generates 2...

1 Like

This was all they claimed in the ST forum too, but point taken. Not sure why they did this. Maybe it was a webcore thing. I'll definitely fix it though, thanks.