GE Dimmers and flip flopping toggle state in Web UI

I’ve searched around the forums and I have learned how to handle the GE Dimmers and the issue they present with the web ui toggle switch flipping back and forth due to polling and the ramp-up and ramp-down lighting.

I’m wondering if there’s a better way to approach this that if a command (on/off) is issued, to keep the toggle at that position until a refresh polling interval (in case of a zwave error or something)?

I mostly have GE Dimmers in my house and turning on or off a switch results in some confusing UI behavior that I’m not sure would pass the WAF :slight_smile:

I have 2 dimmers I am currently testing with and they are setup like this:

zwave:
  usb_path: /dev/ttyACM1
  polling_interval: 10000
  device_config:
    light.bonus_desk_dimmer_level:
      refresh_value: true
      polling_intensity: 1
    light.bonus_room_dimmer_level:
      refresh_value: true
      polling_intensity: 1

If I add a delay to each device config, it doesn’t help the cause. I still get the UI flip flop.

Is there a configuration that I’m overlooking that would help keep the UI in 1 state after the action?

Edit: Adding a gif showing the flip/flop toggle.
toggle

Interestingly enough it does not happen with the Jasco lamp dimmers. When I turn it off, they ramp down but the toggle on the site doesn’t flip back and forth a couple of times.

Anyone have any thoughts?

I’m not at home to test this, but I had a similar issue where the switch would flip-flop. I can’t confirm that this configuration does exactly what you’re describing, but it did seem to help HA reflect the status more accurately. Here’s what I use to get mine much closer to a real representation:

zwave:
  config_path: /srv/homeassistant/lib/python3.5/site-packages/python_openzwave/ozw_config
  new_entity_ids: true 
  polling_interval: 10000
  usb_path: /dev/zwave
  device_config:
    light.cabinet_lights_level:
      ignored: false
      polling_intensity: 1
      refresh_value: 2
      delay: 3

Hope this helps.

I’ll give it a try! Do you know where would the ozw_config be on a hass.io install?

Interesting, your config had worse results. I was only seeing the flip/flop toggle on the OFF command, but using yours it’s doing the flip flop for both ON and OFF. I just changed the delay to 1 and it seemed to fix the ON toggle flop, but still no good with the OFF.

Maybe missing the config is part of the problem?

Also worth noting, I changed the DIM Steps to 99 and DIM Rate to 1 for all 6 configs, and it didn’t make a difference (except caused 1 LED light to not turn on, which is weird) So I reverted back to step of 1 and rate of 3. :confused:

I have no idea on the zwave config file location in hass.io, as I’m using Raspbian with HA in a virtual environment.

What GE product are you using? Is it the Zwave or Zwave Plus version? I’m using the Zwave versions, models 12722 (on/off), 12724 (dimmer), 12730 (fan control), and 12721 (in-wall outlet). I’ve noticed that the 12722, 12724 and 12730 don’t report correctly if I don’t set the refresh_value/delay settings. They will do what you’re reporting, turn on, then immediately off, or vice versa. Then, they only report correctly once it polls again.

That’s why I have it poll again in 3 seconds, which I found was the shortest time that works consistently in HA when using the factory default ramp on/ramp off times (1.8 sec if I remember correctly) on the switches.

As far as programming the devices themselves, the only change I’ve made to the devices themselves was to change the LED setting on the 12721 outlets so that it’s on when the outlet is on, and off when it’s off (opposite of what it does from the factory). Everything else (naming, etc) was done via the OZWCP or HA’s ZWave control panel.

I’m testing with 2 of the 12724 model dimmers. The delay 1 worked with preventing a flip/flop ON, but still have it with the OFF.

I have a bunch of these, so if I adopt HA fully, I guess it’s something I’ll have to deal with.

I use:


  zwave:
    usb_path: /dev/ttyUSB0
    config_path: "/usr/local/lib/python3.6/site-packages/python_openzwave/ozw_config"
    # autoheal: true
    network_key: "REDACTED"
    polling_interval: 30000
    device_config:

      light.toy_room_lights_level:
        # Model: GE 12724
        polling_intensity: 1
        refresh_value: True
        delay: 3

with good results. I believe the delay keeps the UI from checking and gives it time to get to final state. It’s not perfect and I still see the behavior you mention with I quickly toggle multiple devices but doing just one works fine for me.

Also keep in mind you can adjust the ramp rate on the switches so that they get to target faster which could help.

I will also mention, with CustomUI - I am showing the sliders on the main UI and they do toggle between the to-state and the from-state but the actual toggle switch on the dimmer does not.

The interesting thing is if I choose delay 3, I get “worse” results than delay 1.

Here’s a gif I made:

  • The Bonus Room is delay 3, and you can see the flip/flop with ON and with OFF.
  • The Bonus Desk is delay 1, and the flip/flop is only with the OFF only.

So I think I’ll keep the delay 1 since it’s the better of the two options. Not the end of the world, just annoying.

Wish there was another config somewhere that would prevent the toggle flip/flop

toggle

1 Like

What ramp rate do you have on the switch?

They’re at the default step 1 and rate 3

@obrienlabs are you using the same polling interval?

I’m not, I’m polling every 10 seconds ( polling_interval: 10000) to try and “speed things up”. i can expand it to the 30 second setting you have to see if it changes any behavior.

I would recommend giving it a try. Polling too often could overload the network, especially if you have a large number of devices.

No change with the 30 second setting, so I’ll leave it 30s so I don’t overwhelm the network. As I understand it, that setting is just a casual poll to make sure the states are accurate. Nothing really to do with the flip/flop of the UI

Currently I only have 2 devices on HA (so I don’t think 10s would overwhelm 2 devices). I’m migrating off of ST though, so my network will grow rapidly once I finalize my HA configs.

So I’ve confirmed that mine does the same thing that yours does (they toggle on/off, then back to the correct state), but only when I toggle the switch in the UI. While I went through the options and changed mine around as a test (slower/faster), I found that my settings that I posted up earlier are the best for me, in that the UI reports the status correctly after a 3-second delay.

As a reference, I am using (2) on/off switches, (3) dimmer switches, (2) in-wall outlets, and (1) fan control. The dimmer switches are the only units that have this issue, and my switch settings are the defaults.

As a side note, I use HADashboard, which is part of AppDaemon, as my primary method of control, not the HA UI. Using HADashboard as my interface on our phones and hacked Amazon Fire tablets, the status is always reflected correctly.

1 Like

I’ll have to check that out. The flip/flop in the UI is a bummer (coming from ST where it doesn’t do that)!

Oh man, HADashboard is perfect. Too bad the native HA UI has that flip/flop - but I’m liking the flexibility with the HADashboard.

Yeah… it’s pretty slick, which is why we use it as the everyday interface for my wife. It’s sweet, simple and aesthetically pleasing, so it meets the WAF! And you can skin it any way you like.

And while you’re learning about other add-ons, check out Floorplan as well. There’s a link here in the forums for it. That one’s pretty cool too, as you can layout everything based on your actual floorplan, or any other vector drawing you want to use. It takes a little more work to get started with that than HADashboard, but it can be a cool “show off to your friends” thing.

1 Like

I have the GE 14294 dimmer (Z-wave Plus), and I see the same issue where the HA UI light toggle flips back and forth. As mentioned, it would be nice if the UI used the “delay” setting before flipping back to the original state. Perhaps we can submit this as an enhancement. This really bugs me.

Also, do any of you see this extra Z-Wave info (Node id, etc) when clicking on the light bulb in the HA UI? Does anyone know how to get rid of this?