It seems that I can reproduce the issue. If I disable the local relay (config x8) and then enable ‘smart bulb mode’ the switch will start a boot loop. The only way I can recover is to hook up the switch to an alternate power source and factory reset. Not sure if @wogfun had similar settings (disabled local relay and smart bulb mode toggled on in a non-neutral set up)?
I disagree. A zwave dimmer switch should always “know” the current state of all its settings, including dimming level.
I think this discussion got a little side-tracked. There should be no debate about whether the device knows this or not because I believe its a zwave requirement and I doubt it would pass zwave certification if it didn’t do it. The debate is about the value that will be stored/reported when the dimmer is set for SBM and locks the physical load at 100%. Many of us believe the internally stored SetLevel() value should still follow the requested dimming range (either locally or remotely) even though the physical load terminal is being locked at 100%. This is currently how it behaves without SBM and we think there should be no change to this behaviour even whan SBM is enabled. The only change that SBM should do is lock the physical load terminal at 100%. Everything else should work the same as before, including the appearance (LED Bar status and internal dimming level) of dimming.
1 Like
First time using the dimmer as a regular dimmer. (I’ve used the dimmer as a smart bulb controller.)
When I dim up or down (at the physical device or via Z-Wave) there is a very slight stutter in the lights during the ramp. Other dimmers do not exhibit this behavior. Is this expected behavior?
Also, I had the inability to control the device, both physical and via Z-Wave, after updating from 1.35, similar to one of the above posts. I was able to regain control by changing a parameter, but I don’t remember which one
I believe he is saying there is a delay from when you hold down the paddle with the intention of dimming up or down there is a noticeable delay before it starts dimming. I don’t mean to speak on his behalf, but I’m seeing the same thing.
I think we were expecting that the new parameter which allows us to configure the “Button Press Delay” would also apply to the delay before dimming. Basically, one timer that is used to determine if the switch is “pushed” or “held”. That appears to not be the case. The hold-delay for dimming seems to still be very similar to the old delay (around 700ms) even with the new firmware and the delay set lower
@Eric_Inovelli @EricM_Inovelli Please do you guys expect to have a firmware with a configurable delay for the on/offs soon?
Thanks!
Yeah, we’re working on it – we’re trying to get the Dimmers correct before implementing the same/similar changes to the On/Off’s.
It’s also Chinese New Year so the manufacturer won’t be back in the office until the 18th 
Thanks for the response… Wasn’t sure if you already had a file somewhere that just needed to be discovered like the 1.52 file :)… Would wait for it then!
Also, please are you clear on the hold delay now?
Thanks!
Got it – ok, yes this is clear now. I guess I just never noticed this honestly (or just got used to it), but I see what you’re talking about.
I’ll have to figure out a way to better explain this across the language barrier, but the good news is at least I understand what the feature you’re asking for is.
Got it, makes sense – thank you!
Yes – thanks for your patience 
4 Likes
Just upgraded to this firmware, verifying all the functionality. Right away I notice something odd with Parameter 3 (how fast or slow the light goes from on to off to on). No matter what I set this to (Tried as high as 10 seconds) the light (incandescent dumb load) goes inconstantly on and off from the switch paddle.
Can anyone else confirm this?
Smart bulb mode enabled?
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.
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