Firmware v1.57 (Production) | LZW31-SN | Dimmer - Red Series (Gen 2)

I don’t remember which version that was adjusted in, but as @Bry mentioned, in 1.61 you can increase the minimum value past 45.

Thanks. It looks like home assistant/zwave js validates it, so it won’t let me set it above 45. I might try and see if they can fix that.

Shoot, yeah, it is something that got added in 1.61 I believe. If there is a way to force a value (maybe with the zwave js user interface) you might be able to try that.

The zwave JS UI worked. Thanks. Also, there is a pull request here to adjust the parameter too: LZW31-SN -allow higher minimum dim level up to 98 for FW 1.57+ by kreene1987 · Pull Request #5181 · zwave-js/node-zwave-js · GitHub

1 Like

image

This isn’t a huge deal but came across this when trying to make my Blue Series switch behave similar to my red series.

I’m trying to set the min dim setting on my lights so everything works correctly.

I’m finding that ‘Set Level’ value is not the same as the ‘Minimum Level’ for Dimming aka Parameter 5

I can go into the device settings page and manually ‘Set Level’, to 20. I can turn the turn off, and back on and everything works OK.
image

If I set parameter number #5 to 20. Dim the lights up, then back down the lights are much dimmer. If I turn the switch off, then back on the lights won’t actually turn on.

image

Set Level at 20 is the SAME/SIMILAR as Minimum Level 35.

If I Set Level to 35, the lights aren’t that ‘dim’

Anyone else notice this?

Hope that makes sense

This is something unique about LED bulbs that makes the minimum level a little tricky. Every bulb is a little different in this regard, but when the bulbs go from an OFF state to an ON state they have to be dimmed up to a certain (usually higher) level just to turn ON. Then, you can usually dim them down 10-15% and make them dimmer. I’ve had to set the minimum brightness to the higher level so that they don’t get in a state where the hub thinks they are on, but they actually are not.

1 Like

I’ve seen posts and have figured this out from playing around. My comment regarding this was to state that I used the ‘Set Level’ to figure out the lowest % the LED will accept to actually turn on from a off state.

Now that I know the lowest % value, I don’t see why I shouldn’t be able to use that for parameter 5 ‘Minimum Level’

The issue is the ‘Set Level’ in the driver and ‘Minimum Level’ (Parameter 5) values don’t seem to be functioning the same. They seem to be scaled differently.

Looking forward to your response.

Is this with the Blue Series?

I was talking about my Red Series.

Since you asked I just checked my Blue Series

Looks like my blue series is doing something similar.

On the Blue Series-

I have the ‘Minimum Level’ set to

image

If I SET the ‘Set Level’ to 10, I then can use the local switch to dim lower than that.

That doesn’t make sense to me!

image

Ok, yeah, that makes sense. That is because the switch will always be able to change level from 1-100 (99 for z-wave). If you change the minimum or maximum level, the switch just scales the new range across the numbers 1-100. So if you set the minimum to 10 and the maximum to 90 the switch scales the new range across the values of 1-100. The equation is something like this:

((max-min) * x/100) + min

x is the value you have chosen from 1-100. So after you change the max and min (as stated above), if you set the level to 5, the value in the switch will actually be:

((90-10) * 5/100) + 10 = 14 The app will say the switch is at 5%, but internally the switch is actually at 14% (above the minimum)

If you set it to 33%:

((90-10) * 33/100) + 10 = 36 The app says 33% but internally the switch is at 36%

If you set it to 100%:

((90-10) * 100/100) + 10 = 90 The app says 100% but internally it is at 90 (the maximum that you have set)

Hopefully that makes sense.

2 Likes

Can I make a simple quality of life suggestion? Name your firmware files with the target in the name.

Example: LZW31-SN_1.57 (target 0).otz and LZW31-SN_1.45 (target 1).bin

My simple brain has to triple check each time I go to update it.

3 Likes

@EricM_Inovelli if a new firmware version is released could more scene control be added to the config button? It would be nice to be able to use 2, 3, 4, and 5 config button presses as triggers to control scenes rather than only being able to use the current single config button press. From what I read in the Red 2 and 1 thread the config button will have the 1-5 button press triggers as well as hold and release. I plan on getting a couple of them to replace some other switches I have but would like to avoid paying to replace the Red Dimmers I have with the Red 2 in 1 just for the multiple config button triggers.

I’m not sure if this will be possible. For one, the manufacturer has cut ties with Inovelli and is no longer entertaining firmware updates or manufacturing new units. Also, I believe the Lee is no more room on the LZW31-SN MCU for any new features. They would have to remove some of the other features in order to fit new features in it.

I only foresee replacing the older gen 2 reds with the upcoming Red 2-1 dimmer.

Can we get this updated in Home Assistant? GitHub - zwave-js/firmware-updates: The firmware update service for Z-Wave JS at https://firmware.zwave-js.io doesn’t have this listed, and I have switches stuck on 1.35.

We’re waiting on this issue to be resolved: Restore Inovelli LZW31-SN (draft until multi-target updates are fixed) by AlCalzone · Pull Request #39 · zwave-js/firmware-updates · GitHub

Looks like they still aren’t in Z-Wave JS, which is annoying but not completely Inovelli’s fault. Looks like they Z-Wave JS folks won’t add it back until they get them a physical switch and UPS made that hard.

But I’m having issues getting the firmware from Github. When I download them from HERE they don’t pass my MD5 checksum.

certutil -hashfile .\LZW31-SN_1.57.otz MD5
MD5 hash of .\LZW31-SN_1.57.otz:
469099e640a2f4aee4bc8ff5a611d6b0

MD5 from the repo:
7ee1e4cd015f8669ff1c50a0da2caf92

@EricM_Inovelli @Eric_Inovelli can we get the GitRepo fixed or get the files somewhere with verified hashes? I’m still not having any luck downloading firmware from the Git.

Name: LZW31-SN_1.57.otz
Date: 9/19/2023
Size: 271 KB (277,850 bytes)

SHA-1: 6c0e6deeb0e6d080d841ec98089dd3141da1d2fa
MD5: d80cd2d07a675e0947b4e71c4a5206b7
CRC32: c15363e2

MD5 from verification file: 7ee1e4cd015f8669ff1c50a0da2caf92

2 Likes

https://files.inovelli.com/firmware/LZW31-SN/1.57/

I downloaded https://files.inovelli.com/firmware/LZW31-SN/1.57/LZW31-SN_1.57.otz and it matched the md5sum txt file

2 Likes

Yep, I think the Github version is hosed. I hashed the Github version and got the same MD-5 and SHA1 that @nfwolfpryde got, which do not match the published values. I hashed the files.inovelli.com version and got the proper hashes just as @stu1811 did.

So go get it from the location @stu1811 posted.

@EricM_Inovelli

2 Likes

Thanks guys. I replaced the file and the md5 seems to be checking ok now. I’m not a fan of how files are treated in github when we are wanting them to just be downloadable. Is there a different way to do it? Like, when I click on the file name it displays the contents of the file and then I right click on “raw” to download the file. Is there a way to make it just download the file in the first place instead of having it display the contents?