These changes have been merged
I have run into something of interest that maybe you could help with code in the driver. I know you too have a bunch of iLumin bulbs so I figured you could test easily. The RGB Mix has a weird area in the bulb where it’s obvious that the curve doesn’t match the Color Picker index. Part of this is the whole x 3.6 conversion and the bulbs can do most any color. That said, when I tell Alexa to turn the bulb “Orange”, It sets to a Hue of 11 (suspect this is an Alexa Defined Value?) which is stongly a yellow color. If you manually set Hue to 6, we’re about where we should be. Can you code the driver to fix offset and reduce and input value when set to 11 to change to 6? Maybe an On/Off Option for Color Correction? All of my bulbs have this problem when issuing voice commands so I suspect you will as well. Any ideas?
I can for sure add this… I added gamma correction to another color based driver I work on… I’ll add this today…
Awesome! Maybe Hue 4 - 6. Not sure where it should land. Curious Did you test to see if you had the same issue?
Here ya go:
- fixed bug in CT report
- added gamma correction as an optional setting
Through my standard gamma correction algorithm, hue 11 ends up being 7
I don’t use alexa to set color… But I have used this gamma correction code in other RGB based drivers that I maintain… And I have found to to produce more accurate color…
Wow…that was fast. Works Great, thanks! While you are at it could we get “Last Activity” like there is in the Switch Drivers? That will help show when the config or Refresh commands were actually issued. For me, it showed me my clock on the Hubitat was off by 3 hours this AM due to a power outage because the stamp is shown.
last activity is built-in in the device data at the bottom… so this is redundant…
Ahh, I see. I didn’t realize it was down there. Thanks again!
I think they had this in their drivers as a holdover from ST…
this change has already been merged into official …
This is not new but maybe you have insight…I have noticed in the Logs for the bulbs that color changes add a lot of entries. Do you know why this is? For instance, I changed the light to Green and then to Blue…here are the entries.
|colorName|Green||Test - Light Bulb color is Green|DEVICE||2020-04-15 02:54:37.652 PM PDT|
|colorName|Green||Test - Light Bulb color is Green|DEVICE||2020-04-15 02:54:37.592 PM PDT|
|hue|33|||DEVICE||2020-04-15 02:54:37.582 PM PDT|
|color|#00ff00|||DEVICE||2020-04-15 02:54:37.576 PM PDT|
|colorName|Cyan||Test - Light Bulb color is Cyan|DEVICE||2020-04-15 02:54:36.824 PM PDT|
|hue|50|||DEVICE||2020-04-15 02:54:36.811 PM PDT|
|color|#00ffff|||DEVICE||2020-04-15 02:54:36.803 PM PDT|
|colorName|Blue||Test - Light Bulb color is Blue|DEVICE||2020-04-15 02:54:16.549 PM PDT|
|saturation|100|||DEVICE||2020-04-15 02:54:16.544 PM PDT|
|hue|67|||DEVICE||2020-04-15 02:54:16.535 PM PDT|
|color|#0000ff|||DEVICE||2020-04-15 02:54:16.529 PM PDT|
|saturation|0|||DEVICE||2020-04-15 02:54:16.406 PM PDT|
|color|#000000|||DEVICE||2020-04-15 02:54:16.395 PM PDT|
Are the extra color changes mentioned…like CYAN in there just added to soften the transition from one color to another because I only select two colors. Also, this is with “Filter out duplicate events” on but the first two (most recent) entries are the same but they do have different time stamps. Why would we see two entries that set the colorName to “Green” for instance 100ms apart. Is that just a mesh thing?
Duplicate event filtering is for events … not logs…
And because of some quirks in the device you may get some double log entries on color change because of the query that is necessary for longer transitions and missing color component ids when a single component value doesn’t change.
but even with duplicate event filtering turned on there is a possibility of really close events not being filtered as I am not using ignoreCache, as the whole point is to reduce database hits…
I just updated the driver, and it appears the option to set the power recovery state to off has been removed?
@EricM_Inovelli It looks like one of the recent commits (corrected incorrect options for parameter 2 · InovelliUSA/Hubitat@2e98ba3 · GitHub) is the cause of the problem. Can we get this functionality restored please
I did independent testing … And Even though this is valid according to the z-wave certification and the bulb accepts the parameter… It does the same actions as a value of 1 … The official drivers and my drivers reflect this now…
Thank you for taking the time to test that out. I didn’t see your message earlier and also did testing confirming the result. I’d love to see this make it into the firmware in a future release, but at least for now the current solution will do.
Thank you again!
I think there is a minor bug in the LZW42 driver. The bulb works fine, its in the Hubitat dashboard window. I have an Inovelli Bulb multi-color LZW42 in my dashboard using the template “Color Bulb”.
When I click on the bulb icon, a separate window opens with Color Bulb Options, Switch, Level and Color Temperature. If I click on the Switch to turn the light on, it changes to on, like it should. If I click on the (X) in the upper right of the window, the window will not close. However, if I click on the Switch to turn the light off, it changes to off, again, like it should. But now if I click on the (X) in the right corner of the window the window will close.
Not sure who to report this too, so I’ll post it here and maybe someone knows how to proceed. Minor bug, but thought I would point it out.
This has been documented before in the hubitat community… it is not a driver or device issue… it’s a browser / software issue…