More than it is already?
Not sure if this is a RM problem but I just updated to 2.11 and since then when my basement lights come on they are a funny orange colour even though they are set to White 100%. See rule:
Here is the Events log for one of the lights. See that it turned on as colour temp 6536K. I don't have that setting in anything. When I asked Alexa to turn the lights to White it turned them to white but then immediately when back to the colour.
Ah, the colors were adjusted in this release, and apparently yours came out for the worse. You will need to use a custom color. Try hue 52 and saturation 19.
Thanks, that's better! Where can I find the different hues and saturation value? Also, so can we not use the colour selections now?
Yes, you can still use the color selections. They were updated to be closer for most bulbs. But the whites are a problem. Below is the before and after definitions (if not specified, saturation is 100):
"White":
hue = 11 //52
saturation = 0 //19
"Daylight":
hue = 11 //53
saturation = 10 //91
"Soft White":
hue = 11 //23
saturation = 30 //56
"Warm White":
hue = 11 //20
saturation = 20 //80
"Blue":
hue = 66 //70
"Green":
hue = 33 //35
"Yellow":
hue = 16 //25
"Orange":
hue = 11 //10
"Purple":
hue = 83 //75
"Pink":
hue = 97 //83
saturation = 25
"Red":
hue = 100
1 Like
@bravenel, I have always been a fan of more and redundant knowledge transfer. I know and love that a lot of work has been put into the docs.hubitat, which is correct. However, when one is in the middle of trying to create a new ruler where are they? In the hubitat portal, not on docs. Is still think on screen help, notes or even contextually aware links into docs would be very helpful. Digital Adoption Solutions, or putting the right knowledge in the users hands, at the right time (like info pop ups and links) can really go a long way. My two cents, I am a huge fan of this style of just in time teaching.
PS love RM 3.0 and custom attributes in 2.11,
Cheers
2 Likes
I'm having issue with rule I just created using set fan speed based upon the temperature being true. The logs show the rule ran and the fan to turn on the events record the temp which made the rule true, but the fan did not turn on, but it turns on fine through dashboard and device page.
Also note on the events page the "timestamp" is not correct that should match the logs above?
The ? icon at the top of every app opens a new tab with the documentation for the app.
Please show the rule.
Did you look at the fan events? This works for me, can't reproduce a problem with set fan speed.
It's hard to tell when took place after I created this rule with the timestamp being inaccurate, but after I noticed it didn't come on I tried changing the rule using it as a dimmer value of 25, to see if anything was different, and one of the "low" was me manually turning it on to make sure the device was working.
Could it be possibly the rule is sending the action to parent device and not the child "fan itself" part? This is a Hampton Bay Fan Module which has the parent and 2 child devices for each light and fan?
EDIT:....Think I just found my issue, as I just typed that and seen what was selected.....sorry for wasting your time, I will change that and if it doesn't work I'll let you know.
1 Like
I have confirmed this is a bug, found the culprit, and fixed it. Will be in the hot fix release, probably tomorrow.
1 Like
@bravenel, I seem to be having a problem since the latest hotfix release as well. A rule (see below) was working just fine Friday and now fails (it doesn't run weekends so I didn't catch until today) with a ClassCastException. I haven't decomposed it to see which part (and have to run to work now) but figured I'd share now in case it rings a bell and can make it into the upcoming fixes.
I did just try editing it and chose to edit the first "Fade up" action since I know you changed some lighting stuff... that may be the culprit? trying to edit it has emitted an error and the rule editing is now stuck with this error:
app:9292019-06-10 07:06:28.315 am errorgroovy.lang.MissingMethodException: No signature of method: java.lang.Long.getAt() is applicable for argument types: (java.lang.Integer) values: [0] Possible solutions: getAt(java.lang.String), next(), putAt(java.lang.String, java.lang.Object), wait(), grep(), getClass() (selectActionsTrue)
Logs from the rule running:
The rule:
Any update on the hotfix for simple condition actions? Could really use it as soon as practical...
1 Like
Should be today.
1 Like
Not sure what's going on here. There was a bug reported earlier with fade dim over time, that has been fixed but not released yet. I just edited a fade up action with no issue. So perhaps we should revisit this after the hot fix release comes out, to see if you still have the issue or not.
