No 
brightness still doesn’t work. Aside from its apparent issues with HA, I also hate that it takes like 2-3 seconds for the light to turn on/off after the physical switch is pressed. It confuses everyone who touches it. Kinda wish I did return it.
That’s unfurtonate. It’s odd because the light acts as if it recieved the new brightness level, but just doesn’t actually change brightness. I tested by changing the brightness is HA, removing the zwave node, then adding the node back with a different name. After doing so, HA will still receive the brightness value that it sent originally. I also tried changing the brightness level, shutting down HA, then turning the switch off manually. Before actually turning off, it will quickly change to the brightness level I had set in HA. Same thing with turning on. If the light is off, I can set the brightness in HA, shut down HA, then turn the light on manually and it will turn on to the new brightness level I had set in HA.
So, the brightness level is obviously being received, stored, and reported by the light. It’s just not actually changing the brightness at that time. I still can’t figure out why though. It works perfectly through SmartThings, so there has to be a way to get this working properly.
Wow those are some interesting findings.
so I have 2 of these dimmers. In fact, just added one yesterday. I don’t have any issues with brightness or control from HA. There is a weird issue in turning off the light, HA will report it as off but very dim brightness, and other times report it as on and either no brightness or very little, but the light is physically off. It’s a minor inconvenience that resolves itself after a couple minutes.
Anyway, the real reason I’m posting is in regards to the slow dim on/off. This can be changed. In fact you can change how it dims when commanded over Z Wave, physical interaction, or a group all on/all off. If you go into the Z Wave configuration panel from the HA frontend, select the node in the drop down, then scroll down to the configuration options. 6 of the configuration parameters are for dimming commands. You can change the dim levels per step and the time per dim step. the default is dim levels per step 1 (min 1 for tiny changes, max 99 for one large jump) and time per step of 3 (min 1 for short time, max 255 for long time x 10ms). Do the math and that means by default, the dimmer takes 99 steps x 3 x 10ms for a total of approximately 3 seconds to dim on/off. You can adjust this to dim anywhere from on/off in 1 step (99 levels per step) in .01 second or on/off in 99 steps (1 level per step) over 252.45 seconds (4.2 minutes).
I was able to get it somewhat working by using an automation to quickly toggle the switch off and on whenever the brightness value changed. But due to timing of things and the fact that the brightness changes whenever you turn the switch off, it isn’t very reliable. I wish I knew what ST does differently to make it work so flawlessly.
It’s so weird. I don’t have any issues with the on/off reporting correctly, but my brightness won’t change properly. It seems different people have different issues with the lights but I have no idea what causes that difference.
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:
I just added this to my config for zwave and all the lights work as expected in regards to turning on and off, I have ~7 of the GE dimmers:
zwave:
usb_path: /dev/ttyACM0
device_config:
light.living_room_d_level:
polling_intensity: 1
refresh_value: true
light.can_d_level:
polling_intensity: 1
refresh_value: true
light.chand_d_level:
polling_intensity: 1
refresh_value: true
light.island_d_level:
polling_intensity: 1
refresh_value: true
light.hall_d_level:
polling_intensity: 1
refresh_value: true
light.master_level:
polling_intensity: 1
refresh_value: true
1 Like
I had the same on/off/brightness problem, and the device_config solved it. Thanks !
funny, just added 3 new dimmers and this config isn’t working… Works for the first 7, not the newest 3… odd.
I found I had to add it via the Z-wave GUI before it took effect for me.
I tried that last night to no avail. I might load up openzwave tonight to push the property. I hate the zwave config in home assistant. It does not work well.
Is this still working for you? My GE Dimmers work terribly compared to the Levitons. They flip on and off and seem to report their dim changes while fading in/out which is just silly.
Still working fine…
1 Like
My GE Dimmers (all the latest model) do the same. I have all my dimmers set to a 5 second delay in my zwave_device_config.yaml file, e.g.,:
# GE 14294 Dimmer Web UI Fixes
light.kitchen_recessed_lights:
refresh_value: true
delay: 5
light.kitchen_sink_lights:
refresh_value: true
delay: 5
light.kitchen_skylights:
refresh_value: true
delay: 5
I still get the flipping on/off effect but after five seconds the UI is updated correctly. I keep hoping that the UI will get updated to prevent the instant on/off toggle if a delay is set for the device. My GE switches work fine and there is no need to add an update delay for them.
Besides this minor display bug, the dimmers work fine. In older versions of HA, I was enabling polling of the dimmers because the delay setting didn’t appear to work properly. However, it appears the delay feature works as expected in the latest release and I’ve disabled polling for about a week now with no issues.
Since disabling polling, my z-wave network as been very solid and I no longer experience turn on/off delays due to networking flooding caused by the polling.
I have a Leviton for my low voltage under cabinet lighting control and the dimmer is great but basic. I really love the double tap functionality of the GE devices and utilize it throughout the house plus I think the GE dimmers/switches are cleaner looking. After working through all the issues I had with them over the last 8 months I’m actually quite happy with my investment and don’t regret it - 47 GE dimmers/switches and counting. 
1 Like
I think there’s something going on at the z-wave level (I’ve looked at the logs but don’t claim to fully understand them) that causes the HA entity to be updated shortly after the command is sent to the device. But, it would seem like a nice feature for HA to somehow ignore updates like that if refresh_value is true and the delay period has not yet expired.
Another nice feature would be to be able to dynamically change the delay period for a given device via a service. I have scripts for flashing a dimmer that temporarily change the ramp time to its fastest level before toggling the dimmer on and off, and then sets the ramp time back to the default (of 2.97 sec.) But because the refresh delay is fixed (at 3 sec in my case), HA doesn’t see the dimmer toggling on and off. I’d like to be able to see this in the history (specifically in a history_graph I have for my - only 5 
- z-wave lights & switches.)
I haven’t looked at the logs but I think you are right. If I recall correctly, the GE switches don’t actually do the instant updates like they should, like the way my Eaton RF9534DW Dimmer (non z-wave plus) does. I believe the GE dimmers do updates via some funky programing so they could avoid paying a licensing fee to Lutron for their patent (which I think expired recently).
I wouldn’t be surprised if the GE devices are reporting some type of forced status updates to the controller at every step of the dimming process. So instead of just waiting for the dimmer to go from 255 to 0 then send a status it is sending a status at 255, 170, 85, 0 (3 second dim), hence the toggle going from off to on then finally to off again.
I doubt Jasco/GE will ever to an update for this so the only solution would be building in the allowance for their whacky functionality into HA.
I didn’t realize the ramp time is defaulted to 3 seconds. I am going to try lowering my delay time (from 5 seconds) and see if I notice any issues.
The ramp time is controlled by two config parameters: 7, aka Z-Wave Command Dim Step, and 8, aka Z-Wave Command Dim Rate. 7 is described as:
Indicates how many levels the dimmer will change for each dimming step.
And 8 is described as:
This value indicates in 10 millisecond resolution, how often the dim level will change. For example, if you set this parameter to 1, then every 10ms the dim level will change. If you set it to 255, then every 2.55 seconds the dim level will change.
Z-Wave levels go from 0 (off) to 99 (full on.) The default for 7 is 1, and the default for 8 is 3. So, it takes 99 steps (99 levels / 1 level per step), and each step is 30 ms (3 x 10ms), so 99 x 30ms = 2.97s.
FWIW, I have two different versions of the GE/Jasco plug-in dimmer, and for both I set delay to 3 and it works fine.
This worked for all of my dimmers. Thank you for this!
Bg
Just came across this old thread. I installed 8 jasco switches 2 years ago. My wife has been nagging about the switches not turning off entirely and complain how long it takes to dim the lights. It came to a point of her demanding I uninstall each ones and find some that works.
I messed around with the dim steps and dim rate for both local and zwave command…everything seems to work pretty well and responsive. Pretty happy with the results. Hopefully I can move on and see if I can install more =).