This is kind of a big thing for an “aside from”. I want every switch in my house to behave the same, regardless if its wirelessly controlling a smart bulb or an electrical load (I don’t want to have to explain to my fiance or guests “Well this room doesn’t show you the brightness level on the LED, and instead of pressing and holding you have to double tap. But this other room is actually dimming the load so you press and hold… etc”. I’m looking for unification.
I can have what I want right now if I hardwire load to line - this is what I’m doing in my bedroom. But I’m going to be annoyed when I want or need to change (e.g. sell the house - light switches should work like people expect without a hub) and instead of changing a setting I have to pull the switch out and rewire.
Yeah I completely understand and meant no offense by insinuating this was not a big deal. I was merely trying to isolate the issue to understand what we currently have vs where the gap is. So apologies if it came off as otherwise.
One of the big things we’re focusing on in 2021 is user experience. Super important to us and me personally. Completely understand the pain-point in having to explain to the significant other and/or guests how the house works. Not fun at all.
I think I’m clear now in understanding what needs to be done. Thanks for hanging in there with me. Now time to try to explain this to the firmware engineer!
I attempted to update two of my dimmers to 1.52 tonight.
The first one went off without issue, upgraded ok, maintained functionality have tested a bunch and it is working as expected.
Went I went to update the second switch, it completed the upgrade and things looked ok. I went to disable the relay and enable smart bulb mode and it is now stuck in a loop (red/green/blue flashing in a continuous loop with my smart bulbs flickering on and off for a second or two). I tried air gapping and attempting to factory reset, but nothing has worked. Any thoughts on how I can force a factory reset easily so I can get a stable switch to edit settings or reflash?
I actually pulled it out and threw a dumb switch in place for now as it is currently unusable.
All suggestions appreciated
Thanks!
P.S. This is a non-neutral setup and I did enable option 52 (I came from a very old FW, 1.35). I’m thinking it has to do with option 52 and the non-neutral setup as that should be the only thing that was changed as far as settings are concerned. The first switch that updated without issue is a neutral setup and I also enabled the smart bulb option, but it looks to be working just fine.
No, that does NOT accomplish the same thing. That is how I had it set in V1.45 BEFORE Smart Bulb Mode was added in v1.47. It was close but not the same because setting the dimming rate to 0 does not DISABLE dimming, it just dims very fast. The killer is that Parameter 5 is restricted to 1-45 so the Minimum Level can not be set any higher than 45. Setting the dim rates and ramp rates to zero still allows the load to “dim” down to 45 instead of being fixed at 100%. V1.47 provided what I needed when it introduced Smart Bulb Mode which keeps the load at 100% with any SetLevel other than 0. V1.52 changes it so the load is ALWAYS 100% with any SetLevel INCLUDING 0 which breaks things for me because I want the load to be off when SetLevel is 0 and the load to be 100% with and SetLevel other than 0 (this is the v1.47 smart bulb behaviour).
@EricM_Inovelli PLEASE make v1.51 available as the parameter changes do NOT mimic the same behaviour as I have explained above.
YES YES THIS ^^^^^^^ ALL THIS ^^^^^^^
Although, I still like being able to turn the load ON/OFF (100% or 0%)
Understood and I certainly wouldn’t be using it for outlets, motors, appliances, etc. But there are many lights that are not dimmable, including most CFL’s and many types of modern LED bulbs. I have non-dimmable LED bulbs and CFLs in locations today that may get replaced with dimmable LEDs in the future. I may be wrong but I don’t believe running these lights with dimmers fixed at 100% can be much of a risk. And forcing us to swap out switches whenever the bulb type changes seems a bit excessive if the firmware would simply support a non-dimmable mode.
Yes, exactly!
If the only use for the LED Bar was to reflect status of the load then it might as well just be a single LED just like on the on/off switches. The multi-segment bar is what makes the Inovelli distinctive and stand out from other brands. EMBRACE IT Start thinking outside the box For starters, with Smart Bulbs, the load output from the switch should always be 100% but the LED Status Bar should reflect the Level of brightness (SetLevel) of the bulbs. There are MANY other possibilities. A countdown timer is one good example where the level of the bar is indicating time left rather than light intensity. This happens now with V1.47 and a Fade command is sent with Smart Bulb Mode enabled. Another example could be indicating relative number of bulbs lit when there is more than one bulb being controlled (versus the intensity of all bulbs). I have some ceiling can lights that have a “LED Halo” ring. Its activated by switching the fixture on/off/on. I can use the LED bar to indicate (0%=lights off, 50%=Halo on, 100%=main light on). Or how about using it to indicate the relative value of a luminance sensor that controls outdoor lights. Also possible could be the relative position of the garage door (garage closed=0ff, garage moving=50%, garage open=100%). Another thought is using it to indicate a Battery level. Basically, ANYTHING with a relative value could be indicated. I realize some of these examples belong in the “LED notifications” category, but there is [currently] no way to set the LED Bar “level” via the LED notifications. However a SetLevel() command currently does set the LED bar level and could be used for various indications when the load is non-dimmable.
I would really like to see an official response from Inovelli on this suggestion. I think it would be very easy to implement (possibly no more than text editing the restriction in the DTH) and it would effectively disable dimming as well as address issues with LEDs that need more than 50% to turn on. Is there some reason this is not being considered? I think I’m going to try a modified DTH just to see if that works. Its an easy edit to change the range from 1-45 to 1-99, but I don’t know if there is something hard-coded in the switch firmware that will override or prevent Minimum Level higher than 45. If the firmware is restricting it, then WHY? If this were implemented, it might also limit the range on the LED Status Bar (maybe or maybe not?). That might possibly limit some of the current LED Bar functionality and would not be ideal if it does. But I think its an easy way to provide a “non-dimming” setting without having to create a whole new parameter. Currently, setting the Minimum Level to 45 (the max) and sending a SetLeve(1) outputs 45% to the load but only lights up the lowest segment on the Led Status Bar, so it looks like the Led Bar still tracks SetLevel from 0-99 and hopefully will still do that if the Minimum Level were set to 99 and a SetLevel() was sent with something less than 99 (expecting load to stay at 100% but Led Bar track the SetLevel)
@mamber It is a firmware limitation that was introduced to reduce the complications if a user were to set the minimum level higher than the maximum. For example, if you set the minimum to 99 and the maximum to 75. At the time we did not see a need to have a minimum that high, but do see it now. We can program around that scenario though. That’s why we have beta releases is to figure this stuff out.
Has anyone tested the new parameter 50? I set the delay to 100ms and 900ms and I can’t perceive a difference. I already tried excluding and including after updating the firmware to 1.52.
Is it coded into the actual firmware in the switch or just the Device Handler? Its pretty easy to program it so setting any Minimum forces the Maximum be the same or greater. Has that been done in any of the beta releases?
BTW, thanks for making 1.51 available on the download site
Its coded in the firmware on the switch. There was a discussion about it a long time ago (I cant find the post), but I believe the main concern at the time was the lack of space on the device (firmware flash size). If you allow the minimum value to be set to anything up to 99, then you have to add additional checks/logic to ensure that the minimum value is not set higher than the maximum value.
The 500 series chipsets in these switches has very limited firmware space, and some features have already had to be removed to free up enough space for some of the enhancements added in the beta versions.
@Eric_Inovelli I’m testing 1.52. I just want to say THANK YOU for adding an adjustable delay between 100ms and 900ms. That’s amazing. Now the switch reacts really fast when i single click.
I managed to get out of the loop by yanking the switch and powering it via an extension cord temporarily. Factory reset and managed to get it back.
As soon as I would disable the local relay and then attempt to enable smart bulb mode, it would get stuck in that boot loop and the only way I could seem to recover is to pull it out and hook it back up to external power (extension cord) to adjust the settings to default.
As an FYI, I am running 6 11W smart bulbs on that switch.
@stu1811 I have it working on 5 switches. If you set it to 100ms you should have to tap the switch at near superhuman speed to get scenes to activate. Are you sure you don’t have the delay disabled altogether?
I assume that the way you grouped the 1.41.bin with the 1.51 otz means that I should NOT use the v1.43 bin with it? Is that correct? If you hadn’t grouped them that way, I would’ve assumed I should use the v1.43 bin with v1.51 otz.
@EricM_Inovelli I just want to make sure the v1.41.bin + v1.52.otz grouping is intentional and not a typo. Can you confirm?
I agree completely! Many thanks to the crew at Inovelli for listening to us!
If there’s something developers love to hear from a 3rd party, it’s how easy some sort of feature would be to implement…
I’m sure you mean well, but unless you’re involved with inovelli’s firmware, you really don’t know how easy or not something would be to implement. You’re making an assumption.
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.
make v1.51 available as the parameter changes do NOT mimic the same behaviour as I have explained above.
Start thinking outside the box 
For starters, with Smart Bulbs, the load output from the switch should always be 100% but the LED Status Bar should reflect the Level of brightness (SetLevel) of the bulbs. There are MANY other possibilities. A countdown timer is one good example where the level of the bar is indicating time left rather than light intensity. This happens now with V1.47 and a Fade command is sent with Smart Bulb Mode enabled. Another example could be indicating relative number of bulbs lit when there is more than one bulb being controlled (versus the intensity of all bulbs). I have some ceiling can lights that have a “LED Halo” ring. Its activated by switching the fixture on/off/on. I can use the LED bar to indicate (0%=lights off, 50%=Halo on, 100%=main light on). Or how about using it to indicate the relative value of a luminance sensor that controls outdoor lights. Also possible could be the relative position of the garage door (garage closed=0ff, garage moving=50%, garage open=100%). Another thought is using it to indicate a Battery level. Basically, ANYTHING with a relative value could be indicated. I realize some of these examples belong in the “LED notifications” category, but there is [currently] no way to set the LED Bar “level” via the LED notifications. However a SetLevel() command currently does set the LED bar level and could be used for various indications when the load is non-dimmable.
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.