GE/Jasco 14294 Dimmer no longer working

Hardware
Tags: #<Tag:0x00007f326c3d0d38>
#1

Hello,

I’ve had two GE 14294 dimmers working for quite some time, but in the last couple of months they stopped functioning correctly in Home Assistant. When I originally set them up a couple years ago I had to add the following to my configuration.yaml

zwave:
  light.microwave_light:
    refresh_value: true
    delay: 3
  light.kitchen_lights:
    refresh_value: true
    delay: 3

When this stopped working I started researching and found where something may have changed and the zwave configuration should be kept in a separate file so I changed my configuration.yaml to

zwave:
  device_config: !include zwave_device_config.yaml

and then in the zwave_device_config.yaml I put

light.microwave_light:
  refresh_value: true
  delay: 3
light.kitchen_lights:
  refresh_value: true
  delay: 3

Restarted home assistant and the refresh delay still is not being used, the toggle flips back and forth due to the ramp up/down delay on the dimmers as it’s trying to poll the devices too fast. I’ve seem some posts that this can be configured via the UI now and that’s how it should be done but I can’t figure out how to get change those parameters via the UI. Did something else change that I should be doing? Do I need to change this via the UI somehow? Any guidance would be appreciated.

#2

What specifically is the problem, are the states of the switches wrong, or is it just the UI switch toggling? Do the switches end up in the correct state at the end?

#3

The states usually end up being inconsistent with the UI. If the switch is off, and the UI shows the entity off and I toggle it on, the switch in the UI will flip back and forth a couple of times before stopping at on/~25% brightness even though the lights are on at full brightness. If I toggle it back off then the UI switch will flip back and forth back to on/~25% brightness but the lights are fully off. I believe this is due to it polling the device during the ramp up/down period which is what the refresh true delay 3 is supposed to prevent but it hasn’t been working the last couple of months.

#4

Have you tried increasing the delay value? I don’t think 3 has ever worked for me personally, I just stick with the default which is 5.

#5

I changed the zwave_device_config.yaml to

light.microwave_light:
  refresh_value: true
  delay: 5
light.kitchen_lights:
  refresh_value: true
  delay: 5

And they seem to end up in the correct state now on the initial couple of toggles but the UI still bounces back and forth initially like it’s still trying to poll the device immediately after the toggle. Then once the 5 second refresh occurs the UI ends up correct. I’m not sure why it keeps trying to poll immediately after the toggle when this worked for the last two years. It’s also odd because 3 seconds was always long enough of a delay until this started happening.

#6

Because that’s exactyt what OZW does, it always does a Get immediately after a Set to verify the value. There is no way to avoid this problem with the current HA zwave implementation, unless someone submits a code change for a different workaround. Most z-wave dimmers report an incorrect value for that Get since they are too slow to get to the target value. If you don’t set the refresh_value to true, the value is never updated. The refresh_value triggers a second get after the delay time, and by that time the switch is at the proper level. If you turn on the switch with a 10 second transition time you’ll find that the level is wrong for the same reason, there’s not a final Get.

I’m not sure why it keeps trying to poll immediately after the toggle when this worked for the last two years.

But it doesn’t do that, it only does one Get. If it kept trying to poll the value it would be correct eventually. In fact, in OZW 1.6 you can set a flag in the device XML file to poll the value until it reaches the expected value. This flag is enabled for a couple of the GE dimmers, so the ozw integration doesn’t need this workaround. This flag might be available in 1.4, I’ve never tried.

It’s also odd because 3 seconds was always long enough of a delay until this started happening.

Yes that’s odd, but like I mentioned that value never worked for me. Maybe you were just lucky.

#7

Makes sense, I swear the UI didn’t flip back and forth with the delay before but I use the frontend for those lights so infrequently I likely just don’t remember correctly. So migrating to the new OZW integration would likely resolve the issue? I haven’t looked into that much as I assumed it would be a lot of work. I may need to dig into that more.

#8

The amount of work and feature parity level will depend on what kind of devices you have, additionally the more nodes you have the more work.

In OZW 1.6 (and thus the ozw integration) the 14294 has the workaround set in the device XML file to internally refresh the level, so it’s not updated until the level is reached. Long transition times are still a problem.

If you want to test the same fix in 1.4, you can try editing the zwcfg*.xml file (stop HA first, then start). You’d want to look for this block:

                        <CommandClass id="38" name="COMMAND_CLASS_SWITCH_MULTILEVEL" version="2" innif="true">
                                <Instance index="1" />
                                <Value type="byte" genre="user" instance="1" index="0" label="Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="25" />
                                <Value type="button" genre="user" instance="1" index="1" label="Bright" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
                                <Value type="button" genre="user" instance="1" index="2" label="Dim" units="" read_only="false" write_only="true" verify_changes="false" poll_intensity="0" min="0" max="0" />
                                <Value type="bool" genre="system" instance="1" index="3" label="Ignore Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="True" />
                                <Value type="byte" genre="system" instance="1" index="4" label="Start Level" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="0" />
                                <Value type="byte" genre="system" instance="1" index="5" label="Dimming Duration" units="" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="255" value="255" />
                        </CommandClass>

The level value (brightness) is the first entry. You would want to change verify_changes="false" to verify_changes="true", as in

                                <Value type="byte" genre="user" instance="1" index="0" label="Level" units="" read_only="false" write_only="false" verify_changes="true" poll_intensity="0" min="0" max="255" value="25" />

The flag exists, I can’t remember if OZW 1.4 implements it or not for dimmers.

#9

I stopped HA, changed that value to true in the xml file in the block for each of my 14294’s, saved the file, started HA and the toggle still flips back and forth in the UI. I suppose I may need to look into updating to OZW, I only have 10-15 zwave devices currently so it may be best to do it now before I get more. Thank you for the help.

#10

This thread was not what I wanted to read. I have been loosely following the different Z-Wave options in Home Assistant these past few months. Today I was trying to troubleshoot the exact same problem with the 14294 that the OP mentioned.

I came over from SmartThings early last year and this dimmer originally worked perfectly. I even put some Samsung Zigbee buttons next to the bed so we could turn this on to a low level at night and turn the light off from the bed side. This was probably one of the only automations that my wife thought was worth the effort I put into it. It was also the one that she used the most. It has been a mess since about the same time as the OP described though.

It is really depressing that Z-Wave seems to be such an after thought in Home Assistant. I literally think my best option here is to replace the light switch with a different brand and possibly switch to Zigbee. Maybe that will work.

#11

did you ever get this working?

#12

I have a similar experience to @clindsey - migrated from SmartThings, initially my 14294s seemed to work fine (I mostly use scenes to set them to defined values at certain times or on-demand).

Around the turn of the year it seemed the scenes would not complete correctly - the main problem being the physical switch would show ON (indicator off), HA would show the switch as ON, but the actual light would not be on (it would act like it was dimmed all the way down).

The HA UI appears to be updated, but the physical light does not reflect the correct brightness value.

My dimmers are also configured as:

light.microwave_light:
  refresh_value: true
  delay: 4
light.kitchen_lights:
  refresh_value: true
  delay: 4

I am still seeing this issue today, but have mostly given up on fixing it, and am hoping that updating to Z-wave JS solves the problem.

#13

Thanks for the reply. I ended up buying a TP-Link Kasa HS220 switch and replaced that Z-Wave switch in the master bedroom. I am VERY pleased with the HS220. It runs over WiFi instead of Z-Wave. I have the HS220 working with my Zigbee buttons too and no more issues!

I moved the GE Z-Wave dimmer downstairs where I use it much less frequently and don’t have it tied to my slightly complex scripts. All is well in the world now. I am definitely going to buy more HS220’s since they are half the price too.