I am a developer and I don’t appreciate your sarcasm I understand what you are saying if the request comes frivolously from end-users that have no idea how to write microcode. However that is not the case here. I have a degree in Computer Engineering and I have coded many things including firmware for microcontrollers with much less memory than the 500 series chips in these devices. I stand by my statement that in this particular case, what we’re talking about is a very simple logic test and I even supplied the psuedo-code to support my statement.
I asked if there were other reasons for the restriction and none were given. The only reason provided was that there would be issues if Min was larger than Max
Yes I do mean well, I believe I was one of the first to start the discussion about the 700ms delay and offered several possible ways to improve that without adding too much complexity to the code or the user interface. Its taken many months, but we now have that feature and it seems to be highly desired now even though the initial reaction was that 700ms was “good enough” and didn’t need changing. I’m trained in six-sigma and always push for continuous improvement, and I’m intelligent enough to know if a request is too frivolous or going too far. I don’t believe that is the case here.
and unless you’ve worked with me before, you really don’t know what I do or don’t know how to implement. You’re making an assumption.
While I do not have access to inovelli’s source code, that doesn’t mean I don’t know what is an easy firmware logic test. I have coded firmware for other microcontrollers and I would love to get my hands on the Inovelli firmware source code and provide some of this coding myself. I’m not suggesting anything that I couldn’t do myself if I had the source code.
I think its unfortunate that this firmware is all being coded offshore by people who speak a different language. The logistics of this arrangement makes code changes slow and time consuming. The added hassle and cost of Z-wave re-certification with code changes make the overall process complex. But that doesn’t mean every code change itself is always complex or lengthy. In this case the code itself is easy but logistically more lengthy to implement.
If I recall correctly they are looking to bring firmware development in-house to simplify these changes in the future. That being said I think they also mentioned something about not getting the firmware for the current switches as part of the contract or something. I suspect @Eric_Inovelli might have some thoughts on that front.
Hmmm, I’ll challenge you on this point. I first requested a configurable delay in Nov 2019 … I won’t characterize the initial reaction as 700ms was “good enough”. Many others agreed and joined in the request. So some of us have been waiting for way longer than even you so are glad it’s finally here! Hehe!
Ahh yes, looking back I see you were the first … and I will concede that point
What I meant was the initial reaction from Inovelli was that 700ms delay was not noticeable to most people and those of us saying it was too slow were accused of being Super Human Mortal Combat players
The good news is that even though Inovelli initially thought it was fine at 700ms they still listened to us and continued in the discussion where any other manufacturer may have just ignored us. I admire and appreciate that Inovelli listens and asks questions of us.
Using Hubitat C7 I have problem updating the firmware of some LZW31-SN to 1.52. I was able to update the OTZ (took about one hour). But it always crashed in the middle of updating the BIN file. What is the impact of NOT having the BIN file at 1.43 when having the OTZ at 1.52 ?
WOW. It worked. As you said reboot did the trick. But I had 3 devices to update and I had to reboot between each of them… I don’t understand, but at least it worked.
Are you using the relatively new “Device Firmware Updater” App? Or are you using the legacy “Z-Wave Binary Updater” device driver?
I have not had a good sucess rate with the new App. I was seeing similar to your experience where the .otz would usually work (slow but works) and the .bin would always fail. I have a little better luck with the Device Driver method (need to change the switch device driver first, then update, then switch the driver back to the Inovelli driver).
Using LZW31-SN VERSION 1.52, i’m unable to have (stable)
Disable Physical On/Off Delay = YES and
Disable Local Control Disable ability to control switch from the wall = YES
It works some times and not the other time.
Edited: After many changing from Yes to NO and to Yes in the parameter, it SEEMS to work.
@EricM_Inovelli can you please comment? I’d like to know if the file you posted in the v1.51 folder is actually the v1.50 file, OR is the v1.51 file incorrectly reporting itself as v1.50? I’ve been updating many switches over the weekend and they’re all reporting v1.50 when using the v1.51 file
Hubitat. Using the Z-wave Firmware Updater. I’m able to update the 1.52 Beta OTZ, but I don’t see that line Target 0 or 1. Goes to 100% fine and shows as 1.52 when done. How do I do the next 1.43 Holtek then, or do I not need to do it… ?
I understand what you are saying if the request comes frivolously from end-users that have no idea how to write microcode. However that is not the case here. I have a degree in Computer Engineering and I have coded many things including firmware for microcontrollers with much less memory than the 500 series chips in these devices. I stand by my statement that in this particular case, what we’re talking about is a very simple logic test and I even supplied the psuedo-code to support my statement.
… I won’t characterize the initial reaction as 700ms was “good enough”. Many others agreed and joined in the request. So some of us have been waiting for way longer than even you 
so are glad it’s finally here! Hehe!
and Much Thanks to Inovelli! 