LZW42 - Hubitat = SLOW

what does the low bandwidth mode do? how does it compare to regular driver? any cons to it?

@adriang809 - I bought this from this thread about zniffing.

I’m still having issues. Single color changes seem to work, but when I use a color change app, the LZW42 totally fail. I toggle the colors between orange and purple at an interval of 5s and the lights perform horribly. I even bought two more zwave repeaters (ring extender).

I have a single zigbee rgb bulb (no repeaters or other bulbs) and if I replace one of the LZW42 bulbs with it (the one closest to the hub), the zigbee bulb performs perfectly. It toggles from orange to purple and back.

There is either a problem with the LZW42 directly, or the hubitat, or… I have an evil device on my mesh. I’ll be doing more zniffing and recording what’s happening between toggles. All my devices are zwave+ (inovelli switches, aeotec repeater 6, ring extender, GE outdoor outlets).

It’s maddening…

nope not just you… i have 25 phillips hue and they perform great and 25 LZW42 and they all act the same even the ones that are about 5 feet from hub (hubitat)

This is from the sniffer. This was one press of the color change button from the devices area for the bulb in hubitat. It seems to generate a lot of traffic. Device 16 is my bulb. Device 1 is the hubitat. Device 26 is the inovelli switch next to the bulb.

I don’t know if this is normal or not. But when I press the color change button from HE, I see the traffic settle anywhere from 1 to 4 seconds. When I use the color change app (which simply toggles the colors over and over again every 5s), I see the massive traffic backlog in the sniffer.

I see these bulbs are on sale right now - unboxed for $10. It pains me to not pull the trigger because of how unresponsive they are.

We have an alternate driver coming out that should cut down on the traffic. Tagging @EricM_Inovelli to explain more!

1 Like

I sadly ended up swapping the three on the front of my garage out for zigbee bulbs. Waiting for better days on the LZW42 front. I hope Inovelli can make these reliable, stable, and at least as speedy as my zigbee bulbs soon. Until then, my four that came in my Christmas packs are just gathering dust.

I believe they are white label bulbs. Does this eliminate the possibility improvement via firmware?

thats what got me the first time… and i bought 20… now im stuck with them … i will only use them were i dont need color even though they are capable because as of now color changing is very bad and takes tooo long to respond, slows down my hub.

Just throwing my hat in this ring. Exact same issue. I can add that the more bulbs are in the group the more exponential the chatter gets. I just ordered 20 additional bulbs before I found this issue. Rethinking that decision.

Same exact issue here as well, bulbs sometimes take up to a minute to change color. Hoping this can be fixed with a driver update!

I’ve updated to the latest firmware (2.30) (https://support.inovelli.com/portal/kb/articles/firmware-v1-30-beta-lzw42-rbgw-bulb). Using Hubitat’s Group Lighting (Group Bulb Dimmer 2.1) it’s relatively sluggish transitioning colors; however, if I change the colors individually it reacts pretty quick (less than 1 sec). So either Hubitat’s group lighting isn’t the best for my situation, or there’s some coding that needs to be revised. I also enabled Filter Out Duplicate Events.

2 Likes

Just wanted to say thanks for suggesting this firmware update. I just completed the upgrade on one of my bulbs and it was perfectly responsive from the device page.

Unfortunately, my use case is to control these bulbs with Pico remotes through rule machine, and they are just as sluggish as before. Hopefully, there are more refinements to be had - either via firmware or the official drivers provided by Inovelli…

If anyone else has suggestions or workarounds, I will certainly be happy to play the part of Guinea Pig…

I’m surprised to hear of the issues of slow color changes that some are reporting in this thread. I have 3 bulbs in the lamp in front of the house (outside) and the color change is pretty good, though it becomes sluggish if I change the individual bulbs to different colours too many times in a row.

The two that I have in a group inside don’t seem to have the same issue, but I usually always set them to the same color…

For those that are having issues, I would be happy to take the bulbs off your hand! :wink: . I could probably use more!

I also have a lot of GU-10 sockets… I wonder if bulbs for those are in the pipeline for Inovelli…?

Note: I upgraded the firmware to 2.30 with @bcopeland’s tool and had no issue. That driver is absolutely awesome!

2.30 has some dramatic performance improvements… I highly recommend this firmware for anyone using these bulbs…

Quick question for you – when using the Pico remote, do you have these issues with other devices? Also, if you remove the Pico remote from the equation, are the bulbs still slow? I’m just wondering if it’s a Pico or bulb issue. I have about 20 of these bulbs personally on Hubitat and they’re lightning quick.

We’ve also put 42 of these in a restaurant near us and to change them all to various colors at the same time takes about 5 seconds.

1 Like

Saw that video… It was impressive

Thanks for the reply!

I have the same Pico remotes, using the same button rules, in several rooms throughout our house. Three of the rooms have either one or a pair of LZW42 bulbs, and three other rooms have a 3rd gen. Hue color ambiance bulb with the same rules and button configurations. The LZW42s are connected to the Hubitat (as you would expect) directly via z-wave, and the Hue bulbs are integrated through a Hue Hub over the LAN. I ran a couple of quick tests just now, and the the Hue bulbs rattled off 10 randomized color changes triggered by individual button presses in 12.536 seconds. The same test on an LZW42 took 37.654 seconds.

Subjectively, the Hue bulbs might occasionally slowdown for a second but they seem to recover quickly and subsequent changes are smooth and consistent. The first command or two sent to an LZW is just as responsive as to a Hue, but follow-up commands seem to become progressively more bogged-down. In the test I did earlier, the first three transitions executed in .7, 1.9, and 2.8 seconds, the next several transitions took between 5.1 and 6.6 seconds each.

To take the Picos out of the equation, I created a new rule with 10 consecutive actions to set an LZW bulb to a random color, all triggered by a certain time of day. This shortened the total time for execution to 23.617 seconds and further highlights the progressively longer delays between color changes: 0.136, 0.323, 2.017, 2.495, 3.589, 3.269, 3.221, 3.906, 4.661 seconds elapsed between each color change.

You can tell by watching the logs that the Hubitat, in many cases, is waiting to interpret the Pico presses during the time after a bulb is commanded to change and before it reports that the change has been made. Therefore, it seems that the involvement of the Pico is further exposing delays caused by the bulb(s), but not really causing those delays.

If you can’t already tell - I love your products and want for these bulbs to be just as great as the 2-3x more expensive Hue bulbs I’m pitting them against. If there’s any more info I can provide or testing I can do, please just let me know!

1 Like

Have you updated to the latest firmware (beta) for these bulbs? Also, do you have any non-plus z-wave devices on your network?

1 Like

If 2.30 is still the latest beta firmware, then yes. I also have the latest Inovelli drivers, according to Hubitat Package Manager - the comments in that driver show the last changes were made by Bryan on 4/16. I am running Hubitat’s version 2.2.3.118.

I currently have 35 z-wave devices, all are 500-series or newer, except for a Schlage Connect lock (BE468). If anyone thinks that could genuinely be a source of this problem, I can pull the batteries for testing. I wouldn’t think it would be though, since battery powered devices do not repeat? Also, the LZW42 bulb I was testing last night is about 6 feet from the hub, so it should be one-hopping anyway…

I switched to @bcopeland driver and saw significant improvements. I’m not sure if these changes were published to Inovelli driver, but would be worth trying out.