Firmware v1.52 (Beta) | LZW31-SN | Dimmer - Red Series (Gen 2)

No, I should have been clearer (I thought by saying incandescent bulb it would imply not using SBM).

But since you mentioned it, I went and read parameter 52… it was set to decimal 128? I set it to 0 and it still had no effect on my issue.

I figured it out and have come to the conclusion that this firmware version is a hot mess.

Observation: many of the parameters were not at their defaults, as per Inovelli documentation. In one example parameter 52 was set to 128. Parameter 21 was set to 0 instead of the default 1 (and no, I’ve never had a non-neutral setting for this dimmer). There are many other examples where I had to change the settings when I shouldn’t had to.

Parameter 3 no longer controls local Ramp Rate (as per documentation)… it’s now Parameter 4 which is suppose to control the Z-wave Ramp Rate.

Is there no QA checks on this stuff?

See above.

1 Like

If it took me less than 30 minutes, as the customer, to find basic stuff like this out, why couldn’t have anyone at the company done the same?

I’ve been in the technology business for over four decades now… when a company releases a beta it means they’ve done the basic QA and then are relying on the community to uncover the edge-cases, since every possible system combination can’t be covered (at a reasonable cost/time period).

Because there’s 7 of us dude. Stretched to the max on bandwidth and only one of us who understands firmware. Our manufacturer “owns” the source code so we can’t test it 100% ourselves and that’s why we rely on the community. Thank you for determining our firmware is absolute crap, I’ll relay that onto the manufacturer.

We put these out and try our best to help make things better for you and anyone else who asks for these random requests bc we believe in making the best we can and try to help out as many as possible. I know that’s a subject you don’t agree with per your other post, but it’s how we choose to run the company.

Do I personally think that the 700ms “delay” is a problem for mass market? No, not at all. We’ve sold over 100k switches and there’s been very little who have said anything about it. But if we can fix it and help out @gbenrus25 and others who think it is – then so be it.

Do I personally think, “smart bulb mode” is a problem? Again, no not at all as you can see post after post on Reddit, Facebook, etc recommending us to use with their smart bulbs. But yourself, and others wanted to better optimize it and so here we are trying our best to do so.

So rather than being condescending and trying to crap all over us, maybe take a moment to understand where we’re coming from and that’s a place of we’re trying our best.

In fact, I was about to ask for your input on 1.53 as I was pretty excited about working with you to make sure we get everything correct for our production version (not these alternate one-offs), but tbh, I really don’t feel like being crapped on and neither does the team that’s working hard on trying to fix these enhancements.

Congrats on being in the industry for so long, if you can point me in the direction of another company we can emulate that listens to their customers and works to get their firmware out quickly and accurately, I’d love to know.

19 Likes

And I just finished updating all of mine to 1.52… can you guys please stop working on the weekends and slow down. :slight_smile:

Looking forward to the updates. The instant on was a big hit in my household.

1 Like

Eric,

I’m not talking about whether a delay should be 700ms, whether SBM should work this way or that way, etc… it can be debated that some of those issues are subjective.

I’m talking about a very basic business process, something objective. The firmware literally does not match your product documentation anymore. I’m not talking about new features. No one had 30 minutes of someone’s time to do a quick check on the basics?

To your point, I’ve worked in every size company, including startups where I was one of the first handful of people hired. And yeah, we worked around the clock to build something we believed in… but we always tried to make sure we got the business basics right.

My apologies if I offended you, it is never my desire to inflict harm onto anyone.

Fantastic – thanks for clarifying.

No, honestly – no one has/had the time to double-check this. I guess we made the assumption (falsely) that default parameters from the prior versions would match these new defaults. I’m thankful to you and whomever else pointed this out as now we can talk to the manufacturer and say, “hey, why in the world would you change the defaults?”

Just to give a bit of background – apologies if I/we weren’t clear enough when first posting this.

  • @EricM_Inovelli is the only person that understands how firmware works. Yes, it may be a weakness of ours right now, but it is what it is until we can afford to staff up. We made the choice to put it to the community to check the new firmware vs us doing it internally as Eric had many other fires to put out (ie: building device handers/drivers for hubitat/ST for our lightstrip, working with a large alarm company to figure out why our products were not working with their alarm platform, etc etc – so many other main priorities).
  • Choice A was to wait until he had bandwidth to thoroughly check the firmware to make sure everything ticked and tocked whereas Choice B was to rely on the community to do this for us as it would’ve been probably a month or so before he could get to it.
  • We choice Choice B as you guys are incredible at picking apart the firmware and quite frankly have more time than us.

Our hopes were that since the manufacturer is building off of prior firmware, they would’ve have completely messed up anything.

As noted in other posts, there’s an internal battle over the source code (our contract says we own it, they claim otherwise) so we can’t get a hold of the source code to modify anything right now. If we had the source code, I’m confident Eric M would have fixed everything and had it to everyone correctly the first time. But, unfortunately, we have to choose our battles.

Anyway, the goal of these beta firmwares is to figure out any bugs and again, rather than waiting a month or so for Eric M to manually check them, he posts them to the community for feedback. 9/10 it’s good feedback. But it appears this time is an exception and I’m thankful you pointed it out (albeit offensively, but it appears you didn’t mean to offend, so none taken).

That’s fantastic, we’re always looking to improve. I’d love for you to PM me if you find ways we can make things better. We’re trying our best.

4 Likes

I’m happy to hear that, as a consumer I really want you folks to succeed. And there is something I’ve been meaning to ask you regarding your business model, but it’s best not discussed in public. I’ll write something up later.

I for one am fine with this model especially if it means faster beta releases. The way I see it, this is an alternate firmware and there’s a risk of issues in it (even “basic” issues). It’s not the production firmware. As such, since you guys are swamped, please push these releases out and let us dig into it. Each person can decide for themselves whether they want to install it or not or stay with the production release.

I’d just add that it’s probably helpful to make it clear when testing hasn’t been done (as it was made clear in this instance) so each person can properly assess the risk and decide if they want to be the alpha/beta testers.

2 Likes

I think you guys are doing a pretty awesome job as is, putting out beta firmware, soliciting feedback on a variety of topics, being probably one of the most transparent companies out there and making great and unique products to boot, all with an incredibly small team.

Also good to note and I think Eric kind of alludes to this, but I suspect there is a small minority of customers that are a part of this community, and an even smaller number who actively posting and providing feedback. So good to remember that there are thousands of other customers out there who are perfectly happy with the current state of things. They are still going out of their way to even improve things for the vocal minority and not just raking in the cash with the current functionality.

6 Likes

No other company goes after customer requests, and no other company is as accommodating nor feature rich as your company’s. Inovelli is hands down the best dimmer:toggle switch around. Thank you for all your hard work, and try not to be discouraged by those with a lack of programming comprehension or compassion. It is one thing to be frustrated, it is another to belittle you and try hold you to some imaginary standard that your company already exceeds at.

3 Likes

Thanks for the Beta! It fixed a problem I was having with my non-neutral setup. Keep up the good work guys. I’ve never owned a product where I could communicate so easily with the team behind it.

5 Likes

As someone who’s also been in tech my whole career, I find Inovelli’s transparency, openness (about products, plans, and their business situation), and unrestricted communication most refreshing. Unlike most companies, Inovelli truly partners with their customers to develop the very best products for their market segment. THAT is why Inovelli products are at the level they are at- Inovelli never has to guess what customers want.

As far as I’ve seen Inovelli has NEVER mislead users or misrepresented a product. Sometimes their stuff is great, sometimes it needs work, but they have never (that I’ve seen) said ‘trust us this works great!’ when it’s obviously crap.

That is especially true here. They got the firmware from their manufacturer, and posted it CLEARLY with a ‘we haven’t tested this much’ warning so you can make your own INFORMED choice whether to try it or not.

If you are unhappy with the new beta, you can always downgrade to the previous beta or the last Z-Wave Alliance approved release, 1.47.
But don’t crap on them for putting out a beta with bugs that is clearly labelled as possibly having bugs.

10 Likes

@Eric_Inovelli as others have said, keep doing what your doing and let people make their own informed, or uninformed decisions on what they want to load on their devices.

7 Likes

Whoa. Someone literally took beta firmware issued without much testing (CLEARLY stated) and complained. Now I have seen everything.

Inovelli has done so much for us, that I love this sort of thing where we can give back. I haven’t gotten around to installing the firmware yet, but giving this a solid month or so testing period where we can put it through it’s paces in a test/not important area is fantastic.

Please don’t stop this, let us as a community help you guys out. If something catastrophic happens, you will support us (no question!) but we are definitely here to help and actually ENJOY this.

Beta means beta, I get it. I love it. Keep being amazing Inovelli.

9 Likes

I agree 100% :+1:

This was clearly identified as BETA and I appreciate the opportunity to test it out myself and provide feedback to the manufacturer.

INOVELLI: keep doing what you’re doing. :v:

3 Likes

I don’t understand your negativity towards Inovelli about this. They clearly announced it as un-tested beta firmware and asked us to try it out for the purposes of finding bugs like this.

I normally have all my dimmer on/off Ramp rates (not dimming rates) set to 0. So I did not notice anything odd with Ramping when I started testing v1.52. Since you’ve brought it up, I did some quick tests with ramping and it appears to be working correctly as far as I can tell.

It looks to me like you have Parameter #3 and #4 backwards. #3 is Ramp rate when receiving on/off commands via Zwave. #4 is Ramp rate when using on/off locally at the switch paddle. If you only set #3 then that ramp rate only applies to zwave on/off not local paddle on/off. You need to set parameter #4 to change the local paddle on/off ramp rate. I tried both #3 and #4 and they seem to be working correctly for me.

1 Like

I just tested it also and Parameters 3 and 4 work as expected. Like @mamber said, parameter 3 is for zwave ramp rates while parameter 4 is for local ramp rate. I recognize that the manual is wrong but in the driver, it clearly has them labeled correctly (Parameter 4 is called Ramp Rate (From Switch)).
@Eric_Inovelli just as a heads up, parameters 3 and 4 are switched in the manual.

Also, I’ve updated all my dimmers to this firmware and they have retained parameter 21 correctly. Maybe your parameter 21 was set incorrectly before this driver? Parameter 52 had issues in this driver (and the previous one I believe) and if you read earlier comments, you’d see that EricM suggested toggling it on and off.

Just as a FYI, you’ve now chosen to bash them twice. On this thread, your issues had either already been reported or was due to an incorrect manual and you not reading the clear descriptions on the page where you update the parameters. On the other thread, you didn’t understand how they don’t “get” it even though unknown to you, they had implemented almost all of what you said they didn’t “get” (and the main poster even had said this much).

Ultimately, it’d help if you choose not to flame so quickly (or even at all). The Inovelli team is clearly working hard and going the extra mile for us so please let’s be grateful for such great CS rather than flaming!

Hello fellow v1.52 testers. I’ve been struggling with an issue of Hubitat scenes not completely running correctly where devices are “forgotten” or sent the incorrect values. While I do not expect this to be isolated to ZWave devices I want to inquire here to see if anyone has experienced anything like this since moving to v1.52 anywhere in their meshes? The only ZWave devices that seem to struggle are LZW31-SN dimmers which have the 1.52 firmware installed.

Again I doubt that this is the issue but at this point my broken scenes experience is so frustrating and mysterious that I am turning over every rock to at least eliminate possibilities as I move forward. The problems for me began when I migrated from a C-3 hub to a C-7 hub. At that time I also was upgraded to the 2.2.5 branch of the Hubitat OS. Then I started flashing 1.52 firmware to my dimmers but stopped when I experienced these mysterious forgotten devices and incorrect values.

So anyone seeing anything like this?

Original thread from the Hubitat forums where I first documented the problem:

https://community.hubitat.com/t/2-2-4-147-broke-scenes/56833/31?u=r.p.ulivella