[DEPRECATED] Inovelli Bulbs Drivers LZW41/LZW42

MRobi · May 11, 2020, 5:28pm

I just pulled in the update and tried low bandwidth mode. I'm not sure if the issue is in the bulb driver or in MakerAPI but I'm pretty sure it's on the HE side.

I sent these commands
curl http://IPADDRESS/apps/api/APP-ID/devices/DEVICE-ID/setHue/85?access_token=TOKEN
curl http://IPADDRESS/apps/api/APP-ID/devices/DEVICE-ID/setSaturation/100.0?access_token=TOKEN

This is the resulting log:

Interestingly, if I send just a hue change or just a saturation change, I get the expected result. I do still see what appears to be colour transition even with low bandwidth mode enabled.

But sending both together I get a complete random colour. I wonder if this could be the saturation command arriving while the hue is still transitioning??

I just ran another test. Sending saturation followed by hue I get the expected result. Sending hue followed by saturation I get a random colour.

bcopeland · May 11, 2020, 5:30pm

set hue and set saturation are 2 setColor calls

MRobi · May 11, 2020, 5:37pm

But MakerAPI doesn't support a color map so it must be sent as 2 individual commands

bcopeland · May 11, 2020, 5:38pm

I know.. I was just explaining why it shows 2 set color events

bcopeland · May 11, 2020, 5:39pm

it also appears that you are having some repeated packets...

MRobi · May 11, 2020, 7:01pm

It appears that the second event is the winning color. Could it be because the setSaturation command is being received while the color is still transitioning and it grabs the current color when it receives the command? The 255,0,229 is the expected color (hue 85, sat 100 = Magenta). That 5,0,255 is a blue that seemingly comes out of nowhere, and the end result in this case was a blue bulb.

Definitely some repeating going on in there.

JasonJoel · May 11, 2020, 7:04pm

Actually...

bcopeland · May 11, 2020, 7:05pm

Yes.. actually now that you mention it, if you have colorTransition time set, issuing these setColor and setSaturation separately within the colorTransition time could cause some very unexpected results. If you plan on using makerAPI for this primarily, I would turn colorTransition to 0

bcopeland · May 11, 2020, 7:07pm

NVM thanks @JasonJoel.. @MRobi see above

MRobi · May 11, 2020, 8:09pm

colorTransition was already set at 0.

That update looks like it should do what I need, except it doesn't seem to work.

http://IPADDRESS/apps/api/APP-ID/devices/DEVICE-ID/setColor/{"hue":88,"saturation":50,"level":90}?access_token=TOKEN

That should get me what I'm looking for, except I get
{"error":true,"type":"java.lang.Exception","message":"An unexpected error occurred."}

Am I missing something?

bcopeland · May 11, 2020, 8:27pm

Is there an error in the device log? or just makerApi?

MRobi · May 11, 2020, 10:18pm

Nope, I think it was me. I might have had the wrong device ID. Doing it that way is giving me the right colour. That works much better!

I'm still seeing what appears to me to be transition.

I've got color fade time set to 0 and low bandwidth mode enabled.
Normal?

maxq10 · June 6, 2020, 11:26pm

Question - I noticed that these drivers are now included in the most recent Hubitat update (2.2.1). I currently have the driver installed separately under the Drivers section. Do I need to do anything when I update to v2.2.1?

bcopeland · June 6, 2020, 11:49pm

Nope.. You can continue to use the community or move to the internal.. Just hit configure after you change a driver

daweeze · June 6, 2020, 11:53pm

Which one will receive updates and enhancements?

maxq10 · July 19, 2020, 6:29pm

I have a question about how to set a custom color with these lights.

I would like to set a custom purple color in one my rules with these bulbs. In Hubitat, when you choose Set Color on a rule, it gives you a list of preselected colors, or a custom color. When setting a custom color, Hubitat wants the color in HSL format. No problem I thought - I'll just look at the HSL color wheel and pick something that way. The custom purple I want should be somewhere around a Hue value of 284. But when I look at the color wheel in Hubitat, the resulting color I get is NOT purple.

If I manually choose the color with the color map in Hubitat, the purple I am looking for corresponds with Hue value of 76.

hsl

This is not at all what the HSL color wheel says it should be. A hue value of 76 should be a green-ish color. So, I'm very confused here! The values for Hue on the color map only seem to go from 0-99?

bertabcd1234 · July 19, 2020, 7:39pm

There are two concerns here: the general-purpose hue (color) wheel is represented as a circle and goes from 0-360, where the units are degrees (on the circle) and both extremes are red. Hubitat's standard hue model scales this to 0-100 (copying SmartThings, who did this first for whatever reason, maybe scaling it to percent). So the first issue is that if you find a "traditional" hue value, you want to divide it by 3.6 (i.e., a shortcut for doing the value times 360/100).

The second is that every brand/model of bulb might have a slightly different interpretation of hue values. They'll usually be pretty close, but I just wouldn't expect to find one perfect "purple" hue value that works on all bulbs (if it's too blue, try making it higher; if it's too magenta/pink-ish, try lower). For example, the 284 value you found (presumably from some general reference) would be about 78-79 when scaled to Hubitat's model, but it sounds like you prefer 76. Some bulbs also do things better than others, e.g., I find Hue bulbs to be pretty orange compared to others at either hue 0 or hue 100 (with saturation at 100 for all), and the first-gen had yellowish greens. (Still my favorite bulbs, though--just the newer gens. )

A third concern is the "enable high-resolution hue" option you may see in some drivers. This actually does allow you to use hue from 0-360 instead of 0-100, and because you have less change between each value, may allow you to get some finer "in between" control of hue if you want subtler changes. I'm surprised the driver did anything at all with the 284 value without this, but some will try to recover gracefully (perhaps using 100 or the max instead).

PS - Don't forget about saturation, the other aspect (besides level, which is fairly intuitive here--except that Hubitat's color picker shows it as more black when really it's just dimmer). As you did above, I'd recommend starting this at 100; lower values will look closer to white, while higher values will be closer to the actual color you're likely actually looking for.

bcopeland · July 19, 2020, 8:08pm

Install and run this app.. It will show the comparison

github.com

djdizzyd/hubitat/blob/master/Apps/hsv100to360.groovy

definition(
        name: "Hue Color Mapper",
        namespace: "djdizzyd",
        author: "Bryan Copeland",
        description: "HSL 0-100 color map",
        singleInstance: true,
        category: "My Apps",
        documentationLink: "",
        iconUrl: " ",
        iconX2Url: " ",
        iconX3Url: " ")

preferences {
    page(name: "mainPage")
}

def mainPage() {
    dynamicPage(name: "mainPage", title: "Hubitat HSV100 Colors", stall: true, uninstall: true) {
        section {
            String table = "<table border=1><tr><th>Hue<br/>360</th><th>Hue<br/>100</th><th>Color<br/>Hex</th></tr>"

This file has been truncated. show original

adriangenao260 · September 30, 2020, 1:21am

Does having alot of devices logging all the time causes the hub to slow down?

tmichael · October 6, 2020, 2:49pm

I have written a separate post about my general question, but I wanted to ask as well about the specific situation of an LZW42.

I also know that you started this thread and did much of this driver work before you became a Hubitat employee. I assume that being an employee means that your priorities are at least partially driven Hubitat's vs what you might otherwise have done. As a result, I am content with any feedback you might give.

I am a fan of using the startLevelChange (up or down) and the stopLevelChange commands that are available in most if not all drivers for dimming capable bulbs. What I have found however is that they typically change at different rates. Just to be clear, I am only talking about the startLevelChange and not the setLevel where a duration is typically available as an input.

I have a mixture of Zigbee and Z-wave bulbs. Most are paired to my HE, but a few of the zigbee bulbs are paired to a parallel Zigbee mesh controlled by zigbee2mqtt (Z2M). For those on Z2M, I can issue the equivalent of a startLevelChange with a rate of change parameter.

Do you have any insight into whether such a command could be issued to an Inovelli LZW42?

I know such a command would require a new/modified driver and that just because an Ikea Zigbee bulb supports such a command (or Z2M is simulating such a command and doing so internally), doesn't mean that a Z-wave bulb would necessarily support it.

Additionally, I would love any clarification about the drivers for this bulb. Here is what I think I know about them:

There seem to be 2 widely available drivers
Inovelli Bulb Multi-Color (built in Hubitat driver)
Inovelli Bulb Multi-Color LZW42 (user driver available from Inovelli)
The Inovelli driver can be maintained and updated through Hubitat Package manager (a user app)
It appears that the work that you did and discussed in this thread were ultimately incorporated in to Inovelli Bulb Multi-Color LZW42 (user driver available from Inovelli)
There are a few capability differences in capabilities between the built in and Inovelli drivers

As you have transitioned from community member who created/enhanced many things to Hubitat staff, if you ever prioritize making changes to the driver going forward, will those changes be exclusive to the Hubitat driver or the Inovelli driver or will they be Hubitat exclusive, but shared in such a way that Inovelli may choose to incorporate into their driver?

I have been told in the Inovelli forum that the enhancement that I (and possibly me alone) want is not supported by the device as it is a white label item where the original manufacturer controls the firmware and would be responsible for supporting such a command. If I were to dive into the driver build/modification world, is there a good starting point for documentation on knowing what commands a given device supports and how to send such commands?

In this case I see in the current driver this line:

sendToDevice(zwave.switchMultilevelV2.switchMultilevelStartLevelChange(ignoreStartLevel: true, startLevel: device.currentValue("level"), upDown: upDownVal))

and would love to know if this is in any way modifiable in the direction I want or if it literally exercising all supported capabilities.

Thanks for any feedback if you read this entire novel of a post.