Support for Inovelli LZW42 RGBW Bulb

Will there be added support for the Inovelli LZW42 RGBW Bulb?

Code: Select all

Indigo Device "041 - Inovelli Bulb" Z-Wave Properties:
Indigo Z-Wave Version: 7.4.0
Node ID: 41
Model: Dimmable Power Switch
Model ID: 00050001
Manufacturer: Unknown
Manufacturer ID: 031E
Protocol Version: 4.38
Application Version: 2.28
Model Definition Version: 0
Library Type: 3
Class Name: Dimmable Power Switch
Class Hierarchy: 04 : 11 : 01
Command Class Base: 26
Command Versions: 20v1 33v1 85v1 86v1 27v1 70v1 72v1 73v1 98v1 59v1 5Av1 26v2 7Av1 5Ev1
Encryption Status: Supported but not Enabled
Multi-Endpoint Types: - none -
Multi-Endpoint Classes: - none -
Multi-Instance Counts: - none -
Features: routing, beaming, security
Neighbors: 5, 27, 29, 30, 33, 34
Associations: 1:[1]
Config Values: - none -


[matt (support)]

Do you have a link to the PDF for the manual (or any other technical documentation)?

https://inovelli.com/wp-content/uploads ... Manual.pdf

https://inovelli.com/shop/z-wave-smart- ... structions

Hope that helps

[matt (support)]

Indigo 7.4.1 is now available and includes support for Inovelli Dimmer Switches (LZW31, LZW31-SN, NZW31), Relay Switches (LZW30, LZW30-SN, NZW30), LED Bulb (LZW40), Tunable White LED Bulb (LZW41) and RGBW LED Bulb (LZW42).

If I'm still on 7.1.1 (due to not wanting to be indefinitely "subscribing" for software I already paid for in full once and bought a few upgrades along the way to boot ( *end rant* ) ) is there any way to send raw zwave commands or a script solution to set RGB colors on this bulb? Bought it because it was listed as compatible but didn't realize I needed version 7.4+. The manual references some zwave command classes including COMMAND_CLASS_SWITCH_COLOR_V1 and "Switch Color Set Priority" 3 = Red and 4 = Green, etc, but I don't know enough to access these commands directly. Just wanting to set the thing to Red or Green depending on the state of my alarm system (variable).

Yes, assuming manual Zwave commands were around in 7.1 (which I’m pretty sure they were), that’s doable.

However colour commands aren’t in the scope of mental recall for those of us who speak Zwave - I don’t think any of the plugin devs have done much/anything with colours - so we’ll have to grab the commands and have you test them.

Me or another user will fire some at you later depending what time it is where they are.

Peter


Sent from my iPhone using Tapatalk Pro

[matt (support)]

I'll look into Indigo's code later to see if I can pull out the byte sequence needed for the raw commands. That said, the easiest solution here by far is to get the Indigo up-to-date subscription. That funds new development of Indigo, including supporting the latest macOS releases and new hardware support like RGB Z-Wave bulbs.

Thanks in advance for the help! Very appreciated.

Matt - I've probably paid you $400-$500 already for Indigo and a few updates over the years...it's impossible to justify another $250 just to add support for a few devices that I currently don't own (and then have to rewrite my AppleScripts in Python), and what...a nicer interface for plugins or Triggers? Nothing earth-shattering in these last few updates, with all due respect. If I can't use Catalina I'll stick with Mojave. I'll buy devices that ARE supported by 7.1. No big deal. I'm sure for lots of existing long-time users like myself, 7.1 meets my needs just fine, with a few very minor inconveniences. Obviously you switched the pricing structure to (try to) make more money, which is certainly your right, but I'm sure I'm not alone in saying that the new subscription route is not a good solution for me and I'm sure a good percentage of other users. I doubt many applauded the change. So rather than happily paying you something manageable/reasonable like $89 for a periodic upgrade when *I* decide I want or need the new features like I (repeatedly) used to, I'll now just hunker down and "make do" until I absolutely am forced to upgrade. Indefinitely "subscribing" to (maybe) get future updates (what, 3 minor version updates in the last 2 years since you changed the model?) that I don't even know if I'll want or need makes ZERO sense to me. With all due respect.

Anyway I appreciate the help again...for now I'm just turning the bulb on and off to indicate status rather than changing the color, which more or less works fine. It would be nice to be able to do the colors if it's doable, of course. And hopefully I didn't just burn the free support bridge.

Hi

Notwithstanding any discussions about upgrading...

Give these commands a try:

Red
0x33 0x05 0x05 0x00 0x00 0x01 0x00 0x02 0xFF 0x03 0x00 0x04 0x00

Green
0x33 0x05 0x05 0x00 0x00 0x01 0x00 0x02 0x00 0x03 0xFF 0x04 0x00

Blue
0x33 0x05 0x05 0x00 0x00 0x01 0x00 0x02 0x00 0x03 0x00 0x04 0xFF

Any colour
0x33 0x05 0x05 0x00 0xaa 0x01 0xbb 0x02 0xcc 0x03 0xdd 0x04 0xee where:
aa is how much warm white (between 00 (zero) and ff (100%))
bb is how much cool white (between 00 (zero) and ff (100%))
cc is how much red (between 00 (zero) and ff (100%))
dd is how much green (between 00 (zero) and ff (100%))
ee is how much blue (between 00 (zero) and ff (100%))

Peter

Peter, thanks for the assistance. Unfortunately those don't seem to work. I'm turning the light on and then sending the raw z-wave command to the light. I'm not seeing any errors in the log but nothing is changing color-wise. Even tried to set the "cool white" to FF with no change (it just stays at its default warm white color). Any other suggestions?

From the log:

Z-Wave sent "Alarm Indicator Light" on
Z-Wave sent "Alarm Indicator Light" raw command [03 05 05 00 00 01 00 02 00 03 00 04 FF]


If it helps here's the properties:

Z-Wave Indigo Device "Alarm Indicator Light" Z-Wave Properties:
Indigo Z-Wave Version: 2.0.111
Node ID: 53
Model: Dimmable Power Switch
Model ID: 00050001
Manufacturer: Unknown
Manufacturer ID: 031E
Protocol Version: 4.38
Application Version: 2.28
Model Definition Version: 0
Library Type: 3
Class Name: Dimmable Power Switch
Class Hierarchy: 04 : 11 : 01
Command Class Base: 26
Command Versions: 20v1 33v1 85v1 86v1 27v1 70v1 72v1 73v1 98v1 59v1 5Av1 26v2 7Av1 5Ev1
Encryption Status: Supported but not Enabled
Multi-Endpoint Types: - none -
Multi-Endpoint Classes: - none -
Multi-Instance Counts: - none -
Features: routing, beaming, security
Neighbors: 3, 6, 13, 15, 19, 28, 29, 33, 35
Associations: 1:[1]
Config Values: - none -

[matt (support)]

... just to add support for a few devices that I currently don't own (and then have to rewrite my AppleScripts in Python), and what...a nicer interface for plugins or Triggers? Nothing earth-shattering in these last few updates, with all due respect.

While of course I cannot argue if the cost of an Indigo subscription is worth it for you personally and your needs, I would like to point out the list of features included in Indigo 7.2, version 7.3, and version 7.4. If you scroll through those threads I think you'll find it is far more than support for a few new devices (well over a hundred), including one you now have. There are dozens of other new features (not related to new hardware) as well.

As to the raw commands, it looks like Peter's list just has a typo on the first byte for all the commands. Instead of "0x3" try using "0x33".

As to the raw commands, it looks like Peter's list just has a typo on the first byte for all the commands. Instead of "0x3" try using "0x33".

Oops...

Fixed above for future readers.

Aha, that fixed it, thank you again!

Matt not to beat a dead horse but I've reviewed the features list for all three recent updates and there is nothing in there remotely worth $250. Aside from conditional actions in Triggers, which might be useful (but sounds like it just saves me from having to create two separate Triggers with unique conditions is all), it's a lot of cleanup and polish but definitely nothing as I said earth-shattering -- precisely what you'd expect from a series of minor 7.x updates. Yes a ton of new devices are supported, but again it's not worth paying $250 to support an $18 bulb when I can buy a 7.1-supported bulb for $30 and be done with it (or learn how to send a raw z-wave command as we've done here). I haven't reviewed the list of supported devices to see if there's any in there that add amazing new functionality that old devices didn't offer, but it doesn't seem like it. Existing users already own most or all of the devices they need, so unlike brand new users, a huge increase in supported devices isn't really compelling.

So your proposal is that I pay $250 now to gain a few minor features or a supported device or two that I care about, and then *hope* that version 8.0 comes out with some actual meat on the bone, within a year, otherwise I have to pay again, and then hope again that I get my money's worth the following year, and just keep "paying and hoping" indefinitely. Makes NO sense compared to the old model where I could freely assess the value proposition BEFORE I paid. Subscription models work for things like anti-virus where you NEED the updates, or things like Photoshop where you can buy otherwise very expensive software for a small monthly fee, but for your software, it's most definitely not the right model. Just my opinion. But I'll bet you $250 that if you let your users vote which model they prefer, the old one would win by wide margin, especially now that it's been a couple years with only 3 or 4 minor-version updates.

Anyway thank you again for the assistance, and for the respectful consideration...perhaps if enough users echo my sentiments, we'll see a change back to a more sensible pricing structure.

[matt (support)]

It doesn't look like the value is there for you, which is fine.

While a subscription model is not what you want, it is the model Indigo will have going forward and we've had the model long enough to see that it is a success. A vast majority of our users haven't had an issue paying $59.95 / year to get updated versions that give them new feature releases (including tons of new hardware support and other minor and major features), reflector access, and macOS compatibility with the most recent Apple versions. Note that maintaining macOS compatibility is a huge feature, both for customers and for our development costs.

Some folks don't like subscription models, which is why we decided on a hybrid model that allows folks to continue running their last eligible feature release version indefinitely. In that case they have to buy a new license to get back into the upgrade loop, which is what you are opting to do if the value proposition is ever there for you again.