"Fake" physical dimmer dilemma

That doesn’t work either. LED strip just stays on as if bulbs were 100% brightness…won’t react as I change dim level.

Sorry to be frank, but are you and @curiouspasserby just guessing to see if this works or do you have it working on your setup? I’ve never seen @EricM_Inovelli recommend using anything but Group 2 and Group 4 for smart bulb associations with dimmers. And while I’ve searched the community, I also haven’t seen a working model of how to have a Red Series Dimmer LED strip reflect the dimness of the associated bulbs outside of the rules I built here: Smart bulb dimming with Red Series Dimmer (LZW31-SN) on Hubitat - #8 by jws6 - Sorting Category - Inovelli Community

I’m by no means an expert in any of this and I’m not convinced the way I got it working is the “best” but right now it’s the only way I’ve seen that works.

@jws6 LED strip stays 100% in disabled local mode. In my opinion local mode shouldn’t be disabled or the strip shouldn’t be locked at 100%

Disable local mode = make the dimmer to completely not respond to physically pressed buttons (like a security feature)
Disable remote mode = same, but only related to Hubitat

Any other behavior in these modes is misleading (or the modes were named as misleading)

It shouldn’t change the LED strip behavior

1 Like

I came across your post looking to see if Inovelli supported the 10v dimming. I’m intrigued by this and trying to understand it. I use Home Assistant, not Hubitat, and I haven’t worked with the Associated Groupings yet, but I assume it would be somewhat similar.

Essentially, you’re using a 0-10v dimmer with an Inovelli switch + Qubino and have “full” functionality at the Inovelli switch? How is your response timing? You hold the Inovelli switch to brighten the LEDs, and it reacts well?

Trying to figure out if I could use the same concept with this:

https://www.q-tran.com/Customer-Content/www/products/Files/INSTALL_PSC_QTM-eLED.pdf?i=68788905

I thought of putting the Qubino on the driver, but I also want a physical switch on a wall. This solution sounds like it delivers that?

Thanks!

@curiouspasserby and @jws6 in total agreement with you.

I bought Red Dimmer on the premise that it would not mess with the power to the local load but still retain full Z-wave dimmer functionality, ie, would still function in all other ways and send dimming information to my home automation platform (Homeseer) so that I could then use the dim level information to set other devices such as Zigbee bulbs (Hue). Basically turn it into a Z-wave remote dimmer accessory, like the ones Eaton Cooper sell, with the added benefit of retaining local load control if one decides to switch back to dumb bulbs in the circuit.

@EricM_Inovelli and @Eric_Inovelli I really feel the marketing of your device is misleading, considering you now have at least three folks here who all thought it would operate in a way that seems not possible (at the moment).

@nomearelti

I thought of putting the Qubino on the driver, but I also want a physical switch on a wall. This solution sounds like it delivers that?

Correct! I don’t even need hub (it can be offline).
Qubino 0-10V Z-Wave IS the Dimmer. That’s very important to understand. It has no physical control at all and full 12 or 24V power must come to it (I have AUX 24V power right in my LED driver inside the pendant). You can control it only via the hub.
But what I did: using Inovelli driver with Red Dimmer and Association tool (which you probably can do directly through the driver without the tool) I created group 2, 3 and 4 association between Red Dimmer and Qubino 0-10V dimmer. Once it’s done, Red Dimmer sends the commands directly to Qubino allowing to physically control it.
It is fast as it’s all local, literally like your Red Dimmer dims the LED. There could be very little noticeable delay, but probably only because you know technical implementation. My wife didn’t complain and feels pretty comfortable

1 Like

I know there is a, “debate” as to what the right and wrong approach is to this and we are addressing it in separate firmware. Smart bulb mode does exactly as it’s intended (right or wrong). It keeps 100% power to the light bulb and you use associations or scene control to control the smart bulb.

I have Hue setup at my house with the dimmers dimming them perfectly up and down using scene control on Hubitat. Relay is disabled, full power goes to the bulb and does not get cut. Hence, smart bulb mode.

We now know that there are alternative ways to make this happen and as mentioned, we are working on firmware (there’s only one guy) to try some things to make it smoother.

So, difference of opinions on whether our marketing is, “misleading”, but I can tell you that smart bulbs work just fine without rewiring anything.

Out of curiosity, how would you prefer us to explain it to be more clear? I’m happy to optimize the listing if it causes less confusion.

Hi @Eric_Inovelli ,

First, if there is new firmware coming put that solves this dilemma, then I will be the first one to fill my house with Red Dimmers and recommend them as the only dimmer one should consider. It truly will make the Red Dimmer the most feature packed currently on the market.

Secondly, when you say you have Red Dimmers controlling your Hue bulbs, what platform? From reading through your website, the resources seem focused on writing custom drivers for SmartThings. There are many of us on other platforms, especially system integrators, that prefer systems that don’t rely on cloud connections. That means using strictly local control and Z-wave commands. Can I simulate a dimming function by detecting the paddle held down? Sure, but that requires me to come up with some scripting for key held, looping to adjust dim level on the bulb, key release, and the right timing so it works smoothly. But if I was getting the actual Z-wave dim commands sent to the platform then I could simply link the device representation for the Red Dimmer to the device representation of the Hue bulb and they would track each other easily.

And having dim control, without affecting the load, would allow local visualization of the virtual dim level. As of right now, there’s no way of doing that as far as we know.

In terms of how to explain how it currently works? Very simply state disabling the local relay also disables all dimming commands sent from the dimmer and dimming level indications on the LED strip. You’re basically limited to scene control and that’s it.

Just to reiterate, if you can “fix” the current operation to the one that some of us expect, at the current price point, then you’ve got a runaway hit IMO. No other dimmer currently on the market would be able to match it. The only one that comes close is the Homeseer 200, but they seriously messed up on the dim level limits. You folks took a smart approach by adding another chip and bypassing the memory limitations of the current 500 series Z-wave chip.

Hopefully you’ll take the suggestions in the spirit they were intended, which is to simply improve a product that many of us would love to buy dozens of.

@EricM_Inovelli

It keeps 100% power to the light bulb and you use associations or scene control to control the smart bulb.

So I don’t know how exactly you did it, but it DOES cut the power in Smart Bulb mode.
I’m on 1.47 firmware, I enable Smart Bulb mode. When I turn off the dimmer either physically or via Hubitat (press Down once), it shuts off the power to bulbs (or in my case to Qubino completely).

I have Hue setup at my house with the dimmers dimming them perfectly up and down using scene control on Hubitat. Relay is disabled, full power goes to the bulb and does not get cut. Hence, smart bulb mode.

I don’t know why everyone keeps saying “relay” word. There is NO “relay” word in the settings of the dimmer. There is Local Control Mode setting, which in theory should disable any physical control over the dimmer and maybe it does it, but it make LED always on at 100%, which basically defeats the whole purpose of the dimmer, so it becomes useless.

So, difference of opinions on whether our marketing is, “misleading”, but I can tell you that smart bulbs work just fine without rewiring anything.

The wording is misleading as I described above: smart mode shutting down the power and not usable LED indicator with disabled local control.
Unless there are real issues with the 1.47 firmware, which will be fixed in future (but this firmware comes out of the box from Amazon). But in this case we need a confirmation that there are issues.

Overall, the product is awesome and super cool! But the initial config isn’t clear. I had to re-wire and bypass the control of the power to make it work in my case, but according to you it should work without it, but it doesn’t

1 Like

You are confusing two distinct settings. Smart Bulb Mode insures that the dimmer is at full brightness. So if you want a dimmer to act like a switch, turn on it on. You can still control the light from the switch. It also insures that a smart bulb doesn’t experience reduced voltage from the dimmer.

Disable Local Control prevents you from using the switch to accidentally turn off the light if you are using a smart bulb.

I’ll tell you why so now you’ll know too. It’s a slang . . . sort of a pass-along from the switch, which does have a relay. You are correct . . it’s referring to Disable Local/Remote control.

Disabling local control does not make the bulb always 100%. You should be able to disable local control and still dim a bulb via it’s wired connection from other sources, such as your hub or via a scene. If your bulb is staying at 100% with ONLY disable local control disabled, then there is some other setting, on the dimmer or otherwise, that’s doing that.

1 Like

Qubino itself has on, off and dim capabilities and is controllable as long as my physical dumb switch is on. It also does have a memory, so it remembers the last state if I turn the switch off.

I just got this up and running to test. Nothing is installed, just sitting on my countertop, but when I turn off the Qubino, it still outputs 1v, which sets my LEDs to 10% brightness I assume. When you turn off the Qubino, do your LEDs actually turn off? If you’ve already closed up the light, perhaps you don’t want to test, but are you also getting 1v when it’s off? I was planning on running live 14-2 to the LED controller, with no switch involved, but based on my initial testing, it seems I’ll have to still have a switch before the controller to turn off the LEDs. That’s too bad because I put a 120v > 12v converter off of the main power to power the Qubino.

The ZWave parameters have a minimum dim level, which is set to 1%, but I’m clearly getting 1.0v.

@Bry I see. I’ll play with it a bit more and see. I’m still questioning 100% powered LED.

@nomearelti Hi! Disassembled it for you to double check :slight_smile: My input is constant 11V (though I thought it’s 24V). When my Qubino is off, the output is 0V. My LEDs (and looks like yours too) don’t work below 10% and above 99% (when you set it to anything 1-9% the LED is still off, and 100% goes back to 99%). So the only change which I made was on Qubino I set “60. Minimum dimming value” to 10 and “61. Maximum dimming value” to 99. And decreased “66. Dimming time when key pressed” to 1s vs 3s.
On the Inovelli Dimmer I set the same options: Minimum Level and Maximum level to 10 and to 99.
In pendant it looks like this:


Let me know if it helps. Make sure your wiring is correct.
If you’re on Hubitat, this is the driver I used: https://github.com/rob121/hubitat/blob/master/drivers/qubino/FlushDimmer0-10v.groovy
If it still always outputs 1V, you may want to contact Qubino support, I think it’s the only other option (or replace it)

Thanks for checking that for me!

I actually bought three of the Qubinos because I have three different drivers I wanted to use this with. I tested all three and got the same result (minimum dim was 1v).

I use Home Assistant, with OpenZWave 1.6.1210. They list that on their compatibility page, so I would expect it to work (https://qubino.com/manuals/Compatibility_with_gateways/Compatibility_manual_Flush_Dimmer_0-10V_02092019.pdf)

I opened a support ticket with Qubino, but read online they can be a bit slow in responding. I did find another post where the user said they it never dropped below 0.5v and required a second switch. The way the switch/ dimmer shows in OpenZWave is a bit strange, it lists a switch and a dimmer. If I put the brightness at 99%, with the switch off, the LEDs brighten to 99% anyway, but the status of the switch doesn’t change to on.

I’ll report back when I get a response from Qubino. Hopefully they have a solution because I really want to be able to use these drivers with Inovelli wall switches like you’ve done.

[edit] I may run to my local hardware store tomorrow and try to get a diode to reduce the voltage… that may be a pretty cheap solution. [/edit]

Qubino support actually responded fairly quickly and said I would need a 1k ohm resistor. I added that and now my voltage drops to 0.95v. They also said it should drop to 0.2v - 0.4v without the resistor, so I’m still fairly sure these aren’t working correctly. At least I can shut off my light now though.

It’s clear their support is in Europe, so each response took a day roundtrip, but their responses were helpful. I’m still quite confused why my situation wasn’t working “out of the box.” The LED driver that I’m using pulls 2 mA, which is in their spec, yet, their dimmer never dropped below 1v.

Will attempt to install this and run a new Red Dimmer soon. I’ll get the LEDs installed first, then work on the Red Dimmer in the wall. Thanks for posting your solution, hopefully I can get it all up and running without too many more questions!

@nomearelti ah, that’s right! I totally forgot about it: either Inovelli or Qubino depends on the load. It has to be more than X w in total. I don’t remember the exact number, you’ll have to read the manuals. If it’s less than X, then you do require a resistor.

I’m using scenes to control a group of Hue bulbs -is there a way to ‘sync’ the LED strip to match the on/off/dim state of that group?