Slow and unreliable RGBW in HA controlled by Red Series Switch

Switches General Discussion
,
#1

I just ordered a bunch of Red series dimmers and RGBW bulbs after having great luck with the red series switches in HA. I received one of my bulbs and paired it. Now I’m finding the Inovelli RGBW bulbs are very slow to update, and are often delayed by several seconds. I’m in my planning phase, so the bulb is always powered in a lamp socket, where as my switch is controlling a vanity light physically, and triggering the bulb. I have set the custom configuration supported features option to 177, which helped speed things up some, but its still; far behind the responsiveness of other RGBW bulbs.

Am I better pairing these in Hubitat and bridging rather than natively pairing in Home Assistant? I have 10 more bulbs coming this week, so I’d love to find a solution fast. I currently have some other devices bridged from Hubitat due to lack of native HA support, so that could be an option if its the best option.

#2

Are you using zwave switches and controlling the Inovelli bulbs via association, or are you triggering an automation based on scenes?

I have noticed the following when controlling bulbs via HA (OpenZwave):

  • Every time OZW sends a command to a bulb, it immediately sends another command to get the status of the bulb. If the bulb is in the process of transitioning on or off, the bulb will report its current state, not the state it will be in once the transition is complete. Then, once the bulb has finished transitioning, it will self-report the new state. This causes a perceived delay in HA.

For example, I turn the light on in HA, and it may take 4 seconds for the state to properly update in HA

20:36:00.824 Detail, Node008, Queuing (Send) SwitchMultilevelCmd_Set (Node=8)
20:36:00.824 Detail, Node008, Queuing (Send) SwitchMultilevelCmd_Get (Node=8)
20:36:00.825 Info, Node008, Sending (Send) message (Callback ID=0x12, Expected Reply=0x13) - SwitchMultilevelCmd_Set (Node=8)
20:36:00.849 Info, Node008, Sending (Send) message (Callback ID=0x13, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=8)
20:36:00.892 Info, Node008, Received SwitchMultiLevel report: level=0
20:36:04.864 Info, Node008, Received SwitchMultiLevel report: level=99

OZW sent the command to turn on, then immediately requested the current state from the bulb. Since the bulb just started the transition, it reported its current state (level = 0). Then, when the transition was over, it reported the new state (level=99).

I have been able to mostly eliminate this delay be setting the dimming duration (transition time) to 0 on the bulb.

#3

I’m trying to control via node red automation, but my perception is based on my actions. I open the bulbs color palette, I pick a color and watching it change. I then try to change the color again, and it doesn’t change for several seconds. I then try to put myself in my wife’s shoes and do what she would do, try changing the color again. Eventually, the bulb will catch up, but it’s slow. It’s to the point my wife will say it’s broken.

I haven’t completed any automations with the inovelli devices yet as I’m trying to migrate off of Smartthings and found a reason to upgrade some of my older Leviton zwave switches. I will be pairing everything with Hubitat to start with to ensure their firmware is up to date. My gut is starting to tell me to keep them on Hubitat to have that same ability down the road and deal with any limitations a bridged integration may present.

1 Like
#4

My ilumin RBGW bulbs are very slow as well, and I don’t have any parameters for ramp rate, only default state, bulb high (K), bulb low (K).

I have also setup with feature 177, how do I set ramp rate or dim speed?

#5

I’m having this issue as well.

My RGBW bulbs are super slow to respond when controlled via Home Assistant. I’ve done the work to manually set feature 177 so I can control the individual white balance/white level, and with three bulbs in a group I find that commands sent to change the bulbs either take a good 5-10 seconds to apply, or just don’t apply at all and I have to try a second or third time.

I’m not even trying to control via a switch, I’m just directly setting values using the HA light UI.

#6

Any thoughts on this one @Eric_Inovelli? I’ve been messing with this for two straight days and the unreliability of controlling the bulbs via HA is troublesome. Even if I set aside the flows I’m trying to do in NodeRed, just simply controlling the bulbs via the HA UI is very hit or miss (more often miss than hit, sadly).

1 Like
#7

Hey, I do not - tagging @EricM_Inovelli as he’s used HA before!

1 Like
#8

We are working on this with the manufacturer currently. I’ve got a couple suggestions that will help.

  1. Include the bulb in non-secure mode. This cuts back 3x on traffic.
  2. Can you remove node 1 from the group 1 association and see if that makes a difference? HA may be requesting the information that is automatically sent to group 1 causing 2x the traffic that is necessary.

So, if you have security enabled and HA is also requesting the info that is already provided to group 1 then you have a potential of a lot of unnecessary traffic.

#9

Thanks for the reply, good to know I’m not crazy.

I only did a normal add node when I added it, I didn’t do an “add node secure”, so I assume it’s already in non-secure mode?

How do I remove something from “group 1” in Home Assistant? I poked around the zwave UI and didn’t see anything obvious.

#10

Hi EricM - Thanks for your response.

I’m not having response issues as much as the bulbs are very slow to dim/ramp. Is this the issue you are addressing with the manufacturer?

I do not have them joined as secure, I will try removing node 1 from group 1 as well, but I’m assuming this will only effect response time, not dim/ramp, right?

#11

@ShoeNerd You are correct, that will just help with response time. With the bulb the only way we can get the dim/ramp speed to change is if we send the SwitchMultiLevel command with the “duration” argument. I’m not sure how to do that in Home Assistant, but maybe you are more familiar? Essentially you send the command to dim to a certain level over x duration in seconds. It would be something like SwitchMultilevelSet(value: 99, duration:1) to have it dim to 99 over 1 second. SwitchMultilevelSet(value: 99, duration:15) would be 15 seconds. SwitchMultilevelSet(value: 99, duration:0) would be instant.

@neile Ok, non-secure will help there. I can write something up about removing group 1, but it is similar to this KB article, but you remove the association. https://support.inovelli.com/portal/kb/articles/how-to-setting-up-device-associations-home-assistant

#12

If you are using the built-in zwave component of HA, have you tried specifying a transition time?

I use Zwave2MQTT, but I was able to eliminate the transition time by setting the Dimming Duration to 0:
image

I tried removing the Lifeline association, and it significantly speeds things up. OpenZwave does appear to issue a GET command immediately after issuing a SET command (and I am not sure if this feature can be turned off). Removing Lifeline association has 2 major drawbacks though

  1. Since OZW Issues a GET command immediately after SET, it ends up getting the brightness of the bulb while it is in transition. This causes HA to assume the wrong state. Setting the Transition time to 0 helps with this, but it is not ideal.
  2. Since the bulb is no longer providing status updates to the hub, states are not updated if the bulb is controlled by another device via association.

Do you know if the Red series dimmers are sending a duration argument to associated devices in group 3? I would expect the dimmer to send a duration argument based on the ramp rate configuration, but it doesnt seem to have any affect.

#13

@EricM_Inovelli Some steps/a KB article would be helpful. I just took a look and I don’t have an “add to group” or “remove from group” option for the bulb.

image
image.png1865×514 10.4 KB

#14

Yeah, this is totally a band-aid until we figure it out with the manufacturer. Any way in HA to send a SwitchMultilevelGet 5 seconds after you adjust the bulbs level or turn it on/off?

It doesn’t send a duration, but would be a great option to add. If you have one Inovelli switch associated to another Inovelli switch, the destination switch will use its parameter setting for “Dimming speed z-wave”.

@neile If you select group 1 in that drop down does it give you any options to add or remove?

#15

You should be able to set up an automation to call the zwave.refresh_node_value service, but you might need to get creative on how you do it. The last thing you probably want is for the automation to trigger itself every time it gets the updated value.

Another possible solution would be to enable device polling on the bulbs (just be careful, as polling too frequently can slow down the zwave network)

#16

@EricM_Inovelli Nope :frowning:

image
image1849×1067 31.1 KB

#17

Ok, so if you select “1:Lifeline” and then under Node to control you choose your “ZWave hub” (should be Node:1). There should be a remove button below. If it executes correctly the section that says "Other Nodes in this group: should be blank.

Ignore the crossed out part of this image as it is for something else:

image
image.png1131×637 43 KB

#18

@EricM_Inovelli Thanks, I was able to do that. I played around with the bulb a bit using the HA bulb control UI and it does seem quite a bit better. Adjusting the “W” slider is basically instant. The brightness slider does trigger every time as well, although it’s slow due to the fade. Is there a way to disable fading and just jump straight to the new brightness?

#19

@jtronicus Mentioned that there may be a way to set the “dimming duration”. Setting that to 0 would make it instant.

As a side note, we have a firmware update that removes the unsolicited color reports from group 1. If things are working for you as is, you may not want to worry about it, but if not it might be worth a try. If you do update the firmware then go back in and set the group 1 association back to the way it was.

#20

@EricM_Inovelli the new firmware is much appreciated.

here’s how to set up a Home Assistant configuration that will allow for a persistent, user-defined transition in the frontend for one or multiple LZW42 bulbs (maybe any bulb?).

  1. edit configuration.yaml
  2. restart HA
  3. set up your lovelace card.

first, drop a template sensor into configuration.yaml (or wherever your sensors are split into). it will track the on/off state of our LZW42 light entity to check how its icon should appear. rename the light.XXX entity to your lightbulb or light group and livingroom_lights: to whatever’s clever.

sensor:
  - platform: template
    sensors:
    livingroom_lights:
    friendly_name: "Living Room Lights"
    value_template: >-           
      {% if is_state('light.livingroom_lights', 'off') %}
        off
      {% elif is_state('light.livingroom_lights', 'on') %}
        on
      {% else %}
        failed
      {% endif %}
    icon_template: >-
      {% if is_state('light.livingroom_lights', 'off') %}
        mdi:lightbulb-off
      {% elif is_state('light.livingroom_lights', 'on') %}
        mdi:lightbulb-on
      {% else %}
        mdi:head-lightbulb
      {% endif %}

then, set up a button card in lovelace, using this YAML. the sensor you set up above is using the livingroom_lights: name so if you changed that code to porch_lights: it would become sensor.porch_lights.

type: button
name: Living Room Light
entity: sensor.livingroom_lights
tap_action:
  action: call-service
  service: light.toggle
  service_data:
    entity_id: light.livingroom_lights
    transition: 0

the “transition: 0” can be set to your preference.

you end up with something like this:

button w transition on

and when you turn the light off, this:

button with transition off

2 Likes