GE Dimmers and flip flopping toggle state in Web UI

Configuration
5

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:

6

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.

7

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.

8

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.

9

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
10

What ramp rate do you have on the switch?

11

They’re at the default step 1 and rate 3

12

@obrienlabs are you using the same polling interval?

13

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.

14

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

15

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.

16

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
17

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)!

18

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

19

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
20

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?

GE_14294_dimmer
GE_14294_dimmer691×848 34.2 KB

21

FYI, someone created a feature request for an “optimistic mode”, which (if it works) should help the extra false triggering in the HA UI. Go here to vote for it:

1 Like
22

Hi Obrienlabs, just wondering if you ever got this resolved since its been over a year since you posted. Running into the same issue myself right now.

1 Like
23

Just checking in to see if anyone sorted this out. I haven’t seen much talk of it in the past year. Thanks!

24

Nothing to sort out, it’s a hardware thing. Jasco switches don’t report values during ramp up and ramp down. All you can do is adjust the delay to a point where its acceptable.