[DEPRECATED] Inovelli Bulbs Drivers LZW41/LZW42

🚧 Developers Code Share
,
61

Pushed an update for bulb power state memory.. Documentation was confusing

62

Pushed an update that adds firmware version reporting

63

@bcopeland Thanks for doing this! I've been tinkering around with your drivers on my LZW42 bulbs, and most things seem to work (where they didn't in the original drivers), but I think there might still be a few bugs. I'm new to Hubitat so I could be off, but here's what I found:

  • typo on line 229 of the LZW41 driver and 292 of the LZW42 driver: switchMultiLevelV3 should be switchMultilevelV3
  • scene capture doesn't capture (or allow adjusting) color temp with the LZW42 driver (it does with the LWZ41 driver), causing the bulb to turn on with default color #ffffff (I was able to work around this by capturing with the LWZ41 driver, then switching back to the LZW42 driver)
  • setColor doesn't seem to propagate level; this means that when in color mode, scene captures hue, saturation, and level just fine, but activating the scene only propagates hue and saturation, not level
  • this may be an issue with scene, but when using pre-staging, activating a scene just pre-stages the color, but doesn't turn the bulb on
  • earlier, I also observed the flash of the bulb during scene transition that @eyrich mentioned, but haven't been able to reproduce it

Note: I was using the version from last night. I haven't looked at your latest changes, but from your comment these probably still apply (except line numbers may have changed).

EDIT: I was able to reproduce the flashing bulb issue by capturing scenes using the LZW41 driver. Switching back and forth between 2 scenes with the same CT and level 50 and 100, it flashes in both directions. But at least the end states are correct.

2 Likes
64

Checking

65

Ok @kdb

All of the above should be fixed now ..
Scene capture issue was because of missing colorMode capability
setColor level was something I missed

there is now an exception to pre-staging .. if level changes in setcolor it will turn on

Not sure about the flash.. but might be fixed... Let me know if you can re-produce that one again..

The update has been pushed to github

66

Thanks that seems have fixed those issues.

The flashes still happen, though inconsistently, and only during scene transitions (not when using setLevel directly from the device page). I think this might be some interaction between the setLevel and setColorTemperature commands sent by scene. I have no idea if this is how it works, but, say, if setColorTemperature internally sets the combined CT+level state using the "current" level, this would explain the flash in the case where setLevel has already previously started the fade to the new level, but the "current" level hasn't been updated yet.

I did try adding a check to the top of setColorTemperature that early terminates if colorMode is already CT and the new temp is the same as the current one, and that seems to get rid of the flash. As a bonus it's also a lot faster, as setColorTemperature seems to take a while and generate a lot of logging (for as long as around 30s after the command is sent).

1 Like
67

Interesting so you are seeing the flash when CT gets set to the same value?

68

Only in a scene transition that has the same CT but different level. If I just call setColorTemperature with the same value from the device page, no flash (and nothing happens), presumably because there's no already-fading-level for the combined CT+level setting to race against.

1 Like
69

Thanks for the info.. I'm going to work on this...

70

mistakes were made on setcolor … fixed them..

also now checking for setting same values on color temp and ignoring

new version has been pushed to github

71

Response times are better on the latest version too

72

Bulbs are running great. All changes are very fast. Nice job.

1 Like
73

Thanks @razorwing .. It has been a journey... But I think I got it

74

Everything with color temp looks good with my tests. Thanks!

Sorry to keep bugging you, but just a little nit with setColor. Right now the level from setColor is not being saved to current states, so scene will capture whatever level was there before. I think you just need to add a sendEvent in place of the switchMultilevelSet you just removed?

Lastly, I saw you removed the turn-on-if-level-changed hack in setColor. I guess since level is technically part of color in the RGB case (though a bit confusingly not in the CT case), it makes sense not to bypass color pre-staging here. But it does mean that if you use pre-staging, RGB scenes aren't going to work. Like I said before, this seems like this should be fixed in scene and not in the driver, so I'm happy with the removal.

Again, thanks for all the work you've put in this!

1 Like
75

Yea.. I see the problem.. But multilevel is not how to fix it.. I know what to do.. Will update this morning

76

@kdb fixed and pushed to github

1 Like
77

@bcopeland Something has gone wrong with latest update. Sometimes colorName doesn't change when doing colors. When I switch to white the Level number drops to zero. Also when I put in a CT number after playing with colors and send the bulb goes off.

78

Ok... I know exactly what the issue is … will fix momentarily

79

@bcopeland Hate to add to it but you might take a look at the color map. I picked a red spot and sent it and the hue, sat and level reads -4, 97, 92 and I know this red obviously should be in the 90's and I have set sat and level to 100.

80

svg

hue is 0 to 360 represented as 0 to 100 in HE

hue = (hue * 3.6)
switch (hue.toInteger()){
    case 0..15: colorName = "Red"
        break
    case 16..45: colorName = "Orange"
        break
    case 46..75: colorName = "Yellow"
        break
    case 76..105: colorName = "Chartreuse"
        break
    case 106..135: colorName = "Green"
        break
    case 136..165: colorName = "Spring"
        break
    case 166..195: colorName = "Cyan"
        break
    case 196..225: colorName = "Azure"
        break
    case 226..255: colorName = "Blue"
        break
    case 256..285: colorName = "Violet"
        break
    case 286..315: colorName = "Magenta"
        break
    case 316..345: colorName = "Rose"
        break
    case 346..360: colorName = "Red"
        break
}

so red actually exists on both sides