Setup 3 LZW42’s they are paired as S0 as no matter how many times I tried I could not get them to pair with no security. I have them on the dashboard as Color Blub. I can bring them up and set color and level but when I click the X to return to the dashboard the bulbs go back to white. When I click to go back into them they show as 84,84,84 where I had them as 0,0,255. What am I missing here? I wouldn’t think it would be this hard to get these to hold a setting. I am on a C7 at 2.2.6.140 and the LZW 42’s are on 2.3.1 firmware. I have tried both the Inovelli drivers and the Hubitat drivers but I get the same results. All bulbs have had 'Configure", “Save Preferences” and “Save Device” clicked.
Found out that I guess this bulb is not officially supported by Hubitat? Yet the Inovelli page shows they are. What can I do to get these to work properly?
As I mentioned on the Hubitat forum (probably a good idea to link to that here so people know what you’ve already tried), I believe the issue is that you are not getting reports back from the device or they are not getting parsed correctly. In general, “Current States” on Hubitat updates only with a report back from the device — not “optimistically” after you only send a command. And you’ve confirmed that the “Current States” on the device page are not showing the correct color. The problem is with that, not Dashboard specifically (or, as far as I’ve seen demonstrated, anything “holding a setting” — just not reporting them as expected, as I assume the device itself is otherwise OK?). If you keep info and debug logging enabled on Inovelli’s driver, you should see when reports come in from the device (the most helpful ones would probably say something with SwitchColorReport). If you’re using Hubitat’s driver, debug logging will be sufficient, though info/descriptionText logging will help you see what events it parses out of the “raw” reports.
As for compatibility, Inovelli could probably clarify this on their site, but the bulbs are indeed fine with the C-5. It’s the C-7 (or really the 700-series chip and official SDK they are using) that is the problem. Many community members believe this is only when paired with S0, which these bulbs will do by default on that controller; Inovelli’s hope (so I assume they agree with this) was to address this with the latest beta firmware that enables a new, non-secure pairing mode. I’m not sure why that isn’t working for you. A secondary controller would help you get there with any firmware (these can be found for as low as $20 USD; PC software or compatible Z-Wave software of some kind also required), but I know that’s something extra…
I do have a secondary controller but would I need it connected all the time? I guess I need to do more research about that. Might be a few days before I can spend more time on it. Thanks for your input thus far it’s appreciated. Really frustrating that there are problems with the latest version of the hub one would think they could figure it out and get it working properly and list it as supported again on Hubitat’s site.
There is some uncertainty in the Hubitat Community about whether leaving a secondary controller (generally a Z-Wave stick with something like PC Controller) unpowered, but enough people think it shouldn’t be a problem that I don’t normally worry about mine. But if you’re only using it for this purpose, you could join it, pair these devices, then un-pair it and not have to worry about it after that. (FWIW, it’s also nice for firmware updates; Hubitat’s built-in or community updater usually work fine, but a secondary normally works faster for me and works with devices that the former sometimes does have trouble with, like many of my LZW30-SNs.)
Assuming S0 is the only problem with these and the C-7 and that Inovelli’s firmware update addresses this, hopefully they’ll be “officially” compatible (with all models) again soon — otherwise hopefully someone figures out what’s wrong! There are a few “problem devices” on the C-7, with a couple devices from Zooz also being on this list (likely also S0-related, but with some of those I’ve also seen people say they’ve experienced problems with “too many” such devices regardless of security, so I definitely don’t know…).
Another odd thing that maybe you know about or someone else does. The driver here on Inovelli’s site has a 2019 copyright on it and originated on 9/9/2019 with the last update by bcopeland on 4/16/2020 but the driver I have loaded currently on my hub is a version that says v2.2 dated 2020-05-11 I would have thought I got it from here but I guess not. I’ll also need to try the driver that is here on Inovelli’s site currently.
Looks like you have Bryan’s own driver (here; no longer maintained, except he’s Hubitat staff now and the built-in driver is probably an updated version of this) rather than Inovelli’s, though they appear pretty similar. I’d probably use one of those two instead of that one, though I’m guessing the biggest issue is the overhead/chattiness of S0 pairing in any case.
I thought EricM suggested to start the pairing of the bulbs, then shut power off for a second or two, then power back up. This forced the bulbs to pair with no security. I ended up having to use a lamp in my basement to pair the bulbs. It was far enough away that forced it to pair without security.
Yeah, the “disconnect power from the bulbs while pairing” thing could work on any firmware, but it it will take some luck — the idea is to interrupt the key exchange (or some other crucial part of the secure pairing process; this might not be exactly it), but you can’t do it too soon or the entire pairing process will fail. If you don’t mind trying a few times to make it work, you’ll probably figure out it, but the updated firmware or a secondary controller are probably easier.
The behavior seems to have changed (for the better) with the 2.2.9 hub firmware on a C7. This is with a bulb from Inovelli’s recent batch with 2.31 bulb firmware, plus their current (Oct 2021) driver from github.
With this combination the bulb successfully paired secure first time, and both the device pane and the dashboard appear to set the bulb properly, and persist the values (including hitting ‘x’ on the dashboard and going back in). I tried switching between RGB & white modes, turning the bulb on/off, changing level and all worked properly.
I did notice the dashboard icon shows only the RGB color, regardless of whether RGB or white mode is active for the bulb, but that seems more like a quirk in the dashboard, not something specific to the bulb.
I just bought 9x LZW-42 bulbs (still need to purchase an additional 3) along with a plethora (30+) of switches as in theory this is exactly what I want.
I’m using the Hubitat hub with the latest upgrades and drivers (from @bcopeland). I’ve installed the bulbs and updated them all to the 2.31 firmware. I was able to handle most of the other issues, but I’m stuck on the following:
Following related to Hubitat only:
Any groups created in hubitat cannot control the ColorTemperature. On, Off, Set color, Hue, Saturation, Level all seem to work fine. Only the set color temperature does not work. So I’m able to turn them all red, then to get them back to let’s say 2,700 CT, I need to individually change each bulb.
The logs on hubitat show the following error message for each bulb signal
2022-02-05 11:43:23.582 am errorgroovy.lang.MissingMethodException: No signature of method: user_driver_djdizzyd_Inovelli_Bulb_Multi_Color_LZW42_579.setColorTemperature() is applicable for argument types: (java.lang.Integer, null, null) values: [6500, null, null] Possible solutions: setColorTemperature(java.lang.Object) on line 573 (method setColorTemperature)
With the working controls, for single and smaller groups (2 or 3 bults), things work fine and responses are good <1 second - 1 second. But for the larger group (all bulbs) sometimes the signals are delayed for minutes. I’m not sure or can figure out what is bogging down the hub. Sometimes a bulb or two won’t even get the signal, and I have to press it again.
The following are related to Siri/HomeKit/Hoobs additions that don’t seem to play correctly with Hubitat on my end:
Asking Homekit/Siri to change any bulb(s) to a specific color will flicker to the right color, but then go back to the last RGB color that was set on Hubitat. For example, I change a bulb to red on hubitat, then to CT 2700. I ask Siri to change the bulb to green, it’ll will flicker green for <1 second, then go back to red. If I manually change it in Hubitat to Green, then ask Siri to change to red (whether I got to CT 2700 or not), it’ll flicker red but go to green.
I looked at the logs, and Hubitat is showing a signal to do just that. Each device has two signals, one for the color I asked Siri then instantly a responding signal changing it to the set value on Hubitat. Anyone know how to fix this or what is causing that second signal?
HomeKit’s color wheel - If I select a color from the RGB, it ignores it. I have to hold the color, press “done”, go back in the edit, hold again. Sometimes this works, but others it doesn’t and I have to do it 2-5 times. for Hubitat to change it. Bulb/Hubitat pick up the CT wheel just fine, it is only the RGB having issues with this.
Following up on #4 (I think this may be related?), the preset values always go back to CT, even if an RGB is selected.
Someone please help! I really like these bulbs and would prefer to work through these issues if fixable.
For #2, have you considered or used multicast? I transitioned to that with the “on” lights when doing my away scene, and it significantly reduced lag times because it sends them to all instead of 1, then 2, then 3, etc. This is purely a function of the speed/power of your hub and strength of your z-wave mesh. Is it commonly pausing between one device’s command in the logs? Might be a specific device issue or a ghost on the network? I am on Home Assistant so I can’t tell you specifics of how Hubitat does multicast.
For #4 and #5, both of these SOUND like hubitat issues within homekit. I don’t use either so I can’t speak to it, but make sure you follow the path of the command in logs and see what doesn’t take. Also, consider posting over on the hubitat forums (if you haven’t) for help. It might be a driver issue as well. I personally don’t know of anyone to tag for Homekit via Hubitat.
when you say you downloaded the driver, you mean youbare using an external driver??.. use the built in driver… no download required… its maintained by bryan
@kreen1987 Thanks for the advice. Multicast sounds like a good option, but I’d have to check Hubitat options as I don’t believe I’ve seen that switch yet. It may be hidden somewhere and I just haven’t seen it.
@adriang809 the download was done through Hubitat’s Package Manger. There’s was two, one by djdizzyd and a second one by Inovelli USA. After they were download the bulbs were set to the djdizzyd driver, but I switched them over to the other. I assume the Inovelli USA driver is the one maintained by Bryan? I’m still fairly new, so if I’m missing something, please let me know.
But if you’re only using it for this purpose, you could join it, pair these devices, then un-pair it and not have to worry about it after that. (FWIW, it’s also nice for firmware updates; Hubitat’s built-in or community updater usually work fine, but a secondary normally works faster for me and works with devices that the former sometimes does have trouble with, like many of my LZW30-SNs.)