YES. This is the same situation I am in. Prefer to install Red Dimmers everywhere (for consistency and future flexibility) and able to disable dimming when they happen to have non-dimmable loads.
I mostly agree. However, I’m on the fence about the LED bar always showing 100%. I’ve grown accustomed to how it works now in v1.47 where the load is 100% on or off but the LED bar still tracks the logical level setting. Its another way to give some visual indication of things. Clearly a non-dimmable bulb is on or off, but one way I use this now is when the light is timed to go off after a certain amount of time. The way it works now with v1.47, the LED bar will slowly “count down” giving a visual indication of how much time is left before the light turns off. So even though the light is not getting dimmer, its still handy to see the “dimming” LED bar as a countdown indicator.
Having the LED bar continue to track logical level allows me to send a SetLevel() command and have the LED bar indicate various levels of something other than bulb intensity. There is currently no way that I know of to do that with LED Notifications parameters.
Don’t get me wrong. I’m not saying its a requirement. I could be swayed away from it. But since that’s how it works now, I’ve been taking advantage of that “feature” and its never fun when we have to give up features
That’s a great use case, and would fit perfectly into the solution I described. You would set the logical mode to “dimmable” and the phyiscal mode to “all or nothing”. I didn’t originally have a good use case for the “all or nothing” option but a countdown timer is a really great one.
@EricM_Inovelli can you make the v1.51 (or v1.49) firmware available? Looking at the release notes, it appears I can get the new “multi-tap delay” setting in 1.49 (or .51) without having to lose my “smart bulb with on/off” that goes away (always on) in v1.52
V1.52 - 01/22/2021
Modified Smart Bulb Mode so that the output can only be turned off by sending a BasicSet(0x00).
Fixed: Solve the problem that the power measured by the light is 5W when the load is not connected (caused by inaccurate power measurement at extremely low power consumption).
V1.51 - 01/08/2021
Fixed: Low brightness would brighten and then darken when being dimmed.
Fixed: Issue where the same value of parameter 5 (Minimum Level) appears inconsistently when both parameters 21 (Power Type =1 - Neutral) and 22 (Switch Type = 1 – 3-Way) are set to 1.
V1.49 - 12/16/2020
Remove local configuration mode (to make space for extra features).
Adding parameter 50 to adjust the delay when parameter 51 is set to 1. 1=100ms, 2=200ms, 3=300ms, etc.
In 1.52, you should still be able to press the config button 8x to “disable the local relay” and get the same functionality you were seeing in previous firmware versions.
Just to make sure we understand each other…because I’m pretty sure that won’t get the same functionality
Are you saying that disabling the internal relay will still allow local on/off control but only disables dimming? That does not match with anything else I’ve read about it. I thought a disable relay would also disable the physical on/off of the load (always on or always off).
And as I understand it I need the relay to work in a 3-way or 4-way with standard aux switches, right? (most of my switches are 3-way)
I must have misread your post and didnt realize what you were trying to do. I think I understand now (turn off the light instantly, but after a delay, and use the LED strip to show a “countdown” until the lights turn off). If my new understanding is correct, disabling the local relay will not do what you are looking for.
Personally, I think what you are trying to do would be better served by a separate config parameter, similar to parameter 8 (auto-off timer), but as a 1-time command and to have it show a progress bar “countdown”
No that’s not it. Now you’re reading too much into it
In the simplest terms, I want to disable dimming but still turn the load on/off from the switch.
The common use for this is with non-dimmable lights. This is how it currently works, and according to the Release Notes, still works in v1.51 if I can get my hands on it. V1.52 breaks this (although I understand it fixes the true purpose of the “smart bulb mode”)
(Please @EricM_Inovelli if you don’t want to post v1.51 publicly can you send it to me privately?)
“disable dimming” could be implemented as a new parameter but is not really necessary since it could also be implemented very simply by allowing the existing Param5 “Minimum Level” to have a range of 1-99. That would solve two issues by providing a non-dimming function (set min level to 99) as well as supporting lights that need more than 50% to turn on (set min level to something higher than 50)
The “countdown timer” was just an example of still using the LED bar even when the load is non-dimable. That was my rebuttal to the suggestion that LED bar should always be 100% if a non-dimming mode was enabled (which I don’t agree with). A delayed countdown function is not my request here, that was just one of many possible uses for the LED bar even if the load is non-dimmable
I’m having a problem after installing the new Hubitat driver. I’ve updated most, but not all of my dimmers to 1.52 and they worked fine before the driver update. But now the ‘current states’ information doesn’t update and I see no log activity with local or remote control. The only exception is two dimmers that are running with no security and 1.52 work properly, but the dimmers with S2 security and 1.52 aren’t updating their status (not sure if security level is related or a coincidence). I have a couple dimmers still running 1.48 and they update their current state properly. I didn’t save the previous version of the driver to try switching back and confirm for sure it’s the cause. Is anyone else seeing this?
Makes sense. I’ll let @EricM_Inovelli comment on ignoring level updates as I’m not sure if that’s possible.
Question for ya around the remote level protection – is this just a security feature (ie: if you by accident set the level on the switch in your UI) or is there another reason I’m not seeing? Just curious.
I just wanted to note that the overall premise is possible right now aside from the remotely ignoring level updates. If you set Parameter 1 to 0, you should be able to turn the dimmer on/off instantly from 0-100. From there Parameters 2-4 will sync so that when you press/hold it will be instant.
Yes, correct. This is how it’s setup now if you disable local or remote control, nothing will cut power to the switch be it at the switch itself (local) or via your hub/gateway (remote). With SBM enabled, the switch delivers 100% power to the bulb and then disables local control of the switch.
We kept Remote control enabled bc of safety reasons (ie: you’re away from your house, but your smart smoke alarm alerts you to a problem – you can cut power to that bulb). If you want to disable remote control, there is a separate feature to do so (similarly to how you can disable local control separately from SBM).
I’m confused here – can you clarify? The bulb should always be receiving 100% power from the switch. The bulb is instead dimmed down in intensity via the, “smarts” inside the bulb itself, not the amount of power being throttled from the switch. I’m not an electrician nor engineer so apologies if that didn’t make sense or I used the wrong vocab lol.
I believe you can accomplish this via scene control if Associations are not an option (ie: tap up 1x = smart bulb turns on via switch sending a signal to your hub, tap down 1x = smart bulb turns off via switch sending a signal to your hub).
There may be a better way to do it – but this is how I’ve accomplished it on Hubitat using Hue bulbs and our switches.
Good news for you is that I know little about either! I can make you a cool picture that sells switches and hang out with you guys in the forum though lol.
Agree.
Fun fact, this is an actual screenshot from a convo a couple weeks back:
@Bry used the word segue and I had to look it up bc I thought it was some French word (said: seg-oo).
That said, you can imagine my brain with the word orthogonal lol.
anyway…
I’ll have to have @EricM_Inovelli or someone from the manufacturer tackle this one. It’s my understanding that the hardware is different in the switch in that it does not have a relay similar to the on/off switch – so it can’t do a binary on/off, but rather we, “trick” it into turning on and off fast.
This is why we do not suggest putting these on non-dimmable loads. While we can trick it to do work, what happens if it fails and reverts back to being a dimmer? We’d hate to be liable for that expensive non-dimmable appliance.
So, while we may be able to solve this via firmware, the hardware in a dimmer is much different and the reason why we can’t endorse putting it on outlets or other non-dimmable devices.
My brain is fried right now – I’ll have to come back to read this tbh. I love the energy and passion though. Thank you for breaking this down.
@Bry 's solve below is how you would accomplish what you’re trying to do. Good news is we haven’t changed that feature since the beginning
Bad news is we still do not recommend putting dimmers on non-dimmable devices for safety reasons and it will void the warranty, but below is how you would accomplish it if you want to take a chance!
I can post it up on the server, but the recommendations about changing a couple parameters may work for you so try that out first.
@jtronicus I get what you are saying about being able to turn off the device via z-wave commands. I originally thought maybe just have it turn off with a “basicSet(0x00)” but do not have it turn off when using switchMultilevelSet(0x00). If all hubs use switchMultilevelSet when turning the device off then this would take care of it. I’m not sure that is the case, but will look into it. Either way we will get it working the way you are describing.
Pretty much to prevent accidental level changes. Like @mamber pointed out it would be nice to be able to intentionally set the level remotely to update the led bar but without having it affect the load at all.
I reallllly encourage you to stop thinking disabling local/remote control is a solution here, as it is not. I DO want to be able to update the logical state of the switch (turn it on, off, set its dim level) both locally and remotely - I just don’t want it to change the load.
It is really useful to have a smart device on the wall that I can use to communicate with the hub. Scenes are not a replacement, as scenes don’t allow you to press and hold to gradually dim the value from 0 - 100%. Also even for on/off, to use scenes to accomplish this in home assistant I would have to create a virtual switch and have automations that turn it on and off when it sees
the scene events… this is so unnecessarily complicated when I already have a switch device that does all of the things I want… I just don’t want it to affect the power sent to my smart bulb.
Seems like a farfetched use case IMO - people will still have smart bulbs plugged into always-on outlets and not be able to kill power to them remotely. Maybe someone wants this as a feature, but it is definitely not required from a safety perspective.
I haven’t upgraded to 1.52 beta yet to test this, so maybe it is close to working, but it still sounds like power will be cut if I flip the switch off remotely (i.e. from automation), which prevents automations talking to the bulb until I remotely flip the switch back on
See above for why scenes are not a solution - they fire every time you press the button (i.e. I only want an event when there’s a state change), and also there is no dimming. I want to press and hold the dimmer to change the switch level, have that level reported to the hub, and automate based on that level. Scenes are great for 1-time events, but not for controlling state (that’s what the switch is supposed to do for me).
Haha! Basically just trying to say that disabling local/remote control is useful, but that it is not related in any way to the problems here.
Fair enough, and I don’t think its a problem. Key point is remotely setting the level to 50% should update the LED to 50% but keep the power output at 100%.
Haha completely understand. Yeah I just got my 10 switches in and started installing and was pretty disappointed when I found out that the “disable relay” option doesn’t completely disable the relay. But seeing you guys engage with the community to improve the firmware has me optimistic.
Ok, but I guess what is the point of the LED bar moving and not reflecting the status of the load? I’m not pushing back, I promise – I’m just trying to really understand the use-case here. I see count-down timer suggested, but outside of that, I’m not sure what the use-case would be. Again, just curious more than anything as we also have to explain this to the firmware engineers where English is not their first language.
I’m really trying to understand, I promise. I’m not sure why it’s not computing in my head or the rest of the team’s.
I think I understand what you’re saying and I think what it boils down to is you want the LED bar to sync with the smart load, right?
Can I ask what the point of this is? Why do you want to change the switch but not have it reflect the at the load?
The way it’s setup now is that the power going to the load is constant (as smart bulbs need 100% power) and if you want to change the intensity of the smart bulb you do so via either your app/voice assistant (by telling the bulb to raise/lower intensity) or you do it via the switch (association or scene control – and yes, I’ll get to your next paragraph below to address that concern).
So, I can’t figure out why you’d need control of the switch to turn on/off or dim your bulb. Again, I’m likely missing something and I apologize.
Scenes do allow you to do this, but I think I may be tracking in my theory that really what everything boils down to is a way to have the LED bar indicate where the smart bulb needs to be at virtually.
I can’t remember off the top of my head how to do this and maybe @EricM_Inovelli can explain better, but essentially with scenes you have a hold down scene and a release scene. When you hold down a scene command is sent and with some hubs (I know Hubitat can do this as I have this setup with Hue bulbs) it starts the dim up (or down) process and then when you release the paddle another scene command is sent to the hub and it tells the bulb to stop digitally dimming.
The disconnect is the LED bar will not notify you where you’re at so there’s a bit of guess work.
However, as I was messing around with it a bit more, I think I have had a breakthrough in how we could solve this potentially – again, I’m not a firmware engineer, so I’m not sure if it’s possible.
Under normal circumstances, when SBM (or local and/or remote control) are not active, when you dim up and down on the switch and release, the switch sends a, “SwitchMultiLevelReport” to the hub (ie: 60 = 60%). However, when SBM/local/remote are enabled, the switch no longer sends that report (it only reports the scene commands).
So, if we could somehow make the switch send the SwitchMultiLevelReport while SBM is enabled, you could set an automation to send that level to the smart bulb and if we can isolate the LED bar, it could tell the bar as well to go to 60. Does that make sense and is that what you’re getting at?
Noted – you can still enable remote protection separately, so we’ll likely keep this as is. I’m not familiar with HA though, so is it a PITA to do this?
Yes it will be cut remotely unless remote control is on. For your automations, we would encourage you to use your bulbs instead of the switch if you want to automate your bulbs. But again, I’m likely missing something as to why you’d want to use the switch.
Well I guess I should’ve read further down before having my breakthrough – I think we’re saying the same thing now, right (ie: SwitchMultiLevelReport value)?
Fingers crossed I’m finally understanding. I also may move our convo over to the Smart Bulb Mode convo just an FYI.
This is more or less what I mean by the “logical state”. The switch would still keep track of the logical state (i.e. the LED, starting value next time you press/hold the paddle), but would not necessarily use that state to change the load (depending on what smartbulb mode you have).
Let me maybe try to explain the general desire differently. Forget about controlling a load at the wall entirely - chop the load screw off of the inovelli red dimmer. There’s still a super useful device there - it keeps track of a value, lets you toggle it on/off, shows you its state on the led, display notification effects on the LED. It wires directly into your wall so that you don’t have to change batteries, and you can reuse that hole in the wall that would otherwise be wasted. That is a great piece of hardware that integrates nicely into my room and lets me do cool home automation things with it. If you sold this device I’d probably buy it.
Now adding the ability to control an electrical load is a killer feature, because now I can use it in cases where there was already a ceiling light or whatever wired into that hole in the wall. But I don’t always need that feature and with smart bulbs its an anti-feature.
To give you a real life example, the first zwave switch I bought (which I’m planning to replace with an inovelli red) was a jasco toggle switch. I got it because I had an existing switch on my wall that controlled an outlet that made perfect sense as the living room light, but the outlet was not where I wanted to put lighting. So I put in the jasco and can control some bulbs across the room. When I flip the switch a loud relay clicks and it toggles power to the outlet - but I don’t want it to toggle power because I don’t want that outlet to be switched anymore (since I’m not using it for lighting). Its annoying. My other options were to get a battery powered wall controller and stick it on my wall… but then I’d still have this toggle switch that does nothing.
Are you just basically asking for a remote but that’s hard-wired in the wall that can dim up/down and turn on/off other smart devices (in addition to being a hardwired light switch)?
If I’m not getting it, I’ll likely have someone else jump in as I just don’t get it .
I have this exact setup in two of my daughter’s rooms so this is where I’m struggling to understand how our switch doesn’t do what you’re asking (aside from the LED bar tracking and reporting the switchmultilevelreport).
My example:
Red Series On/Off switch is wired to a switchable outlet
I don’t want this outlet to be switchable as it has an Amazon Alexa plugged in
I’ve disabled local and remote control on the switch so that now no one can turn off the outlet (so power can’t be cut to the outlet)
There are two bulbs in the room that are Philips Hue bulbs (not connected to the outlet)
Using the LZW30-SN, I’ve setup tap sequences to turn on/off the lights and change their colors
Granted, I didn’t put a dimmer on the outlet bc of code, but if I did, I could do the same thing (ie: make the switch a remote).
Then by adding in the switchmultilevelreport feature, we’d be able to have better control over the dimmable Hue bulbs while reflecting the proper status on the LED bar.
Sorry if I’m just not getting it – I’ll likely have @EricM_Inovelli or @jtronicus chime in as maybe they can explain better. I still need to read @jtronicus’s explanation in the other thread.
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!
if you don’t want to post v1.51 publicly can you send it to me privately?)
.