Just installed the LZW36.
Disappointed with the response time on a physical button press to turn on the light. About a 1 second delay which is unacceptable.
Ramp and dimmer times all zeroed and confirmed, the default dim rate or ramp configuration is silly BTW.
It turns on instantly if I command it from Home Assistant, as in before my mouse button unclicks the light is on, this is nice. So I know it’s capable, can we get the physical button to work the same way?
Will there be a FW update to resolve this?
I’d sure hope so with the positive reaction they have seen with the switches/dimmers via firmware update!
Dang, one day we’ll get our act together, I suppose! Kidding, I just get salty bc we pour our heart into these products and it strikes a nerve sometimes. I’ll get over it lol.
We’ll definitely look into this. As with the dimmers and on/offs, there is a slight delay built in to accommodate for the scenes, but as we worked with you guys to provide an alternate version, we can look to optimize this one as well. Luckily this time we have more room to work with as the 700 series has more memory.
As for a timeline, we want to make sure we get all feedback in from a firmware side before making an official version as it actually costs us minimum $2k from the Z-Wave Alliance each time we update the firmware.
We can certainly put out a beta version though. I’ll check with @EricM_Inovelli to see if he can rally the engineer to work on this.
1 Like
Perpetual beta would be fine for me. If this gets resolved I’ll purchase a second one for another room.
If this helps for prioritizing your product requirements:
As a user, I expect smart switches to behave like a normal switch when physically actuated, this would include perceived response time.
There are probably technical reasons this can’t be identical, that is fine, its just perception we’re dealing with but 1s is well out of range of being imperceptible. I like to use the “by the time I lift my finger off the button” metric as a target for acceptable response. Sampling the time for leading and trailing edge for typical button presses from users should provide some sense of an acceptable time target.
Got it, thanks!
By definition it literally can’t, because it has to wait until the button is RELEASED then start a timer to see if the button is pressed again for scene control (multi-tap control), which is one of the largest featuresets touted with this product and is widely used by myself and others. IF they were to control based on the pressed action (not released) to mimic a dumb switch then there would be zero capability for scene control.
They have worked around this in firmware updates on the dimmers/switches by eliminating scene control (except for button 1 (push/held) and button 7 (config) along with 6 and 8 (hold up/hold down). On the switches/dimmers, they give the user the option to eliminate the waiting period (700ms or so) but forego the scene controls. I believe they can/should do the same here.
Next level of control would be the delay allowed (in ms) to allow both a response time that is good and full scene control. Think of this like double click speed in windows with the bar.
Hopefully my explanation makes sense that unless you cut this product at the knees for smarthome control, you won’t get your desired result with this product.
2 Likes
Just to add to @kreene1987’s response …
When you use the software to control the output, you skip all the local processing that has to decide which “virtual button” within the physical switch you intended to activate, hence it can process the command instantly.
So, for example … you decide to program a double tap of the button to turn on the lights in your kitchen, and triple tap to turn on your porch lights (“scene control”). The switch can’t react to the single tap until it decides that’s what you actually want it to do which requires the delay. As it was stated, if Inovelli adds the ability to disable scene control in a future firmware update, your expectation could be realized … however, that goes against the design premise of the switch, and it makes sense that there was no call to include it in the initial product release.
Ok, that sounds like the revision that needs to be made and this has been done on their other products, so that’s good.
The constraints are all understandable, but they should be balanced against maintaining an acceptable (doesn’t need to be perfect) level of fundamental function, i.e. it’s a lightswitch first and foremost and 700ms is just too much. I’d be happy to have this as a user accessible parameter.
This is the only fan/light Zwave single gang switch option on the market that doesn’t look hideous (it basically looks like a Lutron) and is easily understandable to use by guests, that’s the primary reason I purchased it. The scene features are nice, but seem like feature bloat to me. I’d be happy if I could turn them off to get the benefit of response time.
2 Likes
I think a “dumb switch” mode would be easy to do. Just disable multipress actions for people that want instant press and don’t use scenes. I love what these guys are doing with their switches and will continue to support them. I personally don’t use scenes much and would prefer a better response time myself.
2 Likes
I just installed FW v1.36, thanks for making that happen.
I realized I didn’t set parameter 51 to zero using Z-Wave PC controller before installing my Z-wave stick back in my Unraid box/Docker/Home Assistant setup and then realizing in HA Z-wave config parameter 51 doesn’t show up as an option to configure (probably a z-wave config xml update to achieve this).
However, before I swapped the stick back to my PC to configure parameter 51 to one, I tried the switch anyway. The response was instantaneous, issue resolved! FW notes say default is param 51 = 0 which means 700ms delay, if that’s the case I don’t seem to be experiencing this.
Update: I decided to check the parameters with the Z-wave PC Controller out of curiosity. A few issues: the parameter list is so long that some are off screen and it’s not a scroll-able list. Luckily I can rotate my PC tablet into portrait mode. The default reported for param 51 was zero, however it wasn’t behaving this way (700ms delay). I attempted to switch it to 1 just to see what would happen and help diagnose whether the settings were flopped in the FW. I did that, reloaded the parameter list and it then reported some large number. I could not successfully reset it to 1 nor 0. Some of the other parameters looked weird too. The physical switch response still behaved the same (very fast now), so I just plugged my stick back into my HA box. I noticed all the parameters for LED intensity, ramp rates, everything were screwed up, so I reset them all through HA and all is well. Lesson: don’t set parameters with Z-Wave PC Control I suppose. Still have no idea why the default parameter 51 is “fast response”, that’s not expected, luckily that’s the setting I prefer.
I’m going to go ahead an purchase a 2nd LZW36 now that the physical switch response is resolved.
1 Like
I have also experienced this with my Inovelli switches. I love the design and the notification bar, but when I press them I have to watch them to make sure they are turning off as the delay is so long. I never have to look at regular switches, so I do understand how it could be marked as “unacceptable” by many users. Step one of making something smart is to ensure it behaves just like the dumb alternative when used by someone unfamiliar with it.
I find it most odd that my response times when pressing the button in my Hubitat dashboards are instantaneous (minus the speed of electricity and light), but when pressing the physical switch it takes almost or over a second.
Please don’t be discouraged by my observations! I love my switches!
I am using firmware 1.34 in my LWZ36 fan/lights. I’m not sure what software version of the Hubitat driver I’m using, but it says it was last updated 2021-03-12 4:21:08 PM EST. I too am noticing slow response time for the fan’s lights to come on from the switch. I set the physical ramp speed to 0, which cut it from about 2.5 to 1.5 seconds from its previous setting of 1 - which makes sense as I would expect going from 1 to 0 cut a second off. I set param 51, Disable Physical On/Off Delay, to Yes, but that didn’t seem to make any difference. Any ideas on how I can make the fan light come on almost instantaneously ala the Red dimmer, LZW31-SN?
@Eric_Inovelli
Thanks,
Stuart
Hey @skarden – try updating your switch to 1.36
On Hubitat, your device should say the following, “The 700ms delay that occurs after pressing the physical button to turn the switch on/off is removed. Consequently this also removes the following scenes: 2x, 3x, 4x, 5x tap. Still working are the 1x tap, held, released, and the level up/down scenes. (firmware 1.36+)” indicating 1.36 is needed here.
Set Parameter 51 to 0… boom.
Since I’m so new I haven’t done a firmware upgrade to any of my devices yet. I started at this page:
I saw the table for the Black and Red Series which said the latest OTZ is 1.48 and the BIN that goes with it is 1.47. But when I clicked on the link to take me to the Red Series, LZW31-SN, firmware, it took me here:
https://files.inovelli.com/firmware/LZW31-SN/
and there is no 1.47 BIN file. For 1.48 the BIN file is 1.41 and even for 1.53 Beta it is 1.43. I know that is for the Red Series and we are talking about the Fan/Light LZW36 here, but I don’t know what I can trust. It seems the chart on the Wiki page should be the official page with the correct version. If those numbers aren’t right I don’t know what else to trust about the instructions.
Plus, those instructions talk about having to do the update in 2 steps: step one is for the OTZ and then a second step for the BIN file. It also says the files should be downloaded first and I have to change the parameter to 0 for the OTZ file and then to set it to 1 for the BIN file. But then I found other instructions that seem like they are saying there is a new firmware install app that does it in one step and I just need the URL without having to set the parameter between 0 and 1. Here are links to what seems the newer version of the Z Wave Firmware Updater:
and
I’m also confused by the instructions for the “new” URL based version as it seems like there are 2 URLs, one for the OTZ and one for the BIN but neither of the above 2 links say to do one and then the other. The instructions just say:
Your screen will refresh and the box on the far right will say Update Firmware. In the firmwareUrl: box paste the URL you need from above (obtained in the “Firmware Location” section above). Once the URL is there, click the Gray Update Firmware box directly above the URL. The Current States section will begin to update and you will see a percentage indicator. It will say 100% complete when the device is done updating. We have seen the update process take somewhere between 3 and 40 minutes per unit. For better performance, update your device closer to the hub.
Step 10
Once the device has completed updating, change your Device Driver back to your old driver, click Save Device and you are all set! 
Enjoy your new firmware!
As you can see, those above instructions don’t say anywhere to then repeat pasting in the URL but with the other URL before changing the Device Driver back to the old driver. It only mentions pasting in the URL once.
Maybe that is obvious to you that this process is then repeated with the other URL, but I’ve never done this before, so nothing is “obvious” - especially when it warns I can brick my device if I do it wrong. So I don’t want to paste in 2 URLs and repeat when I shouldn’t and likewise don’t want to only paste in 1 URL if I should then repeat that step but with the other URL. I’m going literally step-by-step as to what it says to do and it doesn’t say to repeat with the other URL.
So, I’m happy to try it, but I still need some guidance.
BTW, am I correct that this means we do NOT use the Hubitat built in Device Firmware Updater and I don’t have to change the parameters for 0 and 1 like the first link I started with says in the official Knowledge Base? (here:)
Final question: I’m 99% sure I got the newest version of the Z-Wave Firmware Updater, but how can I be sure? The version said it was 1.00 at the top of the code when it was brought in, which seems wrong if there was a prior version.
Thanks,
Stuart
It’s been 4 days and @bcopeland hasn’t responded here. Can you contact him or help me some other way? My main questions are:
- How can I be sure I have the most current version of the Firmware Updater (they both seem to be version 1.00).
- Do I only have to run it once for each such device with the link for the most recent firmware?
Thanks,
Stuart
I sent him a message over on the Hubitat forums (he’s staff over there and I saw he posted recently).
I know only the C7 supports the built in firmware updater app, not sure if that’s the reason for the separate driver and documented approach or if both work for this if you have a C7 hub.
Edit, can use either tool if you have a C7 hub, otherwise just follow the documented procedure and driver here if you have an earlier hub -
Second edit, if you’re using the binary driver, that also only has a version 1.00 to my knowledge, so that’s the current version. It’s just a question of which you need to use. And I believe you just have to run it the one time to update to current.
I’m 99.9% sure I got the latest version as it was asking for the URL. For the Fan/Light I pasted in:
https://files.inovelli.com/firmware/LZW36/Beta/LZW36_1.36.gbl
When I clicked on the Update Firmware button just above where I pasted in the URL I saw the Current States change firmwareUpdateProgress to Please wake up sleepy device and lockedBy changed to This process (See screen shot below).
The light for the fan I was trying to upgrade was on, so I don’t know what they mean to wake up a sleepy device or how to do it. What do I do now?
Thanks,
Stuart
It looks like that’s happened before to others - [RELEASE] Z-Wave Firmware Updater - #114 by bcopeland - ⚙️ Custom Apps and Drivers - Hubitat
Solutions seems to vary between resetting the device by pulling the airgap, restarting the hub, and/or doing an exclude/reinclude before reattempting the update.