Min / Max Dim Level logic

@Eric_Inovelli Thanks Inovelli team for all the great work. Question on the minimum and maximum dimming parameters. This is going to sound confusing but here goes… It could be a bug… Maybe.

Using supported Philips Par20 bulbs I have found no visible difference in brightness beyond about 60-65%. So my assumption is that setting my maximum level (parameter 10) to 65% should help improve dimming function.

Based on feedback from an earlier thread, I believe this should result in the new 100% being equivalent to what was 65%. However, the new 100% is visibly dimmer than that. To validate, I then restored parameter 10 to 100%., and dimmed the bulbs down to 65%. This should result in no change to brightness as I understand it, but it actually results in the bulbs going brighter - which shouldn’t happen because the bulbs should have already been at their visible maximum.

Nudge. Thanks in advance.

@Eric_Inovelli @Eric_Inovelli

I think we’d need to see voltage readings or something to validate what you are seeing, but you are correct in your understanding that setting max at 65% means that 65% is the new 100%.

I don’t have an easy way to do this. But optically it’s very apparent to me that this isn’t happening. There must be some other logic that is being employed by the switch.

Noted. I’ll see if I see the same thing once I get my test setup back up and running.

Ty… Any luck with this?

It seems I am seeing the same on my end as well. Seeing different voltages on load side with 65% vs max leve 65% and setting to 100%.

Thanks for bringing this to our attention!

This was reported in github and will supposedly be fixed by the engineer in the next release of firmware

1 Like

Excellent. I think once this is fixed the min and max level customization will be very handy to have.

@kreene1987 Just wondering, is this still in the works?

It is my understanding that Inovelli has alpha firmware to test. It should be included in the forthcoming 2.10 firmware (within a week or so).

2 Likes

I accidentally updated to 2.10 and it has some weird dimming behavior with zigbee binding two switches. I mentioned it on the firmware changelog forum. It broke dimming speeds and dimming being synced while using Zigbee Binding. If you use two switches with Zigbee Binding, I’d hold off upgrading…

You had to press the button twice…

3 Likes

And with this message in the log

2 Likes

I use a manager to update the switches that I made myself.
What’s bad is that you never know if you’re getting a production firmware or an alpha firmware.
It just does what it wants to do. It should ask if you want to continue and what the latest version is.
Right now with default Hubitat behavior, it doesn’t do any of this. You have no idea what it’s going to update to until it actually starts updating.

Also - that link shows no changelog for v2.10. It doesn’t even mention it so the message is useless. I actually went to that link, found that v2.08 was the latest and attempted a firmware update just to check. Found out v2.10 was the latest and it was too late.

I understand the frustration and am sorry this has happened to you. We are in the process of trying to find an alternative method of testing firmware. It isn’t easy for any of our major platforms to do individual firmware updates with Zigbee. At least with Z-Wave there are a few tools out there that the user can use to update at their own will. With Zigbee it is an all or nothing approach right now unfortunately.

1 Like

No worries. I was able to revert the firmware using a firmware manager I have created myself.
Just had to add a little “exploit” to get around Hubitat’s signing requirement / pulling from their server.

Now it shows:
“Proc: Beta”
“CurrentVersion: v2.10”
“LatestAvailable: v2.10”
“ExecutionAction: Downgrade”
"DownloadPkgOTA: “https://files.inovelli.com/firmware/VZM31-SN/Beta/2.08/VZM31-SN_2.08.ota

After some fun minutes later it was reverted to v2.08. :slight_smile:

2 Likes